Your coding agent produces a good diff. The model is capable, the prompt is well-formed, and it passes your pilot tasks. Then you let it run unattended against a production repository and find out what it did while nobody was watching. Trace the failure back and it sits in the configured software around the model: the tools, the memory assembly, the verification steps, the control loop.
That software is the harness, and if you’re keeping an owned harness honest, you already know it exists. It builds up dead weight quietly.
In this article we’ll separate load-bearing capability from dead weight, then wrap the controls and telemetry around it. But first, why do these projects fail at the harness layer at all?
Why do most enterprise AI agent projects fail at the harness layer rather than the model layer?
The model is an open-loop policy: it produces a good next step but never closes the loop. The harness is the controller that checks what happened, decides what to do next, and stops when things go wrong. Over a long task, reliability is a property of that controller. Research on long-horizon agent performance finds harness-induced variance can exceed model-induced variance, sometimes reversing the ranking of two models.
The reason is arithmetic. An eight-stage workflow that runs at 95% per stage succeeds end to end only about 66% of the time, because errors compound across stages: 0.95 raised to the eighth power is 0.66. That is the March of Nines, where each additional nine of reliability costs disproportionately more than the last. A capable model fails late because each step adds a little unverified error and nothing checks or stops it before the next step builds on the last. The dominant failure mode of deployed agents is the silent mistake, and Bessemer’s 2026 infrastructure report estimates 78% of AI failures are invisible.
Then there’s the weight. A harness fills up like a junk drawer: a rule added for one incident, a retry path nobody removed, a check that outlived the model it was compensating for. It accretes silently, and it buries the few components that actually matter.
Missing governance makes it worse. Without a sandbox, a kill switch, and gating at irreversible steps, a capable model expands the blast radius before anyone notices. Replit’s agent deleted a live production database because the “no changes without permission” rule lived in the prompt rather than the runtime, where it carried no enforcement weight.
Finally, absent observability removes attribution: without structured traces you cannot connect a regression to a specific harness component. Load-bearing capability, governance, and observability either exist at the harness layer or they do not. Why the harness now outperforms the model and the operational burden of ownership both rest on that distinction. It is where these projects fail, and why the failure surfaces late.
If the harness is where failure lives, the first job is to see which parts of it actually matter.
How do I tell which parts of my harness are actually load-bearing versus dead weight?
The load-bearing test is a three-part rubric: an owner, a mechanism, and a failing test. A component is load-bearing if someone is accountable when it fails, if the code enforces it, and if something in the pipeline turns red when that mechanism stops working. A component that scores three “no”s is a production risk. Dead weight is the opposite: an accreted rule with no owner, no mechanism, no cost, and no expiry.
The audit is subtractive before it is additive: remove one component at a time and watch the result. Anthropic reached the same conclusion after finding it hard to tell which pieces were actually load-bearing. If nothing regresses, “no change” is a first-class outcome: it was dead weight.
Expect to find a lot of it. ByteDance Seed‘s HarnessDev study found that only 34 of 64 harness changes generalised, and that 124 of 587 harness features were dead code. The same work reports that harness changes “produce some performance gains, but they are unstable and transfer only partially to held-out tasks,” with limited transfer across models. A harness change that doesn’t generalise is an overfit you now have to maintain.
Two tests isolate where the effect lives. Model/harness swap testing holds the model fixed while you swap the harness, then holds the harness fixed while you swap the model. A token-efficiency study found harness choice shifts tokens-per-solved-task by roughly 40x, while a model upgrade moves it only from 1.0 to 1.3. And benchmark on the tasks your harness really runs: the major coding benchmarks have been gamed to near-perfect scores without solving a single task.
Swap testing also shows which parts you can drop without loss, which is what auditing the harness primitives is for.
Once the dead weight is out, what remains still has to be governed while it runs unattended.
What governance and observability do I need around agents running unattended against production repos?
Observability has to come first, because you cannot govern what you cannot see. You want structured traces of every prompt, tool call, permission request, test result, and human intervention, and the open tooling now exists for it (Langfuse, Arize Phoenix, Galileo, Latitude). Keep every failed, expensive, or anomalous trace in full, and sample the happy path heavily, because the traces you drop are the ones you need in an incident.
Containment follows, because a sandbox sets the blast radius before anything else can. An MCP gateway registers and versions every approved tool, and an agent registry records which agents exist and what each may touch.
Then comes enforcement, where the runtime decides. A boundary the agent can rewrite is no boundary at all, which is why runtime policy-enforcement research found 48% compliance without a reference monitor and 93% with one, the gap between advisory guardrails and deterministic enforcement.
Enforcement leads to proactive testing. Continuous red teaming finds failure before it finds you. And two controls bound the moment it does: a kill switch that terminates the entire execution graph (orchestrator, sub-agents, nested agents), and human-on-the-loop gating at irreversible transitions with fail-closed defaults. Killing the parent does not recall the children, so the switch has to sit in the infrastructure layer, outside the agent’s own code.
Compliance sets the boundary. Under the EU AI Act, deployers of high-risk systems face log-retention duties of at least six months, and customer VPC or on-premises residency decides where telemetry and runs may live. Design both together, before the first unattended run, or you’ll be retrofitting them later at the cost of governing what you own.
Owning a harness is an operational burden: a loop you have to be able to see, bound, and stop. The audit’s real product is optionality, learning which parts carry load and which you can drop without loss. Governance is what makes an owned harness governable in the first place, and it turns an unattended liability into a governed loop. Audit and govern before it fails, and failures surface early and traceably. That is ownership done properly.
Frequently Asked Questions
Isn’t a more capable model the fix for an unreliable coding agent?
No. A stronger model raises the ceiling on any single step, but it does not change how error compounds across a long-horizon task or whether anyone can see and stop the run. If your harness has no independent verification, no runtime gate and no traces, a better model often fails later and more expensively, because it travels further before the unverified assumption surfaces.
What exactly counts as the harness, as opposed to the model?
The harness is the configured software around the model: tool access, memory and context assembly, sandboxing, verification steps, retry logic and the control loop that decides what happens next. The model supplies capability; the harness supplies accountability, observability and containment. When a run fails unattended, the fault usually sits in that surrounding software rather than in the model weights.
What is the March of Nines, and why does it matter for a coding agent?
The March of Nines describes how each additional nine of reliability costs disproportionately more than the last. For a coding agent, it means a harness that only catches some failures hits a hard ceiling, because per-step error compounds across a long task. You reach the next nine through independent verification and governance at the harness layer, not by swapping models and hoping.
Isn’t governance just bureaucracy layered on top of a working agent?
No. Governance is the property that makes an owned harness governable at all, because it gives you a runtime you can see, bound and stop. A control that lives only in a document or a prompt is advisory. When it is enforced in the runtime, with a sandbox, gating and a kill switch, it becomes something the agent cannot simply argue past or edit away.
What is the smallest governance control I should add first?
Start with observability. Structured traces of prompts, tool calls, permission requests, test results and human interventions are the prerequisite for everything else, because you cannot govern what you cannot see. Before you build a sandbox, a gateway or a kill switch, make sure a failed run can be attributed to a specific harness component. Visibility comes first.
Can’t I just tell the agent in the prompt what it must not do?
No. A rule in a prompt is advisory, and a constraint the agent can edit, ignore or reason its way around is not a constraint. Enforce the boundary in the runtime instead, where a forbidden state cannot be argued past. Sandboxing, gated tool calls and registry-based permissions hold regardless of how the model is prompted or how cleverly it justifies itself.
How often should I re-audit the harness?
Treat every added capability as a change that needs an owner, a mechanism and a failing test, and re-audit whenever that discipline slips. Dead weight accretes silently, so schedule a periodic subtractive pass rather than waiting for an incident. Re-run your swap tests on the tasks your harness really runs, and remove anything that no longer carries a measured effect.
What if a feature looks load-bearing but nothing regresses when I remove it?
Then it was dead weight, and “no change” is a first-class outcome. Remove it, record the result, and move on. Keep the removed feature recoverable so that if a real task later regresses you can restore it quickly. Removing one feature at a time is what makes that judgement safe, because you can always trace a regression to the change that caused it.
What is the difference between a kill switch and a human-on-the-loop phase gate?
A kill switch stops an unattended run immediately, and it belongs in the runtime so it works even when the agent is mid-task. A human-on-the-loop phase gate is a deliberate pause at an irreversible transition, such as a deploy or a destructive migration. Gates use fail-closed defaults, so if no human responds, the run stops rather than proceeding unchecked.
Does any of this change if my agents run on customer infrastructure?
Yes. Customer VPC or on-premises residency constrains where telemetry and runs may live, so plan observability inside that boundary rather than bolting it on later. Regulatory expectations also matter: under the EU AI Act, deployers face log retention duties for high-risk systems. Design the telemetry path and the retention policy together, before the first unattended run.
Who should own the harness inside an organisation?
Every load-bearing feature needs a named owner who is accountable when it fails. Without that, features accrete with no mechanism, no cost and no expiry, which is exactly how dead weight builds up. Pair ownership with an agent registry that records which agents exist and what each may touch, so accountability and inventory stay joined to the capability itself.
How do I know a harness change actually generalised?
Test it on the tasks your harness really runs, not on a public leaderboard. Hold the model fixed and swap the harness, then hold the harness fixed and swap the model, to see where the effect lives. ByteDance Seed’s HarnessDev study found only 34 of 64 harness changes generalised. If a change helps one task and nothing else, treat it as an overfit.
