What does a harness add to a language model?
A model call receives input and returns output. In a tool-enabled application, that output may include a request to read a file, query a service or run a command. The model does not independently execute that request: application code must interpret it, apply the relevant controls, run the operation and return the result.
The harness coordinates that interaction. It assembles context, exposes tools, handles responses and continues or stops the loop. Session storage, context compaction, user interaction and permission controls may also live there. The exact boundary varies by product; ‘harness’ is an architectural description, not a certification or a fixed feature checklist.
Anthropic explicitly describes Claude Code as the agentic harness around Claude. Pi describes itself as a minimal terminal coding harness. Both descriptions separate the model from the surrounding software, without implying that the two products have identical capabilities or controls.
References: Anthropic — How Claude Code worksPi — coding-agent README, v0.85.1
Model, agent, harness, tool and runtime: what is the difference?
These terms overlap in everyday product language. The following working definitions make it easier to ask where a capability, failure or security boundary actually lives.
| Component | Responsibility | What it does not establish |
|---|---|---|
| Model | Generates responses and may propose tool calls from the context it receives. | That an action ran, was authorized or produced a correct result. |
| Harness | Coordinates context, model calls, tool execution and the continuing interaction. | That execution is isolated or every tool call needs human approval. |
| Agent | The system pursuing a task through model decisions and available actions. | A particular autonomy level or permission to change external systems. |
| Tool | Exposes an operation, such as reading a file or calling an API. | That all inputs, identities and target records are safe. |
| Runtime / environment | The process, machine or container in which software and commands run. | Isolation from the host, network or credentials unless configured and tested. |
| MCP | A protocol through which applications exchange tools and context with servers. | The application's complete reasoning loop or business authorization policy. |
References: Anthropic — How Claude Code worksPi — coding-agent README, v0.85.1Model Context Protocol — Architecture overview
How the loop works: a small coding example
Consider a request to fix a date-parsing bug in a disposable repository with synthetic fixtures. The following sequence is an illustrative design, not a recorded Claude Code or Pi benchmark. A real run may skip, repeat or rearrange steps.
Conceptually: user task → harness assembles context → model proposes an action → execution controls evaluate the request → tool runs in its environment → result returns to the harness and model. The loop continues until it stops, reaches a limit or needs a person's decision.
- Gather context: expose the task, relevant project instructions and available tools. The model requests the source file and failing test.
- Observe the failure: a tool runs the agreed test in the isolated project. Its exit status and output become evidence in the conversation.
- Propose and apply a change: the application processes the model's edit request according to its configured permissions and the operating environment.
- Verify: run the relevant test again and inspect the diff. A model saying ‘fixed’ is not a substitute for that output; passing one test is not proof of every behavior.
- Stop and report: show the change, checks and remaining uncertainty. Committing, pushing or deploying is a separate action requiring the applicable authorization.
References: Anthropic — How Claude Code works
Where Claude Code and Pi fit
Claude Code's documentation describes a loop of gathering context, taking action and verifying results, supported by tools and context management. Its permission mechanisms are part of the application around the model. This explains its role as a harness; it does not prove the quality of any particular generated patch.
Pi's v0.85.1 README describes a minimal terminal harness with read, write, edit and bash as its default model tools. It also documents saved sessions and context compaction. Its philosophy explicitly does not provide built-in permission popups or built-in MCP support. Do not mistake a minimal toolset for a sandbox or assume another product's approval behavior applies to Pi.
This is a documentation-based distinction, not a head-to-head recommendation. Before selecting either product, check the version you will run, the actual configured tools, how access is restricted and how you will review results. Extensions and surrounding infrastructure can change the effective system.
References: Anthropic — How Claude Code worksPi — coding-agent README, v0.85.1
Is MCP the same as an agent harness?
No. MCP defines how a host application connects through clients to servers that expose tools, resources and prompts. Its architecture documentation says that the protocol does not dictate how applications use language models or manage the provided context.
A harness can integrate an MCP client as one way of making capabilities available. It can also use built-in tools, command-line programs or direct API integrations. An MCP server may call an existing API underneath; choosing MCP does not remove that API's credentials, permissions or failure modes.
Exposing a tool is not blanket authorization to use it on any record. Validate inputs and the acting user's access where the operation executes. A retrieved document, repository file or tool response is data, not permission to bypass those checks.
References: Model Context Protocol — Architecture overviewPi — coding-agent README, v0.85.1
What a harness does not guarantee
A useful loop can still make a wrong decision. Context can be incomplete; compaction can lose detail; a command can fail; a remote service can time out after accepting a write. The surrounding application needs a policy for these outcomes, not just a longer prompt.
A confirmation dialog is not operating-system isolation. Likewise, a container is not automatically private if it mounts credentials or retains broad network access. Inspect the real execution boundary and test it with synthetic data before granting access to sensitive resources.
Conversation history is useful for debugging, but it may contain source code, tool output or personal data. Decide what is retained, who can access it and what must never enter the context. Do not publish raw agent sessions as evidence without reviewing and authorizing their contents.
- Use the smallest permissions and toolset that can complete the task.
- Keep high-impact actions, external writes and production changes behind an explicit approval process.
- Treat unknown repositories and third-party extensions as executable code to review, not trusted instructions.
- Separate action requests, confirmed execution, verified results and recovery procedures.
References: Anthropic — How Claude Code worksPi — coding-agent README, v0.85.1
How to evaluate a harness without confusing it with the model
Start from a representative task and a known repository state. Record the product version, model, tool configuration, context, permissions and runtime. Keep the task and acceptance checks stable across trials, and use repeated runs rather than presenting a single successful patch as general performance.
Where possible, hold the model and its configuration constant. If products cannot use the same model, report a comparison of complete systems, not evidence that one harness caused the difference. Report unsuccessful attempts and human intervention alongside successful results.
Useful observations include whether the patch meets the acceptance checks, whether unrelated files changed, what access was needed and whether the system recovered from a tool failure. Cost and duration need actual measurement with the provider's billing scope and test environment stated. This guide contains no measured ranking or cost comparison.
When do you need a harness?
A plain chat interface may be enough to explain a concept or discuss a code snippet that you provide. A fixed workflow may be easier to test when every action and branch is already known. A harness becomes useful when the task requires an ongoing interaction between a model, changing context and tools.
Choose it for the work it must coordinate, not because ‘agentic’ sounds more advanced. The next questions are what the system may read, what it may change, how results will be checked and who owns the failures after the demonstration ends.