If you have operated a coding agent for more than a week, you have built a harness without calling it that. The prompt scaffolding, the little script that assembles the right files before you start, the hook that runs the tests before you trust “done,” the retry you do by hand when a run dies. That is not the model. That is the machinery around the model, and it turns out the machinery is most of the job.
The term circulating for this in the community is harness engineering. You hear it from people who operate agents seriously, in Anthropic’s engineering writing and in developer venues like Latent.Space, used loosely but pointing at the same thing: the discipline of building and tuning the loop the model runs inside. I am using it here in that general sense, because it names something a lot of us have been doing unnamed. The interesting claim underneath the term is that when agent work fails at scale, the harness is usually the reason it failed, and the harness is usually the thing worth fixing. It is one chapter of building software with AI agents, and maybe the least glamorous one.
What a harness actually is
Strip it down and a harness is the outer loop around a model call. The model does one thing: given some context, produce the next output. Everything that decides what context it gets, what tools it can call, what happens with the result, and what happens when the result is wrong, that is the harness.
Concretely, a coding harness is doing at least this:
- Context assembly. Which files, which prior decisions, which constraints go into the window, and in what order. Get this wrong and even a strong model produces confident nonsense, which is the entire subject of context engineering for coding agents.
- Tool mediation. What the agent can run, with what permissions, and how the results come back. A test runner, a file editor, a shell, each with a boundary.
- Verification. What checks the output before anyone trusts it. The difference between “the agent said done” and “the gate passed.”
- Recovery. What happens when a step fails or a run dies, covered in recovery as a first-class workflow.
- Routing. Which engine gets which task, the concern behind routing every task to the right engine.
None of that is the model. All of it determines whether the model is useful. That is why harness engineering became a thing to talk about: the leverage moved.
Why the harness became the bottleneck
For a while, the obvious way to make agents better was a better model, and that worked, until it stopped being the thing that mattered on real work.
The clearest evidence I have run myself is in the recovery experiment. Across four cumulative episodes with hidden gates, a coding agent with a strong prompt plateaued at a two-thirds pass rate. The same agent with a hand-written recovery skill plateaued at the same place. Bigger models in single-run controls did the same. The thing that reached 100% was not a smarter model, it was a harness that held the contract and re-scored the work after each attempt. Same executor, different loop around it, different outcome.
That is the general shape of the argument in agents need a runtime, not a bigger model. Once the model is good enough to write correct code from correct context, the frontier moves to the system that supplies correct context, verifies the output, and recovers when it drifts. The model got commoditized. The harness did not.
Anthropic’s own engineering writing points the same direction, whether in building effective agents or their account of a multi-agent research system: most of what makes an agent reliable at scale is architecture around the model, not the model in isolation.
The parts of a harness worth engineering
Treating the harness as a real artifact means it has parts you design deliberately, not scaffolding you accrete by accident.
The context contract. What always goes in, what never does, and how you keep the window from filling with noise. A harness that dumps the whole repo into every call is not engineering, it is hoping. This is where managing the context window stops being a tip and becomes a design constraint.
The verification layer. Gates that run on the output regardless of what the agent claims. A harness whose only completion signal is the agent saying “done” has no verification layer, it has a suggestion box.
The recovery path. Checkpoints, last-good state, a way to resume without starting over. A harness without this makes every failure a manual salvage.
The handoff format. What travels when work moves between agents or sessions, the subject of handoffs between agents. A harness that cannot hand off cannot scale past one session in one head.
The instruction layer. The rules files the agent reads, and crucially, whether they are still true. A harness that feeds agents stale rules is engineering the wrong loop carefully.
You can build all of this by hand, and if you operate agents seriously you already are. The question harness engineering forces is whether you are building it deliberately, with parts you can reason about, or accreting it as a pile of scripts that only you understand.
Where PaellaDoc fits
Harness engineering as a phrase is useful because it names the real work: the reliability of agent output comes from the loop around the model, and that loop is something you design. The uncomfortable version is that right now, for most people, the harness is a person. You are the context assembler, the verifier, the recovery path and the router, holding it in your head, which is exactly the argument in you are the runtime. PaellaDoc is a harness you do not have to be: the context contract, the gates, the recovery and the routing built as a system, portable across engines, so the loop survives outside one operator’s memory. Not a better model. A better loop around whatever model you run.
FAQ
What is harness engineering?
It is the emerging practice of building and tuning the loop a coding agent runs inside: how context is assembled, which tools the agent can call, how output gets verified, and how failures get recovered. The term is used loosely across the agent-operations community, including Anthropic’s engineering writing, to name the system around the model as opposed to the model itself.
Is the harness more important than the model?
Once the model is good enough to write correct code from correct context, yes, the harness becomes where reliability is won or lost. In a controlled recovery test, the same coding agent plateaued or reached 100% depending only on the loop around it, not the model. Below that threshold the model still matters; above it, the harness dominates.
How is a harness different from just prompting well?
A prompt is one input to one call. A harness is the whole loop: it assembles context across many calls, runs tools, verifies output against gates, recovers failed runs, and moves work between sessions. Good prompting is part of it, but a prompt with no verification, no recovery and no context management is not a harness, it is a single throw of the dice.