What Is an Agent Harness? (And Why Every Harness Needs a Control Plane)
An agent harness is everything around the model that turns it into a working agent: the loop that runs it, the tools it can call, the context and memory fed into each turn, the verification, the budgets and limits, and the logging. The model decides; the harness acts — and the harness is where cost, reliability, and risk actually live.
There’s a line going around that names the thing everyone building agents has been circling: Agent = Model + Harness.
The model is the part everyone talks about. The harness is everything else, and it turns out to be most of the system.
The model is the smallest part
Give a frontier model a prompt and it returns text. That’s not an agent. An agent does things: it reads a ticket, searches the web, queries a database, drafts a reply, sends it — looping, checking its own work, deciding what to do next.
None of that is the model. The model decides; the harness acts. The harness is:
- the loop that runs the model again and again until the task is done,
- the tools it can call, and how their results are fed back in,
- the context and memory — what gets loaded into each turn, and what gets trimmed,
- the verification — the checks that run before a result reaches a user,
- the budgets and limits — how much a run may spend, how long it may go,
- and the logging of everything that happened.
Swap the model for a better one and a bad harness still produces a bad agent. Keep the model and fix the harness, and the same model ships. Practitioners have a phrase for it: the gap between what a model can do and what you actually see it do is a harness gap. Closing that gap is harness engineering — its own discipline now, with Thoughtworks, Databricks, LangChain, and MongoDB all writing about it.
Harness engineering is where the cost and the surprises live
Once you see agents as harnesses, the weird behavior makes sense.
An agent that costs 1.2¢ one run and 2.2¢ the next isn’t a flaky model — it’s a harness whose loop ran a different number of turns. The bill that balloons on a “simple” task is the harness re-reading its whole context on every turn; on most agents, the majority of the token spend is re-reading, not new work. The run that takes three different paths to the same goal is the harness’s loop diverging. These are harness properties, and they’re measurable: turns, re-read multiple, path variance, cost per step.
Harness engineering turns an agent’s behavior into something you can see and tune instead of a black box that hands back an answer.
But the harness creates problems it can’t solve itself
The harness diagrams leave a part out. The moment your harness is calling real tools, spending real money, and acting on behalf of real users, you inherit a set of problems that live below the harness — at the boundary where it touches your tools and your backends:
- Identity. When the harness calls your API, who is it acting as? The user who triggered it? The agent? The framework’s service account? (This is the three-party problem — and most harnesses paper over it with one shared key.)
- Authority. What is this harness allowed to do? Can it delete, pay, email the whole company? A harness will call any tool you hand it; it has no opinion about which calls are dangerous.
- Cost. What is it spending — per agent, per tool call — and can you cap it before a runaway loop bills you $400?
- Control. Can you stop it? Block one caller who’s abusing it? Deny one tool without a redeploy?
- Evidence. Can you show an auditor every action it took, as a specific user, with the result?
These aren’t harness engineering problems. You can build a good harness and still have all five. They’re governance problems, and they’re cross-cutting — they apply to every tool call the harness makes, no matter which framework it’s built in.
The field is starting to draw the line explicitly: observability tells you what the harness did; governance controls what it’s allowed to do. Traces and logs are read-only. Identity, policy, budgets, and blocks are enforcement. A harness needs both, and harness engineering by itself gives you neither.
Every harness needs a control plane
This is why the harness conversation keeps arriving at the same place — the AI control plane.
A control plane sits between the harness and the tools it calls, and handles exactly the five things the harness can’t:
- it gives the agent a verified identity on every call,
- it enforces policy — allow, deny, or require approval, per tool and per action,
- it prices every call, so you see the loop tax and can cap it,
- it gives you a kill switch — for the whole agent, or for one caller,
- and it writes the audit trail — every action, attributed, with its result.
Because the control plane lives at the tool-call boundary, it works across any harness: Claude Code, LangGraph, CrewAI, the Anthropic SDK, or one you wrote yourself.
Anyone shipping a real agent ends up engineering a harness. A harness in production also needs a control plane under it. Call it a control plane, a governance layer, an agent gateway — the name matters less than the layer existing. You engineer the harness for capability; you put a control plane under it for identity, cost, and control.
(Full disclosure: we build one — the Agentic Control Plane — which is why we’ve spent so long staring at harnesses. But the argument stands whatever you run.)