Model plus harness
A coding agent is a model and its harness: the tools it may call, the hooks that fire on every edit, the checks that decide whether its work counts, the review loop that looks at it before a person does, and the context it is given about the codebase it is working in. Take the same model, change the harness, and you get a different agent. Sometimes a much better one.
The number that convinced us sits in a public benchmark. On Terminal-Bench 2.0, a coding agent moved from the top thirty to the top five without touching the model: same weights, different harness. That is not a prompt trick. It is systems engineering, and systems engineering is what software companies are for.
What a harness does all day
Most of it is dull, which is the point. A hook that blocks a destructive command before it runs. A build that has to pass. Static analysis and a security scan on every change. A second agent, briefed to be sceptical, that reads what the first one wrote against the definition of done and sends it back until it holds. Only then a person, who now reviews with the noise already gone.
Written down, it looks like plumbing. In practice it is the difference between an agent you can let loose on a system that has to keep running, and one you can only use for demos.
Why the harness beats the model
A model is probabilistic. Ask it to never delete a file and it will almost always comply. Almost always is not a property you can build a rail-planning system on. A hook that refuses the command is deterministic: it fires every time, and it does not care how confident the model felt. So the rule we work by is to make the environment deterministic rather than trying to make the model so. Instructions are suggestions. Hooks, gates and checks are physics.
The second reason is that a harness learns and a model does not, at least not on your timescale. Every mistake an agent makes in our repositories becomes a check, a rule or a gate, so that exact mistake cannot happen again. The model you rent is the same one your competitor rents. The harness is yours.
What this means if you are buying software
Ask a supplier what their harness is. Not which model they use (that changes every quarter) but what decides whether agent-written code may be merged, who reviews it, and what happens when it goes wrong. If the answer is a document, it is a suggestion. If the answer is a gate you can see run, it is engineering.
Ours is written out on this site: the method on How we build, and the foundation the agents build on, Entry, open source. Read it before you call.