What Is an Agent Harness?
An agent harness is the software that turns a language model into an agent: the loop, the tools, the context and the limits. What each part does, with examples.
A language model on its own takes text in and gives text out. It cannot open a file, run a test or remember what it did ten minutes ago. Every coding agent that does those things has software around the model doing them. That software is the agent harness.
An agent harness is the software around a language model that turns it into an agent. It runs the loop, holds the tools, decides what the model sees and enforces the limits. The model proposes the next step; the harness decides what actually happens.
The four parts
The term is used loosely, so a definition helps. A 2026 paper defines an agent harness as the runtime engineering layer that wraps one or more language models and turns them into an agent. The paper names four conditions: an agent loop that interleaves reasoning, action and observation; tools that can change an external environment; context management that decides what enters and leaves the model's context; and at least one control that does not depend on the model's cooperation.
Model
Proposes the next step, as text.
Loop
Think, act, observe, repeat.
Tools
Read, write, run, call.
Context
What the model sees this turn.
Controls
Limits the model cannot override.
In plain terms:
- The loop. The model suggests a step, the harness carries it out, shows the model the result and asks for the next one, until the task is done or a limit stops it. A chat window answers once; a harness keeps going.
- The tools. Reading files is not enough. A tool that writes a file, runs a command or calls a service changes something outside the model. How tools are offered to a model is on tool use.
- The context. A model only knows what is in its context window on this turn. The harness chooses what goes in: the instructions, the relevant files, the last tool result, a summary of earlier turns.
- The controls. At least one limit is enforced by code, whatever the model writes: a permission prompt, a directory it cannot leave, a budget, a test that must pass. A limit written into the prompt is a request; a limit in the harness is a bound.
One turn of the loop
Assemble context
Harness picks what is seen.
Model proposes
A tool call, as text.
Check the limits
Allow, ask or deny.
Run the tool
The effect happens here.
Observe and keep
Into the next turn.
The model appears once in that sequence. The other four steps are the harness's. When an agent does something unexpected, those four steps are where to look first: what it was shown, which tools it had, which limit was missing, and what it kept from the last turn. The longer version of that argument is why the loop outlives the model.
Examples
The paper tests its definition against Claude Code, Codex CLI, Aider, Cline, OpenHands and SWE-agent. Each pairs a model with a loop, file and shell tools, context handling and some form of approval.
Harnesses are also sold as parts. Anthropic's documentation says the Agent SDK gives developers the same tools, agent loop and context management that power Claude Code. Anthropic calls its Claude Agent SDK a general-purpose agent harness.
Context management is where harness design gets interesting on long tasks, because no context window holds a week of work. For long tasks, Anthropic's harness has the first session set up the environment and every later session make incremental progress, leaving a progress file, a feature list and git commits for the next session to read. The model forgets between sessions; the harness writes things down so the next session can pick up.
A harness can also sit around other harnesses. DAX's README describes a deterministic runtime contract around stochastic model execution, with a policy crate that evaluates tool requests against policy with no model call. It runs coding agents such as Claude Code or Codex CLI in a disposable checkout and keeps scope enforcement for itself. DAX is built by this site's author; its page is on the Stack.
What a harness is not
Several neighbouring terms get used for the same thing. By the paper's test, a framework composes agents above the harness, an SDK that has no runtime loop is a set of building blocks, and an eval harness measures results after the task ends. The older meaning of harness, a test harness that runs code under controlled conditions, survives in that last one.
Names drift between vendors, so test the thing: does it run a loop, act through tools, manage context and enforce at least one limit by itself? If all four, it is a harness, whatever the product page calls it.
What this changes
Choosing an agent means choosing a harness as much as a model: which tools it offers, what it shows the model, where it asks a person and what it records. Comparing models inside one harness tells you about the models. Comparing two agents tells you about two models and two harnesses at once, and the harness is the part you can change.
Where this helps, and where it stops
- What it is
- A definition of an agent harness, its four parts, how it differs from neighbouring terms, and examples.
- What it does not guarantee
- A comparison of harness products, a build guide, or a treatment of the older test-harness meaning beyond telling it apart.
- When the distinction matters
- Someone is choosing, building or debugging an agent, or blames every agent behaviour on the model.
Sources
- Macedo, What makes a harness a harness: necessary and sufficient conditions for an agent harness, arXiv:2606.10106, June 2026external
- Anthropic Engineering, Effective harnesses for long-running agents, 26 November 2025external
- Claude Code documentation, Agent SDK overview (accessed 2026-10-16)external
- DAX README at v2.0.1, product map and crate descriptionsrepository @ fe911e5