Harness Engineering - Why your AI agent isn't a model problem

Part 1 of a 6-part series about Harness Engineering 

The bottleneck keeps moving 

Ask a team why their AI agent pilot stalled and you will usually hear some version of the same answer: we're waiting on a better model. It is a comfortable answer, because it puts the fix outside the building and on someone else's roadmap. It is also, most of the time, wrong. 

Look at how quickly the constraint has moved in three years. 

• 2024 — Prompt engineering. Output quality tracked closely with phrasing. Teams built libraries of prompt patterns, and for a while, job postings existed for little else. 

• 2025 — Context engineering. Phrasing mattered less than what you put in front of the model. Retrieval, document selection, and window management became the differentiator. 

• 2026 — Harness engineering. Prompting and context are now largely solved problems with well-known patterns. What separates a working demo from a production system is the execution layer built around the model. 

Each wave absorbed the one before it rather than replacing it. Prompting did not stop mattering; it stopped being the thing standing between you and a system that works. The same is now true of context. The bottleneck has moved to the code around the model, and most enterprise AI programs have not moved with it. 

What a harness actually is 

The model holds the raw intelligence. The harness is what makes that intelligence reliable. 

Concretely, a harness is everything sitting between the model and the real world. It dispatches tool calls and validates them. It verifies output before that output reaches anyone. It decides what enters the context window and what gets written to durable memory. It enforces permissions. It logs what happened and what it cost. 

None of this is something a model can do for itself, and that is not a criticism of any particular model. A language model does exactly one thing: it takes a context window and returns tokens. It cannot independently check its own work against reality, it cannot remember anything you did not put in front of it, and it cannot decline to take an action it should not take. Those are properties of the system around it. 

The model is the engine. The harness is the car. Nobody ships an engine and calls it a vehicle. Buyers want steering, brakes, a chassis, and a fuel gauge — and every organization still choosing agent platforms on the basis of “which model” alone is answering last year's question. 

What it looks like when the harness breaks 

The cleanest evidence that the harness is the variable is what happens when it changes and the model does not. 

In April 2026, Anthropic published a postmortem on roughly six weeks of quality complaints about Claude Code. Users were convinced the model had gotten worse. It hadn't. The API and the model weights were untouched. The investigation traced the degradation to three independent changes in the product layer around the model: a default reasoning-effort setting quietly downgraded from high to medium to fix a UI latency issue; a caching bug that was supposed to clear stale reasoning history once but instead cleared it on every turn for the rest of the session; and a system-prompt change capping response verbosity that, in testing, also cost about three percent in code generation quality. 

Three harness-level decisions, none of them unreasonable in isolation, compounding into a visible quality problem that thousands of engineers experienced as “the model got dumber.” Same model, different harness, different results. 

This is worth sitting with, because it cuts both ways. If the harness can silently degrade a frontier model, the harness can also be the thing that makes a mid-tier model reliably useful. That is a much better place for an enterprise to be spending its engineering effort than waiting on the next release. 

Why most agents stall 

IDC's research puts it starkly: roughly 88 percent of enterprise AI agent proofs of concept never graduate to production. Other analyst estimates land in the same range. The striking thing is not the number, but how rarely the cause is model capability. The recurring failure modes are all harness failures. 

• Context rot. The constraint you established in the first turn gets summarized away by turn fifteen, and the agent proceeds confidently without it. 

• Self-grading. An agent asked to review its own work approves almost all of it. Making the maker and the checker the same entity removes the only mechanism that catches errors before a user does. 

• Tool escalation. Without a permission layer, an instruction injected through something as ordinary as a ticket comment or a code repository issue can reach a shell. 

• Silent drift. A provider ships an update and behavior shifts with no code change on your end. Without tracing, you learn about it from your users. 

• No persistence. Every session starts from zero and re-learns the same lessons, forever. 

• Runaway cost. A retry loop with no budget ceiling, discovered on the invoice. 

Not one of these is fixed by a smarter model. Every one of them is fixed by engineering. 

What a harness will not fix 

Three honest limits, because a discipline that claims to solve everything solves nothing. 

A harness cannot rescue a vague task definition. The best-instrumented system in the world will reliably and repeatedly produce the wrong thing if nobody has agreed on what the right thing is. Second, harnesses can be over-built. Every approval gate adds latency, and a harness designed for a regulated bank will feel like filing taxes if you drop it into an internal prototyping team. The correct amount of harness is a function of blast radius, not of ambition. Third, and most easily forgotten: the harness is infrastructure, not product. Nobody buys a harness. They buy what the agent produces. The harness is only interesting because it is the difference between an agent that produces something and one that does not. 

Where to start 

You do not need all seven layers on day one, and trying to build them all at once is its own failure mode. Add each layer as the pain that justifies it actually appears. 

Start with tool permissions and a basic verification step — those two, on day one, prevent the categories of failure that are hardest to recover from. Add memory when sessions start repeating themselves. Add guardrails before an agent touches anything customer-facing. Add observability when you need to prove to someone that this is working. Add routing when the cost curve gets uncomfortable. Add feedback when you are tired of watching the same mistake recur. 

If you want a single metric to anchor the whole effort, use cost per accepted change: what actually shipped, measured against everything it took to get there. Not tokens consumed, which measures activity rather than value, and not tasks attempted, which measures optimism. Cost per accepted change is the number that tells a team running the same model as everyone else whether their harness is paying for itself. 

The question to be asking 

Model capability is no longer the interesting variable in enterprise AI. It is broadly available, it is improving on a schedule nobody controls, and your competitors have access to the same models you do. 

What is not evenly distributed is the engineering discipline to build a reliable system around one. That is the gap between the organizations running agents in production and the 88 percent still running pilots. It is a harness problem, and harness problems are solvable with the skills most enterprise engineering organizations already have — once someone names the problem correctly. 

This is the first article in a series on harness engineering. Subsequent pieces will take each layer in turn.