The Harness Around the Model
The model handles understanding, judgment, and fuzzy calls. Whether any of it ships depends on the engineering control layer wrapped around it.
The model handles understanding, judgment, and fuzzy decisions. Whether any of that ships depends on the engineering control layer wrapped around it. That layer is the harness. It does not make the model smarter; it decides whether the model's judgment can land inside your system and be recalled when something goes wrong.
What the model owns, what the harness owns
Models are good at inferring intent from messy input, judging under incomplete information, and producing output that needs semantics. They are bad at remembering your release process, restoring state after a crash, and refusing an out-of-scope write.
So the split is clear: semantic understanding, planning, and fuzzy judgment go to the model; deterministic flow, validation, data passing, state, and permissions belong in the harness. Splitting thinking from doing into separate planes also pays directly. One team decoupled planning from execution and cut p50 time-to-first-token by about 60%, because the first byte the user sees stopped waiting on the long tail of tool execution cursor-agent-harness.
The five jobs a harness does
The harness is talked about as one object, but it does five jobs: Context (what the model sees), Tools (what it can touch), Constrain (fail-safe defaults — every capability starts closed and has to be opened explicitly), Verify (decide automatically whether the result is right), Correct (fix or roll back when it is not) ai-agent-book. The first two decide whether the model can get it right. The last three decide whether you can pull it back when it does not. Most teams spend on the first two and take their incidents from the last three.
The last two each carry a rule that gets skipped. Verify reads structured data only — the fields a tool returned, exit codes, assertion results — and never the prose the model generated, because that text may already be under someone else's influence. Letting the model grade its own account of what happened is letting the defendant issue the certificate of innocence. Correct keeps intermediate state off the screen until recovery has been ruled out: retry quietly, resume generation, and only degrade or hand to a human once you know it cannot be repaired. Showing a user a half-finished result makes their experience pay for your retry budget.
These five are not a rival skeleton to the six domains below. Constraint, verification, and correction land on Gate and Recovery — which are also the two domains most often left without an owner.
What is that layer worth? A reference point that does not depend on a particular model generation: LangChain moved from 52.8% to 66.5% on Terminal Bench 2.0, from outside the top 30 on the leaderboard into the top 5. The model never changed. Everything that changed was harness work — making the agent check its own execution results, notice that it had started repeating itself, and adjust how it spends thinking. The point is not "a harness is worth 13 points." It is that once the model stops being the differentiator, the whole advantage moves to what sits outside it.
Six domains, each with artifacts and an owner
| Domain | Responsibility | Main artifacts |
|---|---|---|
| Identity | Role, inputs and outputs, capabilities, permissions, forbidden actions | Agent contract, policy, capability allowlist |
| Orchestration | Paths, phases, dependencies, parallelism, human nodes | Workflow, state machine, router |
| Context | Selection, isolation, compression, references, handoff | Context policy, handoff, artifact reference |
| Gate | Phase entry, output acceptance, release gates | Validator, checklist, grader |
| Recovery | State, retry, rollback, cancel, resume | Execution ledger, checkpoint, recovery policy |
| Evolution | Failure attribution, experience, rule and asset governance | Trajectory, experience, feedback patch |
Every agent project needs an owner per domain, and safety, permissions, data integrity, and hard gates must live in the system instead of in a prompt openai-harness. The two domains most often left unclaimed are Gate and Recovery: the gate decays into "please check carefully," and recovery quietly defaults to "run it again."
Replaceable, switchable, ablatable
Record what each component solves, what it costs, and how you measure it — and make each one individually replaceable and switchable. The reason is that models move the ground beneath you. A patch written for one generation's quirk can flip from life-saving to dead weight on the next: Anthropic added a context reset to work around a model's context anxiety, and the behavior was gone in its successor. The test is not whether a component helps today. It is whether you can switch it off in five minutes and run an eval that shows the difference.
The symmetric discipline: adopting a harness does not justify multi-agent, a vector store, a durable workflow, or a governance platform. Each of those still has to clear the complexity ladder on its own.
When the next model ships, does this gain or expire?
Test every harness investment with one question: when the next frontier model ships, does this pay off or expire?
Work that substitutes for or compensates model reasoning — decomposing steps, prompt choreography, flow tuning — gets absorbed by the next upgrade, with a half-life of roughly one model generation. Work that hands the model information it cannot manufacture — real internal system state, build output, logs, test feedback — keeps compounding. That is not an argument for never doing the first kind; it is an argument for knowing how much runway you are buying.
The return is a product, not a sum
Return is roughly model capability multiplied by environment capability. The model is a rented factor that rises on the vendor's schedule, outside your control. The environment is a factor you own, have to build yourself, and that only accumulates. Multiplication means that when the environment is zero, no amount of model capability rescues the outcome.
Cursor ran into exactly this when moving agents to the cloud. Locally, an agent inherits a complete environment: installed dependencies, login state, caches, the right data. In the cloud the machine is clean, every invisible premise vanishes, and environment becomes a silent quality killer. Their conclusion is that environment setup is not a deployment detail; it is a precondition for quality cursor-cloud-agents.
So route engineering effort into environment and verification assets: turn internal systems into something with feedback and checkable state, so the agent can obtain ground truth on its own. Do not join the race to make models generate harder. That is the vendor's track, and it is not one you win.
