What is Agent harness?

How it works

A model on its own only turns input tokens into output tokens. The harness is everything else an AI agent needs:

• The loop. Send the prompt, detect a tool request, run the tool, return the result, repeat until done.
• Tools. Definitions for file access, shell, search or business APIs, often via function calling or MCP.
• Context management. The system prompt, which files or history to include, and summarising or trimming when the context window fills up.
• State and memory. Progress notes, task lists and files that let work continue across sessions.
• Controls. Permission prompts, sandboxes, step and cost limits, and logs.

Anthropic's engineering post "Effective harnesses for long-running agents" describes the Claude Agent SDK as a general-purpose agent harness, and shows how a harness can carry a long coding task across many context windows using an initial set-up session, a progress file and incremental commits. Coding tools such as Claude Code, Codex CLI and Cursor's agent are, in effect, harnesses around models.

Why it matters

• Same model, different results. Two products using the same model can perform very differently because of their harness: what tools they offer, how they manage context and how they recover from errors.
• Benchmarks depend on it. Agent benchmark scores are for a model plus a harness; a vendor's number may not transfer to your setup.
• Safety lives here. What the agent is allowed to touch, and when it must ask a person, is set by the harness, not the model.
• It is where builders add value. Most practical agent work is harness design: tools, prompts, context and checks.

Example

You ask a coding agent to add a feature across ten files. The harness gives the model tools to read, edit and run tests; asks you before running a shell command; summarises old tool output when context gets long; and writes a progress file so a fresh session can pick up where the last one stopped.