What is an agent harness? The code around the model that decides what actually runs
- glossary
- agent-harness
- agent-ops
What is an agent harness? It is every piece of software around a language model that turns the model's words into work: the loop that picks the next step, the tool list it may reach for, the gate an action has to clear before it lands, and the record it leaves behind. The model writes text. The harness decides whether that text becomes a command, a file edit, or a question back to you.
- The plain definition. Agent = model + harness. The harness is all the code, configuration and execution logic that is not the model itself.
- Why it exists. A raw model can only answer. Something has to run the answer, feed the result back, stop the loop, and keep a log.
- What is in one. System prompt, tools and their descriptions, a filesystem or sandbox, orchestration of subagents, hooks that run without the model's consent.
- Where you feel it. The same model behaves differently in two harnesses, because the rules live in the harness, not in the weights.
- The honest limit. A harness enforces the shapes you wrote down, and nothing else.
I unpacked this definition against a launch in the agent harness design post, where Meta's Muse Code gets read the way this entry says to read one.
The plain definition
An agent harness is the runtime around a model. LangChain's anatomy of an agent harness (Vivek Trivedy, 10 March 2026) puts it in one equation: "Agent = Model + Harness". The sentence under it does the rest of the work. "A harness is every piece of code, configuration, and execution logic that isn't the model itself." Microsoft's Agent Framework docs say the same from the runtime side: "the runtime scaffolding that turns a language model into an agent that can perform work. It drives model and tool calls, manages conversation state and context, applies approval policies, and can keep the agent progressing through a multi-step task."
The four-word version I settled on while reading Meta's launch is in the agent harness design post: loop, tools, approvals, record. Writing is the model's half. Running is the harness's half, and so is deciding what happens after a run dies.
Why is it called an agent harness?
The name reads as a borrowing from the older software term, the test harness: the scaffolding that runs code under controlled conditions and records what came out. Here the thing under test is a model, and the scaffolding decides what its output is allowed to do.
What it means in practice
The parts are boring on their own and decisive together. LangChain sorts them into five groups. System prompts are the first. Tools, skills and MCP servers are the second, together with the descriptions that tell the model they exist. The third is bundled infrastructure: a filesystem, a sandbox, a browser. The fourth is orchestration, which spawns subagents, hands work off and routes between models. The fifth is hooks and middleware, and it covers the steps that must not wait for the model to agree: compaction, continuation, lint checks. Microsoft's capability matrix names the same family from the other side. Function invocation runs under an iteration limit. History persists after each model call. Then compaction, tool approval, background agents, shell execution and bounded looping.
The rules live in the harness. Directory allow lists, the actions that stop for a person, what the log has to contain, and how a job resumes after it dies halfway. Swap the model and those rules stay. Swap the harness and you move all of them, which is why changing coding agents costs more than the install.
The model is a component. DeepSeek's harness publishes the list of what you can replace and what you cannot; I went through it in the DeepSeek Harness post. The model adapter is a seam with several implementations. The session log is not. That ordering, log above model, says what a harness is for.
What's the difference between an agent and a harness?
An agent is the running whole: a model inside a harness, doing a task. The harness is everything in that whole except the model. LangChain's equation makes the split exact. It also explains a common confusion: two products on the same model are two different agents, because the code around it is different code.
What is a harness for an AI agent?
For the operator it is where control lives. A prompt asks the model to behave. The harness enforces it. A hook reads every command before it runs. A sandbox limits what that command can reach. An approval step waits for a person, and a log survives the crash. Benchmarks describe the model. The harness describes the bad day.
Examples of agent harnesses
Four are worth naming right now: one I run, three I have only read. A terminal coding agent is the obvious shape and a library the less obvious one; the same word covers both, because both hold the loop, the tools and the approvals.
What are examples of agent harnesses?
Every terminal coding agent is one. Claude Code, the one
I run daily, is a harness with a swappable model. Meta's Muse Code and
DeepSeek's dsh, open source under the MIT license, are harnesses I have read
but not run. Microsoft ships one as a library and you supply the chat client.
The entry points are HarnessAgent in Agent Framework for .NET and
create_harness_agent in Python. Todo tracking, plan and execute modes and
observability are on by default. Standing approvals and auto-approval rules for
tools are on by default too, but the default rule set is empty: the docs say no
heuristic rules are configured, so an approval-marked call still comes back to
the person, and a standing rule only starts answering after they have answered
once. DisableToolAutoApproval in .NET and disable_tool_auto_approval in
Python remove that middleware, not the approval requirement on the tool itself.
Is Claude Code an agent harness?
Yes, and my own rules sit on it. The loop, tool list, permission prompts and transcript live in the tool, and the model inside is a component I can change. Four pieces decide when a run stops, when a command has to stop for a person and what ships, and none of them waits for the model to agree.
A PreToolUse hook reads every shell command before it runs: a 79-line script
with 13 danger patterns and one document gate, always answering "ask", and 16
regression cases, all green on 10 August 2026. The write-up is
the PreToolUse post.
/goal is Claude Code's, not mine.
It sets a completion condition. After each turn a small fast model reads the
conversation and returns one of three verdicts: met, not yet met, impossible.
The docs name the constraint: the evaluator "doesn't run commands or read files
independently", so the condition I write has to name the proof Claude will
surface.
A judge agent reads what the writing agent produced: each post in this batch goes to a fresh context, with the sources fetched again instead of remembered. And the publisher that put this page online is a script with no model in it, which only ships a post that passed the judge and me.
Two of those four are my code and two are Claude Code's own machinery. All four are harness. The tool supplies the events and the evaluator; the shapes, the conditions and the rubrics are mine.
What people get wrong
| People say | What is true |
|---|---|
| A harness is a framework | A framework is a library your code calls. A harness is the running system that calls the model, runs its tools and holds the rules. A framework can be part of one; it is not the whole |
| A harness is MCP | MCP is one way to publish tools to a model, covered in the MCP entry. The harness decides whether and when a tool gets called, and what happens with the result |
| The agent is the model | Agent = model + harness. Two products on the same model are two agents |
| Swapping the model swaps the agent | The rules stay where they were. Only the component that writes text changed |
| The harness is the chat window | The window is a surface. DeepSeek ships its web interface as a plugin next to a headless runner; the harness is what runs either way |
One example from my own work
The cleanest demonstration is one model, one tool, two runs.
Claude Code's non-interactive mode has a flag for scripts,
--bare. The docs say what it
drops: "skipping auto-discovery of hooks, skills, custom commands, subagents,
plugins, MCP servers, auto memory, and CLAUDE.md". Without the flag, the docs
say, a -p session "runs the hooks in a project's .claude/settings.json and
connects the servers in its .mcp.json".
Read that list against my own setup. In bare mode my command hook does not fire, my memory index is not loaded, my project skills do not load, and my MCP servers never connect. The model is identical. Everything the flag drops is harness.
My hook has 13 shapes because I met 13; the fourteenth passes until I add it. That is the reason to keep the log, so the fourteenth shows up in the record instead of in production.
Where to go deeper
The Muse Code post has the event log. The DeepSeek Harness post has the seams and the spine. Production-ready AI agents has the gate list, and what an AI agent is sits one level up.
Sources: LangChain, The Anatomy of an Agent Harness (10 March 2026); Microsoft Learn, Agent Harness (published 29 July 2026, updated 25 August 2026); Claude Code docs, Run Claude Code programmatically; Claude Code docs, Keep Claude working toward a goal; DeepSeek, Harness. All read on 4 September 2026.