A language model can generate text, including a request to call a tool. It does not itself read a file, run a command, retain a durable task state, or decide whether an action is permitted. Software has to do those things around it. That software is commonly called an agent harness.
There is not yet one industry-standard boundary for the term. In practice, a harness is the runtime that gives a model the context, tools, control loop, execution environment, and feedback required to work on a task. It is where much of an agent's real behavior is determined.
The useful shorthand is:
agent = model + harness
It is shorthand, not a formal equation. A model matters. But changing the harness (its tools, instructions, context selection, retry policy, or verifier) can materially change what the same model achieves.
Anthropic describes its Agent SDK as providing the same tools, agent loop, and context management that power Claude Code. That is a practical example of the distinction: the model generates decisions, and the surrounding runtime makes those decisions operational. Anthropic Agent SDK documentation.
What a harness does
The exact design differs by product, but a capable coding-agent harness usually owns five responsibilities.
Tool access. It tells the model which operations are available: read a file, run a test, edit code, query an API, or call an MCP server. It validates and executes the tool call, then returns the result.
Context and state. It selects the task brief, repository instructions, previous tool results, and any durable notes that should be shown to the model. This is often described as memory, but it is more precise to say the harness chooses what information is carried into each model call. The model can use what is in its context window; the runtime decides what to preserve, retrieve, summarize, or discard. The four memory layers every coding agent needs breaks this responsibility down further.
Execution environment. It provides the workspace, filesystem, sandbox, credentials, network policy, and process boundary in which actions happen. Files matter here: an agent can write an intermediate result to disk and inspect it later instead of keeping it in every model call.
Control and permissions. It sets budgets and stopping conditions, requests approval for risky actions, limits which tools can run automatically, and records what happened. A prompt can ask a model not to do something; a harness can enforce it.
Feedback. It returns the result of an action and can run checks such as tests, type-checking, linting, a diff review, or a policy gate. That does not guarantee correctness, but it gives the agent evidence to revise its work against.
The loop
Most tool-using agents follow a loop with this shape:
- The harness assembles context and asks the model what to do next.
- The model replies with text or a structured tool call.
- The harness checks whether that action is allowed and executes it.
- The harness returns the result to the model.
- The cycle stops when the task is complete, a verifier fails, a budget is reached, or a person intervenes.
This is often described as ReAct-like: reasoning, acting, then incorporating an observation. ReAct itself is a specific research paradigm introduced by Yao et al. in 2022, not a name for every agent loop. Its contribution was to interleave reasoning traces and actions against an external environment. ReAct: Synergizing Reasoning and Acting in Language Models.
The distinction matters. A modern agent may use hidden reasoning, structured tool calls, subagents, a state machine, or a workflow engine, and still have this basic feedback loop without being a literal ReAct implementation. Inside Claude Code's agentic loop walks through one concrete version of it.
Harness, framework, and prompt
These terms overlap, so the useful definitions are practical rather than doctrinal.
| Term | What it is | What it cannot do alone |
|---|---|---|
| Prompt | An input to a model call: task instructions, examples, constraints. | Execute a command, persist state, or enforce a permission. |
| Framework | Reusable infrastructure for agentic applications: model clients, tool abstractions, state machines, tracing, workflow primitives, deployment support. | Decide, by itself, which tools an agent should have or which context it should see for a given task. |
| Harness | The configured runtime an agent actually works through: which tools are exposed, which context is loaded, what approval rules apply, how feedback is used. | Not applicable. |
LangGraph and agent SDKs can be used to build a harness. Some products ship enough configured behavior that they are both a framework and a usable harness on their own. The boundary between them is not necessarily one task or one process either: a harness can support a single coding session, a persistent agent, or a fleet of workers.
Agent harnesses and system harnesses
A useful distinction from a recent position paper separates the immediate agent loop from the orchestration around it.
| Level | Scope | Examples |
|---|---|---|
| Agent harness | A model working toward one concrete task, with a prompt, context, tools, and a loop. | Claude Code, Codex, Cursor Agent, SWE-Agent, OpenHands. |
| System harness | Sits above one or more agent harnesses: turns a higher-level goal into tasks, assigns work, manages shared environments, and routes outcomes through feedback such as CI, review, deployment checks, or production signals. | An outer orchestration layer that decomposes an issue, runs separate agents in isolated environments, and decides what may progress. |
This is the terminology of that paper, not a universally accepted taxonomy. It is nevertheless a helpful way to describe a production workflow in which an issue is decomposed, separate agents work in isolated environments, and an outer system decides what may progress. Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering.
A concrete example: Claude Code and the Agent SDK
Claude Code is an agentic coding tool that can read a codebase, edit files, and run commands. Anthropic's Agent SDK exposes the tools, agent loop, context management, permissions, sessions, hooks, MCP integration, and subagents that power that experience, programmable from Python and TypeScript. Agent SDK capabilities.
That does not make every application built on the SDK identical to Claude Code. It means the SDK provides a substantial part of the harness; the application builder still chooses the task flow, tool policy, environment, and verification.
Where enola fits
enola. is an MCP server and CLI, and against the five responsibilities above it fills two of them rather than all five: context and state, before an edit, and feedback, after one. It does not manage tool access broadly, provide an execution environment, or handle control and permissions; those stay with the harness it plugs into.
On the context side, the gap it targets is structural: what depends on this module, which routes a client reaches, where a change can propagate, which boundaries the repository declares. A harness can hand the model shell and file tools to reconstruct that from search results, but doing so from scratch in every session is slow and approximate. enola instead builds a deterministic graph from parsed-source facts (modules, symbols, dependencies, calls, routes, cross-repository links), and an agent queries it directly with explore, impact_analysis, and find_path before it edits. Seven questions you can ask enola shows what those exchanges look like against real repositories.
On the feedback side, the gap is that tests passing does not mean the architecture held. A new dependency can cross a declared layer, a change can reach packages outside its intended scope, or a cross-repository seam can appear without a contract, and none of that shows up in a single file or a test result. enola compares a new snapshot against a pinned baseline and reports the structural delta: new dependencies, coupling, findings, measured regressions. A policy you set turns selected regressions into a non-zero exit code, so the same evidence can be handed back to the agent, used in a hook, or enforced in CI. Installed with enola install --hooks, that check runs automatically at the end of a session and returns its verdict to the agent before the agent reports the task complete, which is the control-and-permissions responsibility from earlier acting on evidence enola supplied rather than enola providing it directly.
That is why enola. is better understood as an architectural quality gate plugged into two specific slots in the harness, not a general-purpose codebase-context tool. It measures a defined set of structural properties before and after a change and lets your team decide which measured changes should block a merge. It does not predict every runtime failure or claim that every cycle, dependency, or hotspot it finds is wrong.
Each snapshot records its source revision, enola version, extractor set, dirty-tree state, and content-derived ID. It also reports coverage gaps, so an unresolved edge is reported as a gap rather than presented as proof that no relationship exists.
It should be used alongside source inspection, not as a replacement for it. Dynamic dispatch, generated code, runtime-composed URLs, unsupported libraries, and unsupported language constructs can leave an edge unresolved.
A sound instruction for an agent using enola is:
Before an architecture, dependency, or change-impact decision, query enola. Use source inspection to verify behavior and investigate unresolved coverage.
enola's analysis runs locally against local source. That does not by itself determine what a separate model provider or other tools receive; use the data controls of the harness you run.
Enola on GitHub is Apache 2.0 licensed.
Why the harness matters
When someone says a coding agent is good or bad, they are usually describing a system, not just a model. The model is one component. The harness determines what it can access, which evidence it receives, which actions are safe, how it recovers from failure, and what counts as done.
That is why benchmark results should identify the model, harness version, environment, and evaluation setup. The same model can perform quite differently under different tool interfaces, context policies, and feedback loops; a single headline score is an outcome of the whole arrangement, not the model alone.
For teams building agents, the practical question is not only which model to use. It is also what operating environment gives that model the right evidence, the right constraints, and a reliable way to check its work. Enola is an architecture fitness sensor works through one way to categorize that operating environment: splitting its controls into guides that steer an agent before it acts and sensors that check its work after, each either computational or inferential, and mapping where a given tool actually sits on that grid. What makes a coding agent correct its own mistakes? looks more closely at the feedback a sensor should return when it rejects an attempt.
FAQ
What is an agent harness?
The software layer around a language model that supplies tools, context, an execution environment, permission controls, and feedback, so the model's proposed actions become actions that actually run and get checked.
Is an agent harness the same thing as an agent framework?
No. A framework is reusable infrastructure, such as model clients, tool abstractions, or workflow primitives, that you can use to build a harness. A harness is the specific, configured runtime doing a task: which tools are exposed, which context is loaded, and which approval rules apply. A product can ship both at once.
Is every agent loop a ReAct loop?
No. ReAct is a specific 2022 research paradigm that interleaves visible reasoning traces with actions against an environment. Plenty of modern agents run an observe-and-revise loop with the same basic shape but use hidden reasoning, structured tool calls, or subagents instead, so calling every loop "ReAct" overstates what the term actually names.
What is a system harness?
In the terminology of a 2026 position paper on agentic benchmarking, it is the orchestration layer sitting above one or more agent harnesses: it breaks a goal into tasks, assigns them, manages the environments they run in, and routes outcomes such as CI results or review feedback back into the system.