An agent harness is the software wrapped around a language model that turns it into a working agent: it assembles the context, runs the loop, dispatches tool calls, applies permissions and handles results. Two agents using the same model can behave very differently because their harnesses differ.
A language model produces output from input. Everything else that makes agentic AI operational is supplied by software around it: deciding what the model sees, offering it tools, carrying out the calls it requests, feeding the results back, keeping track of a long task, and stopping. That software is the harness. A coding agent that runs in a terminal operates through one: the agent is the model and harness working together, and the harness is the part that is not the model. Anthropic describes its Claude Agent SDK as a general-purpose agent harness, and LangChain uses the same word for its Deep Agents library.
Three engineering responsibilities meet in this entry, and they are easier to reason about when kept apart: making an agent operational, making it more capable, and making its execution accountable. A harness is squarely responsible for the first, contributes heavily to the second, and can take part in the third without being the whole of it.
What a harness does
The functions below recur across harnesses. Few harnesses provide all of them, and how much each one does varies.
| Function | What it involves |
|---|---|
| Model interaction and the execution loop | Calling the model, reading its output, and repeating: the agent loop |
| Tool discovery, routing and invocation | Presenting tool definitions, including tools from MCP servers, and dispatching each tool call |
| Context construction and management | Assembling the prompt, and summarizing or offloading material as the context window fills |
| State, memory and continuity | Notes, files, checkpoints or memory that let work survive a long task or a new session, where supported |
| Planning and task decomposition | A task list or plan the model maintains and the harness keeps in view |
| Retries, error handling and recovery | What happens when a tool fails, a call times out or a run is interrupted |
| Subagent delegation | Handing a subtask to a fresh agent with its own context and receiving a compact result, where supported |
| Execution environment and filesystem access | Where commands run and which files are reachable, often a sandbox |
| Human intervention and approval | Pausing before configured operations so a person can approve, edit or reject them |
The harness changes what the agent achieves
The second sentence of the definition is the one most often overlooked. Hold the model constant, change the harness, and the results change.
The reasons are practical. A model can only reason over what is in its context, so a harness that selects context well gives it a better problem to solve. A model can only act through the tools it is offered. On a long task, a model that fills its context with test logs loses the thread, while a harness that writes those logs to a file and lets the model search them does not. Work that spans sessions depends on what the harness preserves between them.
Anthropic's published engineering work makes the point concretely. Its account of long-running agents starts from the observation that each new session begins with no memory of what came before, and describes a harness-level answer: a first session that sets up the environment, and later sessions that each make incremental progress and leave clear artifacts, such as a progress file and git commits, for the next one. A later account of harness design for long-running application development reports raising performance well above a baseline through prompt engineering and harness design together. That work does not isolate the harness as the single cause of the gain, and it does show that the design of the software and prompts around a model substantially affects what the agent achieves. LangChain describes its own harness as the same core tool-calling loop as other agent software, with built-in capabilities added to make agents reliable on real tasks.
Two consequences follow from the conceptual point, which holds whatever the size of the effect in a given case. An agent's measured performance is a property of a model and a harness together, so an improvement cannot automatically be attributed to the model alone, and a benchmark result may not transfer to a different harness. And a harness can compensate for practical limits in a model, by managing context, preserving progress, exposing tools and structuring long work, without changing what the model is.
What a harness contributes is the ability to get work done. It does not, by that fact, establish that the work was appropriate, that it was authorized, or that it succeeded.
Harness, runtime, framework, sandbox and protocol
Usage varies across the industry, and the boundaries blur in real products. One widely read articulation is LangChain's, which separates three layers: frameworks, which provide abstractions and integrations for building agents; runtimes, which provide durable execution, streaming, persistence and human-in-the-loop support; and harnesses, which it calls opinionated, batteries-included, with built-in tools, prompts and subagents. It names examples of each from several vendors, including other companies' harnesses.
- The model generates. The harness is everything that makes that generation into action.
- An agent framework is a library of components for building agents. A harness is a more complete, more opinionated assembly that runs one. Many harnesses are built with a framework.
- An agent runtime is the environment that hosts the agent while it works and determines what its actions can reach. The word is also used for durable-execution engines that keep long-running agents alive across failures. A harness runs on a runtime in both senses.
- An agent sandbox is an isolated execution environment. A harness may configure one and route commands into it.
- MCP is a protocol for connecting an application to external tools and data. A harness is often the MCP host. The protocol defines how the harness talks to servers, not how it runs the agent.
Deep Agents: a named harness
Deep Agents is LangChain's name for its own agent harness. It is a standalone library built on LangChain's building blocks for agents, and it uses the LangGraph runtime for durable execution, streaming and human-in-the-loop support. Its documentation groups its capabilities into an execution environment (tools, including tools from MCP servers, a virtual filesystem with pluggable backends, declarative filesystem permission rules, and sandbox backends that add a shell tool), context management (skills, memory files, summarization, context offloading and prompt caching), delegation (subagents and optional task planning) and steering (pausing for human approval on configured tool calls). One scoping detail is worth knowing: the declarative permission rules apply to the built-in filesystem tools. They do not apply to arbitrary command execution through a sandbox backend, which is governed by its own controls, such as the sandbox's isolation, backend policy hooks and approval steps. That is how the layers are divided, not a gap in them.
The related names are distinct. LangChain is the agent framework and its building blocks. LangGraph is the lower-level orchestration framework and runtime. Deep Agents is the harness built on both. LangSmith is separate tooling for tracing, evaluating and improving agent behavior, and is not the harness.
Deep Agents is one implementation of the concept, and a useful illustration of how much a modern harness includes. It is not the definition of the category. An agent with a sophisticated harness is not thereby a deep agent, and LangChain's own documentation lists other vendors' products as harnesses alongside it.
Sandboxes, permissions, approvals and governance
Several mechanisms are found in and around harnesses, and they answer different questions.
A sandbox isolates execution within the resources and boundaries it controls: which files a command can touch, which network destinations it can reach, which processes it can start. Anthropic's description of sandboxing in its coding agent stresses that filesystem isolation and network isolation are both needed, because each can be used to defeat the other. That is real protection, within the sandbox's boundary.
A harness may contain controls of its own: permission rules over files or tools, approval steps before chosen operations, security checks, policy hooks or middleware that can refuse a call. These act on what passes through the harness.
Runtime governance establishes an explicit relationship between an agent's declared objective and scope, the actions it attempts and the policies that apply, and preserves the evaluation as evidence.
AI agent governance is the broader responsibility, covering authority, compliance, completion, efficiency, oversight and accountability.
These complement one another and are not mutually exclusive. A single product may implement several, and a harness can perform governance functions. The distinction is about what each mechanism covers, not about which product it ships in.
An example: a coding agent, a sandbox and a production API
The following scenario is illustrative. It was written for this entry and does not record a real run.
A coding agent is asked to fix a flaky retry test in a payments worker and keep the suite passing. Its harness provides planning, context management, repository tools, a sandbox in which tests and commands run, and a deployment tool that talks to the company's deployment-management API. The deployment tool runs outside the sandbox and holds its own credential, which is the arrangement LangChain's sandbox guidance recommends: keep secrets in tools outside the sandbox so the agent can use them by name without being able to read them. The task's boundaries are this repository and no production changes.
The harness at work. The agent writes a short plan and runs the suite in the sandbox. The failure is intermittent. The test output runs to thousands of lines, so the harness writes it to a file instead of placing it in the model's context, and the agent searches it. It suspects a race in the retry backoff, which uses a shared clock helper. It hands a subagent the job of surveying every other use of that helper and gets back a one-paragraph report. Partway through, the session reaches its limit. The harness has kept the plan and the agent's progress notes, and the next session resumes from them. The agent fixes the race and runs the test fifty times in the sandbox without a failure. The same model, without offloading, delegation and persistence, would plausibly have lost the thread in the logs or restarted from nothing.
The consequential action. While investigating, the agent notices that the production worker is configured with five retries. It reasons that setting retries to zero in production would stop the intermittent behavior from reaching customers while the fix is reviewed, and it emits a call to the deployment tool to update the production configuration. The call is technically available and the credential is valid. It is outside the task.
Each layer stands in a different relation to that call.
| Layer | What it sees | What it can do |
|---|---|---|
| The sandbox | Nothing. The deployment tool runs outside it by design | Constrain the tests and commands inside it. It does not constrain this call |
| The harness | The tool name and arguments, before dispatch | Apply a permission rule, pause for approval or refuse, if it was configured to for this tool. This covers calls made through this harness |
| The deployment API's authorization | The credential and the requested operation | Decide whether this credential may change this service. The credential was issued for deployments, so it may. The decision is about permission, not about this task |
| The production system | The change itself | Apply its own rules, such as a change freeze, protected environments or required reviewers. Where they are actually enforced, they cover the routes and callers that reach the system through them |
Suppose the harness was not configured to pause on the deployment tool. The request is sent, and the API replies that the configuration update was accepted. Several different facts are now in play. A request was attempted. A result was returned: the API accepted the update, which means it passed validation and authorization. Whether the deployment system has recorded the new desired configuration is a further fact, visible in that system's own state. Whether the running workers have actually adopted it is another again: a rollout may be pending, paused or failed. The effect is confirmed by evidence from the workers or the deployment system's rollout status, not by the reply the agent received.
Now suppose the harness was configured to pause, and a person declined. That restriction held for this agent, in this harness. A teammate's script, another agent or a CI job holding the same credential is not subject to it. If the organization's intent is that nobody changes production configuration outside a release, the place to express that is the production system or its authorization layer. A rule there covers the relevant routes and callers to the extent that it is actually enforced on them, which is itself worth verifying.
From observing to enforcing
Governance is not one more harness feature for improving model behavior, and it is not one mechanism. At least six distinct things can happen around an attempted action.
- Observing that the action was attempted.
- Evaluating it against declared governance context: the objective, the scope, the policy.
- Recording a finding.
- Requesting human confirmation.
- Restricting or refusing execution in the harness.
- Enforcing a restriction at the system that can produce the consequential effect.
These may be implemented together or separately, by one product or several. Two properties are worth stating plainly. An advisory finding does not by itself prevent an operation. And a restriction is effective only to the extent that the relevant execution or authorization boundary honors it.
Where enforcement is absent, incomplete or bypassable, the practical consequences depend on the operation: disclosure of data to a party that should not have it, destructive changes, unintended transactions, or other effects outside the harness that may not be reversible from inside it. That does not mean every action warrants blocking or a human approval. An agent that must ask permission for everything has lost the autonomy that made it useful, and people asked to approve too often tend to stop reading what they approve. The appropriate response depends on the deployment: the systems involved, the consequences of an error and the organization's tolerance for them. Each organization has to decide which operations warrant a record, which a flag, which a confirmation, and which enforcement at the target system. Governance of this kind supports useful autonomy instead of eliminating it.
Governance extends beyond the harness
Governance can be integrated into a harness. The responsibility for it does not necessarily end at the harness boundary.
The example shows why. The agent worked inside a carefully controlled environment and still held a route to a consequential system outside it. The sandbox constrained local execution and not the API. A harness-level check governs the actions taken through that harness and not other routes into the same system. Authority is granted by whoever owns the credential and the system. Policy may be written in one place and needs to be honored in several. Evidence of the attempt lives with the harness, and evidence of the effect lives with the system that was changed. Accountable execution therefore tends to require coordination across more than one execution and authorization boundary: the harness, the identity and authorization layer, and the target systems themselves.
How agentic AI, MCP and the harness relate
- Agentic AI describes autonomous, goal-directed behavior.
- The harness makes that behavior operational.
- MCP standardizes the connections through which the system discovers capabilities and exchanges information with external systems.
- Governance makes autonomous execution accountable to objectives, authority, policy and outcomes.
These are different architectural concerns. A deployed agentic system may combine a harness, MCP and governance, and none of them implies the others. In particular, MCP is not necessary for an agentic system: a harness can offer tools with no protocol involved.
Where governance instrumentation connects
Harnesses commonly expose extension points around tool execution: hooks that run before and after a tool call, middleware, callbacks, or a wrapper around a client. The moment just before dispatch is an execution boundary, and what can be captured there is an agent action: the tool, the type of operation and the system it targets. This is where runtime governance can attach to a harness without becoming the harness. It does not run the loop, manage context, route tools or execute anything.
Sentience Governor is one implementation of runtime governance that connects at such points: through Claude Code's hooks, through a wrapper for MCP clients, in LangChain and LangGraph, and in Pydantic AI through a separate package. Of the six responses above, its current implementation performs the first three. It observes each attempted action where it is instrumented, evaluates it against the declared objective, scope and the operator's policy, and records the finding. It returns no decision to the harness, so the call proceeds. Requesting confirmation, refusing a call and enforcing a restriction at a target system are separate capabilities in the broader architecture and are not part of the current implementation.
Applied to the example, with representative Claude Code hook payloads and nothing executed: a session declared with a scope covering the repository's files and test processes records the deployment call as a write to a target outside that scope and flags it at the attempt, together with the default intent rule. The call is passed through. The API's "accepted" reply is recorded as context entering the session, by size only. The service name, the environment and the new value are absent from the record, and the record is not evidence that production changed. Governor sees the calls that pass through an instrumented harness. It does not see a teammate's script or any other route to the same API.
Often confused with
An agent framework. A framework supplies components. A harness is an assembled, opinionated system that runs an agent, and is often built from a framework.
An agent runtime. The runtime hosts the agent and bounds what it can reach, or, in the other common sense, keeps its execution durable. The harness is the agent-specific software that runs on it.
A sandbox. A sandbox is one component a harness may use. It isolates execution and does not decide what the agent should do.
An MCP host or server. MCP describes connections. A harness frequently acts as the host, and servers supply tools to it.
Orchestration. Agent orchestration coordinates agents, tools and steps in a larger process. A harness may orchestrate subagents, and an orchestrator may run many harnessed agents.
Deep Agents. A specific harness from LangChain, not a synonym for the category.
Where the concept stops
A harness makes an agent operational, and a better harness makes it more capable. Neither fact makes its execution accountable. Whether an action was appropriate to the task depends on a statement of the task. Whether it was authorized depends on whoever owns the system acted on. Whether it took effect depends on evidence from that system. A harness can host the mechanisms that address each of these, and for actions that reach beyond its own environment, some of those mechanisms have to live where the consequences do.