Harness Engineering: The Room Around the Model

In the spring of 2025, Thorsten Ball published a small tutorial called How to Build an Agent that did something quietly wonderful: it made the magic trick explainable. A working code-editing agent, the kind that reads your files, decides what to change, and changes it, turned out to be under 400 lines of Go, and most of those lines were boilerplate. His summary has been living in my head ever since: an LLM, a loop, and enough tokens.

I remember two feelings arriving at once. Relief, because something I had been treating as deep magic was suddenly legible. And then a question that took me much longer to phrase well: if the loop is a few hundred lines, why do agents built on the very same model feel so different from one another? Why does one stay coherent for six hours while another, same model, same task, wanders off after twenty minutes?

The industry has finally given the answer a name. Everything around the model is called the harness, and the craft of building it well is being called harness engineering. I think it is the most useful phrase to enter the field in the past year, and I want to lay out why, carefully, with the receipts.

The part that is not the model

Simon Willison, whose definitions have a habit of becoming the field’s definitions, settled on a compact one: an agent runs tools in a loop to achieve a goal. The model supplies the judgment inside the loop. The harness is everything else: the system prompt, the tools and their descriptions, the policy that decides what the model gets to see at each step, the memory that survives between sessions, the sandbox that makes it safe to act, the hooks that check the work, and the feedback loops that tell the agent how it is doing.

Vivek Trivedy at LangChain wrote the cleanest anatomy of this I have read, The Anatomy of an Agent Harness, and his framing is the one I would put on a whiteboard. Agent equals model plus harness, and if you are not the model, you are the harness. The essay’s quieter line is the one that stayed with me: “The model contains the intelligence and the harness makes that intelligence useful.”

This is measurable, which is the good part

What makes this more than a naming exercise is that the harness turns out to carry a surprising share of the performance. Earlier this year, the LangChain team took their coding agent from 52.8% to 66.5% on Terminal-Bench 2.0, moving from around thirtieth place to fifth, without touching the model at all. The gains came from things that sound almost domestic: middleware that notices when the agent is going in circles, a checklist it has to pass before declaring a task finished, better ways of showing the agent where it is. Same brain, better room.

Anthropic published a matching result from the other direction. In their engineering piece on harness design for long-running development, Prithvi Rajasekaran describes handing a large build to a single agent: it declared victory after twenty minutes and nine dollars, and the result barely worked. The same model, arranged into a harness of planner, generator, and evaluator agents, worked for six hours and produced something dramatically more complete. Two failure patterns kept showing up in the simple setup, and both are worth knowing by name. One is context anxiety, where a model senses the end of its context window approaching and starts wrapping up early, like a student watching the clock. The other is self-evaluation bias: asked to grade their own work, agents respond by “confidently praising the work” even when a human observer would call it mediocre. The strongest single lever the team found was separating the agent that does the work from the agent that judges it.

There is also a reason this discipline is arriving now rather than two years ago: the tasks are getting longer. METR’s research on task horizons found that the length of task an agent can complete with 50% reliability has been doubling roughly every seven months, and their more recent measurements suggest the pace has quickened since. A harness barely matters for a thirty-second task. Across a six-hour task it is most of what matters, because the harness is what keeps hour five coherent with hour one.

A short history of widening care

It helps to see harness engineering as the third chapter in a story about a widening circle of care. The first chapter was prompt engineering: care about the words. The second was context engineering, a term that took hold in mid-2025 when Shopify’s Tobi Lutke proposed it and Andrej Karpathy endorsed it, calling it “the delicate art and science of filling the context window.” Anthropic’s guide to context engineering gave that chapter its physics: models have a finite attention budget, performance degrades as the window fills, a phenomenon they call context rot, and the job is to find the smallest set of high-signal tokens that produces the outcome you want.

