Me, and the AI thingy

Harness Engineering: The Machine Around the Model

An agent is a model plus a harness, and the harness is everything that isn’t the model. The weights are fixed. The machine around them is not. The harness is the runtime scaffold that turns a raw model into an agent: the loop, the tools, the context management, the sub-agents, the guardrails. Engineer that machine well and a fixed model measurably outperforms itself.

If context engineering writes the score, harness engineering builds the instrument that plays it. This piece is about the instrument.

TL;DR. An agent is a model plus a harness. The harness is every piece of code, configuration, and execution logic that isn’t the model itself (LangChain, 2026). METR calls the same thing a scaffold and treats it as load-bearing: a capability number without a named scaffold is close to meaningless. LangChain reports moving a coding agent from Top 30 to Top 5 on Terminal Bench 2.0 by changing the harness alone, model held constant. And harness engineering is not only what a lab does when it builds the loop. Most people do it from the outside, wiring tools, subagents, and guardrails around an agent they did not write. The harness is where reliability is won, because it is where context rules actually run.

Anatomy of an agent: a fixed model at the center, wrapped by a harness ring carrying labeled component chips for the loop, tools, context management, sub-agents, memory, and guardrails.

Agent = Model + Harness

Start with the definition, because the whole discipline follows from it. LangChain puts it as plainly as anyone: “A harness is every piece of code, configuration, and execution logic that isn’t the model itself.” And the corollary, which is the line worth memorizing: “If you’re not the model, you’re the harness” (LangChain, The Anatomy of an Agent Harness, 2026).

Böckeler, writing on Fowler’s site, reduces it to an equation: “Agent = Model + Harness” (Böckeler, 2026). Simon Willison says the same thing from the tool side: “A coding agent is a piece of software that acts as a harness for an LLM” (Willison, 2026). Three sources, one boundary. The model is the part you download. The harness is the part you build.

This matters because the two halves improve on different clocks. A new model arrives when a lab ships one. The harness you can change this afternoon. So if capability is set by both, the half you control is where your leverage lives. That is the reframe. The harness is not plumbing around the interesting part. On a fixed model, it is the interesting part.

The harness is the scaffold

The word is new. The thing is not. METR, whose evaluation work is about as rigorous as this field gets, was already calling it a “scaffold” in 2024. Same object, older name.

METR’s framing is worth stealing because it is careful about what it is measuring.

🔬 A number without a scaffold means little. Capability, they argue, should be read off “the best available scaffolding,” because the scaffold materially sets the measured ceiling (METR, Guidelines for capability elicitation, 2024). A model tested through a weak scaffold looks weak. The same weights through a strong one look strong. So a capability number without a named scaffold is close to meaningless.

Vendors landed on “harness” instead. Anthropic ships “a powerful, general-purpose agent harness” and documents its “context management capabilities such as compaction” (Anthropic, 2025). LangChain, Fowler, and Willison all use “harness” too. Scaffold, harness: read them as synonyms. I’ll use “harness” because that is where the practitioner discourse settled, but when METR says scaffold, it means this.

What a harness is made of

Break the machine into parts. Six of them do the work.

The loop is the engine. Reason, call a tool, observe the result, repeat. Willison names the canonical shape: “LLM + system prompt + tools in a loop” (Willison, 2026). Everything else hangs off this cycle.

The agent loop as a cycle: the model reasons, calls a tool, observes the result, and repeats, with the system prompt seeding the first turn.

Tools and execution are the hands. File reads, shell commands, API calls, a code sandbox. The model proposes an action as text. The harness is what actually runs it and feeds the result back.

Context management is the editor. Compaction, truncation, summarization: the harness deciding what stays in the window and what gets dropped as the run grows. Anthropic lists compaction as a first-class harness capability (Anthropic, 2025). Hold onto this one. It is the seam with context engineering, and I come back to it.

Sub-agents and orchestration split the work. Anthropic’s long-running harness runs a Planner, a Generator, and an Evaluator, each with its own fresh context (Anthropic, Harness design for long-running application development, 2026). One model, several roles, coordinated by the machine.

Memory and state carry what the window cannot. File-based memory, scratchpads, context resets that reload from disk. The window is finite; memory is how the agent remembers past the point where the window forgets.

Guardrails and permissions are the brakes. What the agent may touch, which commands need approval, where isolation boundaries sit. Böckeler frames the harness in control-theory terms: guides that feed the model forward, sensors that feed results back (Böckeler, 2026). Guardrails are where you say no.

Anthropic gives the design rule that ties these together: “Every component in a harness encodes an assumption about what the model can’t do on its own” (Anthropic, 2026). Read your harness and you are reading your own list of the model’s limits.

Same model, better harness, higher capability

