# What Is an Agent Harness? (And Why Every Harness Needs a Control Plane) The model is the smallest part of your agent. Everything around it — the loop, the tools, the memory, the budget — is the harness, and it's where reliability, cost, and risk actually live. Here's what an agent harness is, why harness engineering became a discipline, and the one thing every harness in production still needs. **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](https://martinfowler.com/articles/harness-engineering.html), [Databricks](https://www.databricks.com/blog/ai-harness), [LangChain](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness), and [MongoDB](https://www.mongodb.com/company/blog/technical/agent-harness-why-llm-is-smallest-part-of-your-agent-system) 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. One harness component deserves its own pattern language: the control layer — the mechanisms that constrain what the agent *may* do rather than what it *can* do. We have catalogued the eight patterns every harness converges on (prompt rules, permission prompts, pattern rules, approval classifiers, hooks, sandboxes, proxies, and independent ledgers) in [harness control patterns](/harness-control-patterns). ## 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](/blog/the-three-party-identity-gap) — 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](https://medium.com/@adnanmasood/agent-harness-engineering-the-rise-of-the-ai-control-plane-938ead884b1d). 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.)*