An agent harness is the scaffolding that turns a model into something that acts: the loop that calls the model repeatedly, the tools it can invoke, the memory it carries, and the guardrails that bound it. It is the difference between "a model that can answer" and "an agent that does." The category matters because the harness, more than the model, is where day-to-day behavior is decided.
The clearest way to see it: the same frontier model behaves completely differently inside Claude Code, OpenClaw, or a Paperclip-orchestrated swarm — because each is a different harness, with different tools, prompts, memory, and limits. The model sets the capability ceiling; the harness decides how much of that ceiling you reach, how it fails, and how much it costs to run.
That is also why the harness is the security and cost surface. Tool access, the retry loop, what goes into the context window, and the spend ceiling all live in the harness — and they are where runaway bills, prompt-injection blast radius, and "why did it do that?" originate. If you are evaluating agents, evaluate the harness, not just the model behind it.
/Glossary
- Agent harness
- The runner, tools, memory, and guardrails wrapped around a model to make it act. Where agent behavior is actually implemented.
- Agent loop
- The cycle of call-the-model, run-a-tool, feed-the-result-back that lets an agent take multiple steps toward a goal.
- Tool use
- The mechanism by which an agent invokes external actions (run code, call an API, browse). The tools a harness exposes define what the agent can do — and break.
- Context-window management
- How the harness decides what to keep in the model's limited context across a long run. A major driver of both cost and quality.
- Guardrails
- The limits a harness imposes — allowed tools, spend ceilings, approval gates — that bound what an agent can do when it goes wrong.