What Is a Harness in AI Agents?
When people discuss AI agents, the conversation is always about the model: which one is smarter, which is cheaper. Yet two agents built on the same model can behave completely differently — one finishes the job, the other stops halfway. The name for that difference is the harness.
The metaphor is literal. The horse supplies the power, but what pulls the cart is the harness — it decides the direction, how the load is attached, and when to stop. A harness is that apparatus around the model.
What a harness does
Three jobs:
It manages context. On a long task, the output of every step accumulates and the model eventually fills its own context window. The harness decides what is kept, what is summarised, and what is dropped.
It manages tools. It determines what the model can reach at each moment: file reads, shell commands, web search, database queries. Leaving every tool open at every step is not a good default.
It manages the loop. Who keeps the “model answered, called a tool, read the result, thought again” cycle going? When does it stop, and when does it hand work to a sub-agent? The harness sets that.
Why it matters — three typical failures
Anthropic’s own engineering write-up describes three recurring failures in agents running in a single context. I’ve seen all three in practice:
Agentic laziness. The model declares the job done before it is. Half the work is complete and the report says finished.
Self-preferential bias. Asked to review its own output, the model approves it. When something checks its own work, its hit rate for finding faults drops.
Goal drift. On long tasks the original instruction dilutes; ten steps later the model is optimising for something else.
None of these is a weakness of the model — they’re weaknesses of the apparatus. And the fix isn’t a better model: have a separate agent do the review, split sub-tasks into clean contexts, restate the goal each turn.
Who supplies the harness
In practice there are four options, and the distinction is who supplies the harness and who supplies the hosting:
| Approach | Who writes the harness | Where it runs |
|---|---|---|
| Hand-written loop | You | Your infrastructure |
| The SDK’s tool runner | The library | Your infrastructure |
| Claude Agent SDK | The library (with built-in tools) | Your infrastructure |
| Managed agents | The provider | The provider’s infrastructure |
The point that trips people up: a library supplying a harness does not mean it also supplies hosting. In the first three, the servers are still yours.
What this means in practice
When an agent project isn’t delivering, the first instinct is to move to a stronger model. Usually that isn’t the problem: the task is too long for one context, the tools are broader than needed, and there’s no review step.
That’s exactly why multi-agent systems exist — splitting the work does more than swapping the model. I described the setup I use in my agentic stack.
Frequently Asked Questions
Is the harness the same as the model?
No. The model is the brain; the harness is what puts it to work. Run the same model under a different harness and the result changes noticeably.
Is a harness the same as a framework?
Close, but not the same. A framework is a general software skeleton; a harness is specifically the layer managing the agent loop, context, and tool access.
Should I write my own harness?
For most work, no — the existing ones already handle the loop. It’s worth writing your own when you need particular approval steps or sub-agents running in a specific order.
How does this touch my business?
If it doesn’t directly, you don’t need to know it. But if you’re receiving proposals to “build an AI agent”, look at what the proposal says about the harness: if there’s nothing about review, context management and stopping conditions, the proposal is incomplete.
How does it relate to RAG?
Different layers. RAG is about getting the right information to the model; the harness is about managing what the model does with it.