The model is the engine. The harness is the car.
Give the exact same model a task with no tools and it flails. Give it the ability to read, run, and retry, and it succeeds, without getting one bit smarter. Most 'the AI cannot do this' is a harness problem. Bolt the pieces on and watch the number move.
The task: fix the one failing test in a 40-file repo. Same model throughout.
Bolt on the harness
Task success rate · illustrative
8%
What the run looks like
Blind. The model guesses which of 40 files is wrong, edits one, and has no way to check. It confidently reports a fix that never even compiled.
Same model, 8%. Not one point of that came from the model getting smarter. It all came from the harness around it.
What a harness actually is
The harness is everything around the model call: the tools, the environment, the loop, the context management, the memory. It is where almost all the engineering lives.
The model is fixed, the harness is yours
You rarely change the model. You constantly change what it can see, do, and check. That surface area is the harness, and it is where results are won or lost.
Verification is the highest-value piece
The biggest single jump is giving the model a way to check its own work and try again. Read plus run plus loop turns guessing into self-correction.
Capabilities have prerequisites
A retry loop is worthless without a way to run and observe. Adding capabilities in the wrong order buys nothing. The harness is a system, not a checklist.
The same harness idea, three altitudes
Claude Code and your internal coding agents are harnesses. So is a three-line tool loop. Same shape, different scale.
The concept
A harness is a loop that gives the model tools, runs the ones it asks for, feeds the results back, and lets it verify and retry until the goal is checked as met.
tools = [read_file, edit_file, run_tests, search_docs]
while not verified:
step = model(task, history, tools) # think
result = execute(step.tool_call) # act (in a sandbox)
history.append(result) # observe
verified = run_tests().all_passing # check its own workThe point: tools, a verify-and-retry loop, and a sandbox are the concept. A raw loop, a tool-runner SDK, or a full coding agent are the same idea at three scales.
Where harnesses fail
Each of these is a capability you toggled, or forgot to.
Blaming the model for a harness gap
The model "cannot" fix the bug, so the team reaches for a bigger model. The real problem was that it could not run the tests, so it never knew its fix was wrong. A better harness beats a bigger model here, at a fraction of the cost.
What good engineering does → before upgrading the model, ask what it could not see, do, or check. Usually that is the fix.
The harness with no sandbox
You gave the agent a shell and file access on a real machine. One confused or injected instruction and it runs a destructive command with your permissions. Capability without isolation is a loaded gun.
What good engineering does → every tool the agent can call runs in a sandbox with least-privilege scopes, so a bad step is contained, not catastrophic.
The harness that could not verify
The agent reports success, but nothing in the harness actually checked the result, so "done" just means "the model said done". You ship a fix that never passed a test.
What good engineering does → the harness, not the model, owns the definition of done: a real check (tests green, output validates) gates every success.
In the interview
"An agent keeps failing a task you think it should handle. Walk me through what you change."
Not the model, first. I ask what the harness is missing: can it read the relevant files, run and observe a real check, retry on failure, and is each capability actually wired (a retry loop needs a runner). Most "the AI cannot do this" is a missing tool or a missing verification loop. You change the harness before you change the model.
On your real stack
Give one agent a way to check its own work.
Find an internal agent that reports success without verifying it, and add one real check (run the tests, validate the output) that gates "done". It is the single highest-leverage change you can make to an agent’s reliability.
One lesson of the masterclass
Engineer the surroundings, not the model.