Here is the claim with a receipt. Hold the weights fixed, improve the machine, and measured capability goes up.

🔬 Same weights, better machine. LangChain took a coding agent, held the model constant at a single frontier model, changed only the harness, and reports moving it from Top 30 to Top 5 on Terminal Bench 2.0 (LangChain, 2026).

No new weights. A better instrument playing the same score.

This is exactly why METR insists that capability be read off the best available scaffold. The measured ceiling belongs to the pair, model and harness, not to the weights alone. Improve the half you control and the number moves, on a model that never changed. That is the argument for treating harness engineering as a discipline. When the model is fixed, and for most teams on most days it is, the harness is the lever still in your hands.

Most harness engineering happens from the outside

It is easy to read all of this as work for the people who build agents from scratch, the labs and framework authors wiring a reason-tool-observe loop. Some of it is. But most harness engineering today is done by people who never wrote the loop.

You adopt an agent someone else shipped, and then you engineer the harness around it. You choose the tools it can call and the MCP servers it can reach. You compose subagents and hand each one a slice of the work. You write the guardrails: which commands need approval, which paths are off limits, where the isolation boundary sits. You give it memory files and the instructions it reloads on every run. None of that is the model. All of it is the harness.

That is why Böckeler’s piece is titled “Harness engineering for coding agent users” (Böckeler, 2026), and why Willison writes about coding agents from the same practitioner seat (Willison, 2026). The discipline is not reserved for whoever compiled the loop. If you are shaping what an agent can touch, what it remembers, and what it can be stopped from doing, you are already doing harness engineering, whether you built the loop or only configured it.

The harness enforces what context engineering decides

Now the seam, because this is where the twin disciplines meet and where people talk past each other.

Draw the line by object. Context engineering engineers the content: which tokens earn a place in the window, curated fresh every step. That is judgment, taste, a decision. Harness engineering engineers the machine: the runtime that carries those tokens in and out. That is code. Context management is where they touch. Compaction is a decision about what matters, executed by a harness capability. The engineering decides; the harness enforces.

Two disciplines, one system: an outer harness wrapping the context window and the model, with context engineering deciding the content on the left and harness engineering running the machine on the right, meeting at context management.

I have to be honest that the field does not agree on how these nest. LangChain puts the harness on top: “harnesses today are largely delivery mechanisms for good context engineering,” so the harness contains the context work. Böckeler flips it: “a harness is a specific form of context engineering,” so context engineering contains the harness. Anthropic keeps the two vocabularies apart and does not nest them at all. Three respected sources, three containment stories.

So I am not going to pretend the hierarchy is settled. I draw a functional line and I say I am drawing it: content versus machine, decision versus enforcement. It is a working boundary, not a law. It has the one property I need, which is that it tells you which discipline owns which failure. If the wrong tokens were chosen, that is a context problem. If the right tokens were chosen and the machine dropped them anyway, that is a harness problem. For the content side of the seam, in its own words, go to the twin: context engineering, the content side.

Why leanness has to live here

This is the payoff, and it is where the brand thesis bites. A lean window is not something you hope for. It is something the machine enforces.

Think about who is being asked to keep the window lean. If the answer is “the model, by policing its own context,” you have already lost, because the model cannot see what it is not shown and has no incentive to spend fewer tokens. Good intentions do not compact a transcript. A capability does. Compaction is a harness capability (Anthropic, 2025). Truncation is a harness capability. Context resets that reload memory from disk are a harness capability. Leanness is a property you build into the runtime, not a discipline you ask the weights to exercise.

That is why the leanness argument lives here and not in the model. You do not count on the model to keep its own window clean. You enforce a lean window in the machine, the same way you enforce anything you actually care about: with code that runs whether the model cooperates or not. The harness is the enforcement layer. If it is not in the harness, it is a wish.

Hands off

This piece drew the machine side of the line. Its twin draws the content side: which tokens earn their place, and why curation is a decision discipline with human taste at the center. Read it next: context engineering, the content side.

Under both sits the mechanism. If “the window,” “compaction,” and “tokens” are doing heavy lifting and you want the machinery, see what a context window is. Cost, position, and rot all fall out of one line: the model rereads the whole window on every step.

And the harness capabilities named here each earn their own spoke. How to compile specs into executor scripts the harness runs. How custom linters become guardrails the loop cannot skip. How permissions and isolation get enforced at the boundary. Those are the machine, in detail. This was the machine, in outline.

Hold the one line. The model is fixed; the harness is not. Everything you can still change about what your agent reliably does, you change in the machine around the model.

Sources

harness-engineering primer reliability
Newsletter

One email a month — what I'm working through, and the posts it produced. One click to leave.

Malo Couaran
Got a reaction, a correction, or a better idea? Reply by email.