Harness engineering is the chapter where the circle widens from the window to the whole room. Addy Osmani, who has spent the past two years writing some of the most level-headed material anywhere on AI-assisted engineering, published an essay on agent harness engineering this April that I would hand to any team starting out. His central claim is cheerfully contrarian: a decent model with a great harness beats a great model with a bad harness. Instead of waiting for the next model to fix your agent, you treat each failure as a configuration problem you can do something about today. Dex Horthy at HumanLayer planted a similar flag earlier with 12-factor agents, arguing that much of what looks like a model limitation is, on inspection, a harness limitation. Osmani also points out something I find genuinely hopeful: the leading coding agents, Claude Code, Cursor, Codex, Aider, Cline, are converging on the same harness patterns despite running different models, which is usually the sign that a young field has found its load-bearing ideas.

The room around the model

Earlier this year I wrote about designing hallways instead of machines: drawing the room an agent is allowed to act in, rather than pretending to control its every move. Harness engineering is that instinct grown up and given a job title. After months of building and rebuilding these rooms in my own work, a few principles have earned their keep. I offer them as my reading of the evidence, not as settled fact.

Separate the doer from the judge. The self-evaluation bias in Anthropic’s data matches everything I have seen. An agent grading its own work is an author reviewing their own book, sincere and generous in equal measure. A separate evaluator, with its own context and its own incentives, catches what the generator has stopped being able to see.

Put the state where you can see it. LangChain calls the filesystem the foundational primitive of a harness, and Anthropic’s agents hand work to each other as plain artifacts on disk. When state lives in files, the handoffs are readable, and drift becomes visible before it becomes expensive. The agent’s memory should be something you can open in an editor.

Let failures become walls. Osmani calls this the ratchet: every mistake the agent makes gets converted into a permanent constraint, a line in the instructions, a validation hook, a tighter tool description, traceable back to the specific error that earned it. His companion principle is the one I would frame: success is silent, failures are verbose.

Date every wall. My favorite sentence in the Anthropic piece is this one: “Every component in a harness encodes an assumption about what the model can’t do on its own.” Models change underneath you, and assumptions expire. When a newer model arrived mid-project, the Anthropic team found they could remove whole layers of scaffolding, because the model no longer needed the help.

The honest tension

I want to be fair to the strongest objection, because I feel its pull. If every model generation deletes part of the harness, is harness engineering just scaffolding on a building that will eventually finish itself? The evidence here is genuinely mixed. Anthropic’s own experience, simplifying their harness as the model improved, supports the objection. What complicates it is that the frontier keeps moving outward: each time a model absorbs the old harness, teams point it at longer and harder tasks, and those tasks need a new room built around them.

My current view, held loosely, is that the individual walls are temporary and the craft of placing walls is not. Harness engineering is how you convert model progress into product progress on the day the model ships, rather than a quarter later. That translation layer has been valuable in every generation so far, and I would rather bet on the pattern than against it. But I hold this as a bet, and I notice the people I respect most in this field hold it the same way.

A small practice

If you build with agents, here is what all of this cashes out into, and I like how small it is. Keep a file of your agent’s failures. When one recurs, promote it into the harness: a rule, a hook, a checklist line. Keep that file short, on purpose; the discipline of the cap is most of the value, and the teams doing this best keep their agent instructions to a page. Then, when a new model ships, spend an hour doing the opposite. Pick a wall, take it down, and watch whether the agent still needs it. Half the craft is adding structure. The other half, the part that keeps it a craft rather than an accumulation, is taking structure away.

The loop will keep being a few hundred lines. The models will keep improving, on a curve that keeps surprising the people who measure it. What stays is the room: someone has to decide what the agent sees, what it can touch, who checks its work, and what happens when it is wrong. That someone is doing harness engineering, whether or not their title says so. I find this oddly comforting. The center of the field turned out to be a place where ordinary engineering care still compounds.

The studies and numbers here are real and linked, but the shape I have drawn around them, the room, the walls, the widening circle, is my framing and it could be wrong. I hold these views the way a good harness holds an agent: firmly, and ready to be revised when the next release argues back.