What is an agent harness?
An agent harness is the layer around a language model that turns single model calls into an agent: it runs the loop, executes the tools the model asks for, manages the context window, and decides what the model is allowed to do.
This page is written in English. The terms it explains are the ones people search for in English, and a translated term of art is a changed term.
Where the boundaries are
The word is easiest to pin down by elimination. A running coding agent is four layers deep, and only two of them are the harness. Below it is a model you did not train and an HTTP API you do not control; above it is whatever draws the output on a screen. The harness is everything in between, which is to say: everything that has to be decided.
| Layer | Owned by | What it decides |
|---|---|---|
| Model weights and inference | The provider | Anthropic, OpenAI, Google, or a runtime on your own machine. |
| Wire format | The provider | Each vendor's own HTTP shape for messages, tools and streaming. |
| Agent loop | The harness | Call, read the response, run what it asked for, call again, stop when it is done. |
| Tool execution | The harness | Validating arguments, running the tool, and deciding what runs in parallel. |
| External tools (MCP) | The harness | Discovering servers, namespacing their tools, speaking JSON-RPC to them. |
| Context | The harness | What stays in the window, what gets compacted, what is recalled from earlier. |
| Permissions | The harness | What the agent may do without asking, and what it must ask about first. |
| Rendering | The frontend | A terminal, a browser, a desktop window, or no display at all. |
Read the table downward and the reason the term exists becomes obvious: the two rows at the top change every few months, the row at the bottom is a matter of taste, and the five in the middle are where every hard decision in an agent actually lives. Naming that middle is what the word does.
Why model-agnostic is the hard part
Almost every harness is written against one vendor and adapted to others afterwards. That order is the problem: the first vendor’s assumptions end up in the conversation store, in the tool schema, in how a streamed response is parsed — places nobody thinks to look later. Switching then means a migration, and a migration in the middle of a session means you do not switch.
The alternative is to store history in a format that belongs to no vendor and render it into a vendor’s wire format at the moment a request goes out. Nothing is converted when the model changes, because nothing was ever in the old model’s shape. That is the single design decision OHarness is built around, and the architecture page describes how the layering is enforced rather than merely intended.
Harness, framework, SDK
- An SDK gets a request to a model and a response back. One call, one vendor, no memory of the last one.
- A framework gives you parts to assemble an agent from. You still decide the loop, the retries, the compaction policy — and you own them afterwards.
- A harness is the assembled thing. The loop, tool execution, context management and permissions are already decided; you supply tools, a model and a policy.
The practical test is what happens on the day you want a different model. With an SDK you rewrite the call site. With a framework you find out how many of your own parts assumed the old vendor. With a harness built for it, you change one setting.
Common questions
Is an agent harness the same thing as an agent framework?
They overlap, and the useful distinction is what you end up holding. A framework asks you to build an agent out of its pieces — you write the loop, the graph, the retries. A harness is the loop, already written: you give it tools, a model and a set of permissions, and it runs. Most frameworks can be used to build a harness; a harness is the thing you would otherwise have built.
If a vendor already ships an SDK, do I need a harness?
A vendor SDK gets you to a model call and stops there. It has no opinion about when to call again, what to do with a tool result, what to drop when the context window fills, or whether a shell command should run without asking. Those decisions are the harness, and if you do not adopt one you will write one — usually by accident, spread across a codebase, against exactly one vendor.
Can one harness talk to more than one model provider?
It can, but only if it was built that way from the start. The hard part is not the HTTP: it is that conversation history, tool definitions and streamed output all have a vendor-shaped form, and a harness that stores history in one vendor's shape has to migrate it to switch. Storing history in a neutral form and rendering it into a vendor's wire format at the moment of the request is what makes switching free.
Is there an open source agent harness?
OHarness is one, under the MIT licence. It speaks natively to Anthropic, OpenAI and Google Gemini, to any OpenAI-compatible endpoint, and to local runtimes such as Ollama, LM Studio and vLLM — and it runs in a terminal, a browser, a desktop app and headless, all on the same engine.
Read the implementation
OHarness is an open source agent harness under the MIT licence: one runtime dependency, every provider reached over plain fetch and SSE, and its own MCP client. The documentation is written beside the code it describes, and the download page has the desktop builds and the command line.