Agent sprawl occurs when individual developers or teams deploy AI agents without central oversight. Research indicates that 73% of enterprise AI agents are unmonitored “shadow agents” — running without governance, logging, or security review. They have access to codebases, APIs, and sometimes production systems without anyone tracking what they do.

Security: Shadow agents may have overly broad permissions, creating attack surfaces.

Compliance: Untracked agents may violate data handling policies or regulatory requirements.

Cost: Unmonitored agents can run up significant API bills through doom loops or inefficient usage.

Quality: Without harness engineering, shadow agents produce inconsistent, unreviewed code.

Traditional vendor lock-in was about the model: if you built on GPT-4, switching to Claude was hard. The new lock-in is at the workflow level: if your entire harness is built around Claude Code’s CLAUDE.md format, Cursor’s AGENTS.md conventions, or OpenAI’s Codex API, switching platforms means rebuilding the harness.

Platform-agnostic constraints: Write constraints in generic markdown, generate platform-specific files.

Abstraction layers: Build your orchestration on abstractions that can target different agent platforms.

Portable skills: Structure skill files so they can be adapted to any platform’s format.

Multi-model testing: Regularly test your harness with different models to ensure it’s not model-dependent.

Prompt injection via CLAUDE.md: If an attacker can modify the constraint document, they control the agent’s behavior.

Tool abuse: Agents with shell access can execute arbitrary commands. Agents with API access can exfiltrate data.

Supply chain: MCP servers from untrusted sources can inject malicious instructions through tool outputs.

Privilege escalation: Agents may be given broader permissions than needed for their specific task.

Least privilege: Give agents only the permissions they need for the current task.

Sandboxing: Run agents in isolated environments with limited file system and network access.

Audit logging: Log every tool invocation, file modification, and API call.

Constraint integrity: Protect constraint documents with the same rigor as production config. Code review all changes to CLAUDE.md.

A rippable harness is one that can be replaced or significantly modified without rewriting the entire system. The constraint logic is separated from the platform integration. The review pipeline is modular. The orchestration layer has clean interfaces. If a better platform emerges tomorrow, you can swap it in without starting over.

Separate concerns: Constraint content, platform integration, and orchestration logic in different layers.

Standard formats: Use markdown for constraints, JSON for schemas, YAML for configuration.

Clean interfaces: Each harness component communicates through well-defined interfaces, not tight coupling.

Version everything: Constraint documents, skill files, and pipeline configs should be versioned and diffable.

Harness engineering is creating a new career path: engineers who specialize in designing systems that make AI agents productive. This requires deep software engineering knowledge (to understand what good code looks like), systems thinking (to design constraint and review architectures), and AI literacy (to understand agent failure modes).

How long will this role exist? If agents get good enough to not need harnesses, the role disappears. If agents always need guidance (the more likely scenario based on current trends), harness engineering becomes a permanent discipline — like DevOps, which emerged when deployment became complex enough to need its own specialists.

Agent registry: Central catalog of all deployed agents, their permissions, and owners.

Approval process: New agents require security review before deployment.

Permission tiers: Read-only, write-to-branch, merge-capable, production-access — each requiring increasing approval.

Cost budgets: Per-agent and per-team spending limits on API calls.

Audit requirements: Logging and review requirements based on agent permission level.

Governance doesn’t have to be heavy. Start with: (1) A shared spreadsheet of all agents and their owners. (2) A Slack channel for agent-related incidents. (3) A monthly review of agent costs and error rates. (4) A simple approval process for new agents. Scale governance as agent usage scales.

Google DeepMind’s AutoHarness paper demonstrated that models can automatically generate effective harnesses for coding tasks. The agent analyzes the task, generates appropriate constraints and verification steps, and uses them to improve its own output. This suggests a future where harness generation is partially automated.

AutoHarness doesn’t eliminate the need for harness engineers — it changes what they do. Instead of writing every constraint manually, engineers design the meta-harness: the system that generates and validates task-specific harnesses. The human role shifts from writing constraints to designing the constraint generation system.

Standardization: Expect convergence on constraint document formats, review pipeline patterns, and orchestration interfaces. The current fragmentation (CLAUDE.md vs AGENTS.md vs Codex rules) will consolidate.

Tooling: Dedicated harness engineering tools will emerge — constraint editors, compliance dashboards, entropy monitors, and harness testing frameworks.

Education: Harness engineering will become a formal topic in software engineering curricula and professional development.

Harness engineering is part of a broader shift: software engineering is becoming systems engineering. Engineers increasingly design systems that produce code rather than writing code directly. The skills that matter are shifting from implementation to architecture, from coding to constraint design, from debugging to observability. Harness engineering is the discipline that makes this transition work.