An agent harness is what turns a stateless language model into a functional agent, by grounding its outputs in external execution, persistent state and verifiable feedback. Code as Agent Harness: Toward Executable, Verifiable, and Stateful Agent Systems frames the central design question for any harness as a question about medium — what connects the model to its task environment — and argues that code is the answer, because code is executable, inspectable and stateful in ways natural language is not. On that account these are not properties of code as a notation but the properties that make it function as a harness interface: executability means the harness can verify what the model intended, inspectability means failures can be diagnosed and fed back, and statefulness means the agent’s interaction history is not lost between steps.
Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering uses the term more narrowly, as one of two levels of orchestration. There, an agent harness is a language model interacting with tools, working towards a single task, with some system prompt and context to draw on; the System Harness is the outer layer that turns higher-level goals into concrete tasks, dispatches each to one or more agent harnesses, manages the environment they act on and routes their outputs through feedback. On that reading most artefacts described as “coding agents” — the paper names Claude Code, Codex, Cursor Agent, SWE-Agent and OpenHands among them — are agent harnesses in this sense. The same paper treats an agent harness as a configurable executor composed of model, prompt, tools and loop, which the surrounding system harness may tune or treat as a black box.
Usage
The survey distinguishes the harness from the code running inside it. Code is an executable medium within the harness; the harness is the larger policy-governed system deciding what code may be executed, trusted, persisted, reused or promoted into future workflows. Reliability, on this framing, depends not only on the model’s judgement and on agent-authored artefacts but on human-designed policies, sandbox boundaries, permission tiers, verification oracles, audit logs and human-review gates.
Three roles are identified for code at the harness interface. Code for reasoning externalises internal logic into verifiable computation that interpreters, symbolic solvers or execution traces can check and refine. Code for acting translates high-level intent into executable operations grounded in embodied, GUI, software or tool-use environments — with the survey emphasising that executable action code is an interface to perception, affordance estimation, controllers and safety layers, not a replacement for them. Code for environment modelling represents world state, transition dynamics and feedback signals through program states, repositories, simulators, tests and logs the agent can execute, edit and query.
Above that interface sit the harness mechanisms the survey groups into five interacting categories: planning, which organises long-horizon execution; memory and context engineering, described as a state-management layer deciding what stays in active context, what is compacted into summaries and what is offloaded to durable external storage; tool use, treated as a governed interface between model intent and external systems rather than an auxiliary capability; control through the Plan–Execute–Verify Loop; and Harness Engineering, which studies how the harness itself can be measured and improved.
The survey also treats the harness as a safety governor rather than only a context manager or tool executor — a layer that classifies proposed actions by risk, enforces permission tiers, denies actions violating hard constraints and requires human approval for irreversible or externally consequential transitions. Its proposed structure is a multi-tier permission model: a read-only tier for browsing, retrieval, static inspection and log analysis; a sandbox-edit tier for local patching, test execution and temporary dependency installation inside an isolated workspace; and a full-access tier covering network access, credentials, deployment commands, package publishing, destructive filesystem operations and Git history mutation. The authors argue permissions should depend not only on tool identity but also on arguments, environment state, data sensitivity and expected side effects, since the same command may be safe in a disposable sandbox and unsafe in a production repository.
A further argument the survey makes about safety is that human-in-the-loop control should become durable harness state rather than an occasional prompt interruption: each approval, rejection, policy exception or reviewer correction should update the harness’s permission rules, escalation policy, verification criteria and future memory retrieval, and high-stakes approvals should be auditable state transitions recording what was proposed, what evidence was shown, what risks were surfaced, who decided and what responsibility boundary changed. The authors call this executable accountability.
Gorinova et al. use the agent harness as an argument about measurement: because the harness is part of what a benchmark actually scores, a leaderboard entry naming only a model is under-specified. They reproduce Terminal-Bench entries for a single fixed model across several agent harnesses in which accuracy ranges from roughly 58% to roughly 80%, and argue that since the model is fixed the spread cannot be explained as a difference in model capability — it shows that prompt, tool interface, action loop, environment handling, retry behaviour and terminal conventions are part of the measured object. They add that a model may have been trained or tuned under particular tool-use conventions, so a harness can be well or poorly matched to a model before any task-specific reasoning begins.
LangChain’s Harrison Chase uses the term for a position in a layering of agent-building software rather than for the system around a model in general. In Agent Frameworks, Runtimes, and Harnesses- oh my! he places an agent harness above an Agent Framework: where a framework’s value is its abstractions and an Agent Runtime beneath it supplies production infrastructure, a harness adds default prompts, opinionated handling of tool calls, planning tools and filesystem access — “batteries included”. His example is LangChain’s own Deep Agents, built on LangChain and described as a “general purpose version of Claude Code”; he reads the Claude Agent SDK as Claude Code’s step in the same direction and allows that all coding CLIs could be argued to be agent harnesses of a kind. He states that he did not come up with the term and that its definition, like the boundaries between the three layers, was not yet clear.
A later LangChain post by Vivek Trivedy, The Anatomy of an Agent Harness, proposes a much broader definition than Chase’s layering: “Agent = Model + Harness”, and “if you’re not the model, you’re the harness”. On this account a harness is every piece of code, configuration and execution logic that is not the model itself — system prompts; tools, skills and MCP servers with their descriptions; bundled infrastructure such as a filesystem, sandbox and browser; orchestration logic such as subagent spawning, handoffs and model routing; and hooks or middleware for deterministic execution such as compaction, continuation and lint checks. A raw model is not an agent, the post argues, until a harness gives it state, tool execution, feedback loops and enforceable constraints. Trivedy offers this as, in his opinion, the cleanest of many possible ways to draw the boundary, and derives each component by working backwards from something a model cannot do on its own: the filesystem for durable state, bash and code execution as a general-purpose tool, sandboxes for safe execution and self-verification, memory files and search for knowledge beyond the weights, Compaction and Tool Call Offloading against Context rot, and the Ralph Loop and planning for long-horizon work. The post also argues that because products such as Claude Code and Codex are post-trained with their harness in the loop, a model can overfit to that harness — yet the best harness for a given task is not necessarily the one the model was trained with.
Anthropic’s own documentation uses the term in the same broad sense for its product. Describing how Claude Code works, it says the agentic loop is powered by two components — models that reason and tools that act — and that Claude Code is the layer around the model that provides the tools and manages the context the model sees, which it identifies as what the term agentic harness refers to. The loop that harness runs is described as three blended phases: gathering context, taking action and verifying results.
The open-source OpenHarness project defines the term in the same broad sense in its README: an agent harness is the complete infrastructure that wraps around an LLM to make it a functional agent, with the model providing intelligence and the harness providing “hands, eyes, memory, and safety boundaries”. It closes on the line “The model is the agent. The code is the harness.” The harness it implements is organized around an agent loop that runs each tool call the model requests through a permission check and lifecycle hooks before feeding the result back, surrounded by subsystems for tools, skills, plugins, permissions, hooks, commands, MCP, memory, background tasks and multi-agent coordination — the model, as the README puts it, decides what to do and the harness handles how.
Jimmy Song’s online book on building agents gives the term a chapter of its own and defines a harness as a runtime substrate that mediates observation, action, feedback and completion — the layer between model and application that turns the model’s reasoning into behaviour that can be executed, observed, recovered and governed. Where the model is the engine, he writes, the harness is the chassis. The chapter assigns a complete harness six responsibilities: observation (assembling file-system state, process output, user input and API responses into context), action (gating and sandboxing tool calls, scheduling concurrent calls and tracking side effects), feedback (writing results back, retrying, compressing context and holding intermediate state), completion (validating output, running tests and archiving evidence), permission (approval for destructive operations, allowlists and blocklists, and file-, network- and process-level access control) and memory (persisting sessions, cross-session memory, checkpoints and session lineage). On this account the completeness of those six is what separates a harness from a framework: a library that only wraps tool calls is a framework. The chapter attributes the shift to agents moving from one-off task execution to long-running autonomous operation, which calls for checkpoints, audit trails, permissions and memory rather than stateless chains, and it notes that research has begun to group Claude Code, OpenAI Codex, Hermes Agent and OpenClaw together as CLI harnesses. It reads Hermes Agent (always-on), Claude Code (developer-facing and interactive) and Codex (asynchronous and isolated in the cloud) as three forms of the same idea, concluding that “harness” names a class of runtime substrate rather than any one product.
Song’s layering inverts Chase’s. Where Chase puts the Agent Runtime at the bottom of the stack, beneath frameworks and harnesses, Song puts it above the harness: the harness is the runtime substrate of a single agent and is concerned with that agent’s execution quality, while the agent runtime is the operating platform for many agents, handling scheduling and governance at system level, and one runtime can manage several harness instances. He presents the two as complementary rather than as substitutes. The chapter also names the security risks this layer has to face once agents run continuously — prompt injection when messages, memory, skills, scheduling and the shell share one authority boundary, confused-deputy attacks, permission escape where gates exist only at the shell level, and checkpoints that may capture sensitive data — and argues for least privilege, audit trails for every operation and approval gates for destructive ones.