What is Harness Engineering

For a long time I thought a better agent meant a better model, and a lot of people still do. Swap in the smarter one, get better results. That is true right up until it is not, and the place it stops being true finally has a name: the harness.

How We Got Here

A few years ago AI went mainstream. Once the thrill of talking to a chatbot and watching it print careful, human-sounding words wore off, the next wave arrived: AI that writes code.

The first coding assistants were barely more than skeletal wrappers around a raw model. Cursor, Bolt, and v0 were my introduction, and they mostly worked by scaffolding a pile of predefined prompts and instructions to steer the model in the right direction.

Then came vibecoding. Agents were, and still are, sold as a god in your pocket: do and undo, create and destroy, all from a few keystrokes or a spoken sentence. They got faster and smarter, but the mistakes kept coming, and every new version promised to fix the last one's.

What actually fixed them was not a smarter model. It was the scaffolding built around it — the thing we now call harness engineering.

The hard lesson underneath it is that models are brilliant and completely untrustworthy. They will lie, break things, and walk over system-level instructions to satisfy whatever a user wants in the moment. A nuke in a child's hands is still a nuke. You cannot treat a model like a person and hope it behaves. You enforce rules, you build guardrails, and you hand it the right tools — and only then does it do genuinely great work. That is why we can confidently ship real code today with Claude Code, Codex, and OpenCode: we are trusting their creators to get the harness right.

Agent = Model + Harness

It looks like a throwaway formula, but it is the whole idea, so it is worth reading slowly.

Agent = Model + Harness

The model is the raw intelligence: the weights that turn a prompt into tokens. It reasons, writes code, and plans. On its own, though, it cannot actually do anything. It has no hands. It cannot open a file, run a test, or remember what it tried five minutes ago. It is the part you buy, and the part you cannot change.

The harness is everything else in the system: the tools it can call, the context it sees, the memory it keeps, the checks on its work, and the boundary it is not allowed to cross. It is what gives the model hands to act, eyes to see what happened, and a leash so it cannot wander somewhere it should not.

The agent is neither half on its own. It is the two composed, and the plus sign is the part people skip. Capability does not come from a smarter model alone. It comes from a model wired into a harness that lets it act, see the result, and get corrected.

Harness engineering is the practice of designing that second half so a capable model becomes a reliable one.

The Autonomy Gap

Zhong and Zhu put it precisely in AI Harness Engineering: autonomous capability comes from a model, harness, and environment working as one system — not from the model alone.

The question stops being "Is the model smart enough?" and becomes "Can the system produce a verifiably correct, attributed, and maintainable change?"

The distance between what a model can do in the small and what it can actually finish on its own — that distance is the autonomy gap. The harness is how you close it.

The Anatomy of a Harness

Read enough about harness engineering and the same shape keeps surfacing. The one-line definition is easy, but underneath it sits a whole discipline. It decomposes cleanly into six areas that build on each other.

Harness Engineering
│
├── Core Philosophy ──── system not model · autonomy gap · claim to evidence
├── Five Subsystems ──── context · tools · memory · observe · verify
├── Regulation ────────── budgets · permission boundary · failure taxonomy
├── Implementation ────── H0 to H3 ladder · reproduce to report
├── Key Principles ─────── P1 to P5 · verify, not assert
└── Technical Components ── responsibilities · traces · outcome labels · metrics

Core Philosophy — the one move everything rests on. The agent is a system, not a model. The autonomy gap is what you are closing. "Done" has to be evidence rather than a claim.

Five Subsystems — every harness needs context, tools, memory, observability, and verification — and a trace each one leaves so you can see what it did.

Regulation — a harness as control over scarce resources. The budgets and permission boundary it enforces, and the failure taxonomy you attribute a break to before patching it.

Implementation Models — you do not build it all at once. The H0 to H3 ladder adds one class of runtime support at a time, ending in the reproduce → attribute → fix → verify → report loop.

Key Principles — the five rules that hold a harness up, from exposing runtime resources to attributing a failure before recovering from it.

Technical Components — the concrete responsibilities and the artifacts they emit, bundled into an episode package with an outcome label. This is what makes the whole thing measurable.

The Five Subsystems

Every harness is built from the same five subsystems. Get one wrong and the whole system degrades.

Context — everything the model can see. The system prompt, conversation history, retrieved documents, tool results, and current task state. Context quality is the single biggest determinant of output quality. Garbage in, garbage out. The harness controls what goes in.

Tools — functions the agent can call to act on the world. File access, code execution, web search, API calls, database queries. The harness defines which tools exist, what they can do, and what they cannot. An agent without tools is a text generator. An agent with the wrong tools is a liability.

Memory — what the agent retains across steps and sessions. In-context memory is the conversation window — fast but limited. External memory is retrieved and injected — slower but persistent. The harness manages what gets stored, what gets retrieved, and how retrieval quality is maintained over time.

Observability — how you see what the agent did. Every tool call, every reasoning step, every decision should emit a trace. Without observability, debugging is guessing. With it, failures have a location and a cause.

Verification — the checks that determine whether output is correct before it ships. Did the code run? Did the tests pass? Did the change break anything? Verification is the harness checking the model's work. Without it, "done" is just a claim.

Why Most Agent Failures Are Harness Failures

The instinct when an agent makes a mistake is to blame the model. Usually the model is not the problem. The harness is.

Context failures — the agent had the wrong information, incomplete context, or stale retrieval. It produced a reasonable answer to the wrong question.

Tool failures — the agent called a tool it should not have, used a tool incorrectly because the interface was ambiguous, or hit a tool that had no error handling.

Memory failures — the agent forgot relevant context, retrieved the wrong chunk, or made contradictory decisions across a long session.

Observability failures — nobody knew the agent was going wrong because there were no traces. By the time the failure was visible, the damage was done.

Verification failures — the agent said it was done. It was not. There was nothing in the harness to check.

Each failure maps to a specific subsystem. Engineers who understand the harness diagnose failures in minutes. Engineers who blame the model spend hours on the wrong problem.

What This Means in Practice

The model is the part you cannot change. You pick it, you prompt it, you update it when a better one ships. But the harness is yours. The context window, the tool interfaces, the memory architecture, the traces, the verification gates — all of it is yours to design and yours to get right.

A bad model in a good harness produces acceptable results and improves as models improve. A good model in a bad harness produces unreliable results and gets worse as it takes on harder tasks.

The people building reliable AI products in 2026 are not the ones who found the best model. They are the ones who built the best harness.