# Part 2: What an LLM harness is and how it runs tools

Canonical page: https://vikrammohan.com/thought-leadership/llm-harnesses-and-governance/what-is-an-llm-harness/

The harness for a large language model (LLM) is the software that prepares its inputs, makes tools available and coordinates their execution. In a coding assistant, those tools can read project files, edit code or run tests. The model proposes a next step; the running application handles that request and returns the result to the model. Anthropic describes Claude Code as this surrounding layer in [How Claude Code works](https://code.claude.com/docs/en/how-claude-code-works).

The harness determines how proposed work becomes action, which execution conditions apply and what observations are available afterwards. Understanding those responsibilities helps explain both the capabilities of an agent and the limits of its authority.

## Model, application, agent and workflow

| Term | Role |
| --- | --- |
| Model | The learned component that processes supplied context and generates a response, potentially including requests to use tools. |
| Application | The product or service combining the model with interfaces, data and supporting software. |
| Agent | A system that uses model decisions and feedback from its environment to pursue a task through successive actions. |
| Workflow | An arrangement of activities whose sequence is substantially specified by application code. |
| Harness | The execution machinery that prepares model inputs, coordinates tools and manages the operating loop. |

The distinction between a workflow and an agent concerns who determines the route through the task. A workflow might prescribe inspection, editing and testing in advance. An agent might decide that a failed test requires another file inspection before further editing. Applications can combine these patterns. Flexible routing helps with tasks whose steps are difficult to predict, while introducing more decisions to assess. Anthropic explains these architectural distinctions in [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents).

## How a tool request becomes an action

A tool request describes an action for the application to handle. The runtime, meaning the software executing the application, interprets the request and applies its configured execution conditions before invoking the tool. The result returns to the model as context: information it can use when deciding what to do next. Anthropic documents this repeated exchange in [How the agent loop works](https://code.claude.com/docs/en/agent-sdk/agent-loop).



![Task information enters context assembly in the harness and is sent to the model. The generated response reaches a router. Tool requests pass through configured execution conditions, then either run a tool or produce refusal feedback. Results return to context assembly. A completion response follows a separate branch labelled proposed completion.](https://vikrammohan.com/thought-leadership/llm-harnesses-and-governance/figures/fig-02-01-the-harness-coordinates-the-tool-loop.svg)

*Figure 2.1. The harness assembles context, routes model responses and handles configured execution conditions. Tool results or refusal feedback become input for a later step; a proposed completion still needs assessment against the task.*



Consider a hypothetical repository task: update a name-formatting function to handle empty input according to the requester's specification, update the relevant tests and add a release note. A repository is the collection of source files and their version history. The requested behaviour would need to be established before deciding which implementation is appropriate.

A search might locate several similarly named functions. Reading their callers, the code that invokes them, could establish which one is relevant. If a proposed change were tested, a failure might reveal an unintended effect on existing non-empty values. The agent could use that result to reconsider the edit.

The loop depends on useful observations. A message saying only that a test failed provides less direction than a result identifying the failing assertion, meaning the test's check that a condition holds, alongside its expected and actual values. Even detailed feedback needs to be interpreted against the task's requirements.

## Permissions, isolation and hooks

Permission controls determine whether an action may proceed under the application's approval arrangements. Isolation limits the resources available to the process once it executes. A permitted command can therefore run inside a restricted environment. A permission decision alone does not create an operating-system boundary. Anthropic distinguishes these mechanisms in [Choose a sandbox environment](https://code.claude.com/docs/en/sandbox-environments).

For the repository task, permission concerns whether an edit or command may run. Isolation concerns what that command can reach. A sandbox, an environment with restricted access to resources, may cover one tool or the whole application. Those boundaries cover different activity. Files left writable and network destinations left accessible remain within reach according to the configuration.

![A requested operation reaches a permission decision. An unauthorised operation is refused. An authorised operation starts a tool process, whose resource request is then checked against configured isolation. That check leads either to accessible files or endpoints or to resource access being denied.](https://vikrammohan.com/thought-leadership/llm-harnesses-and-governance/figures/fig-02-02-permission-and-isolation-govern-different-decisions.svg)

*Figure 2.2. Permission determines whether the requested operation may proceed. Where isolation is configured, it separately limits the resources the executing process can reach. Authorisation at the first stage does not grant unrestricted access at the second.*



A hook is a handler invoked at a defined event, such as before a tool call or after an edit. It lets the runtime trigger an operation without relying on the model to choose that moment. A handler may itself ask a model for a judgement; automatically triggering it does not remove uncertainty from that judgement. See [Automate actions with hooks](https://code.claude.com/docs/en/hooks-guide).

## How skills and MCP extend the harness

Skills package reusable instructions or procedures. MCP, the Model Context Protocol, provides an interface through which applications connect to tools and contextual resources. These extensions supply knowledge and capabilities to the application; their operations still raise questions about permission and evidence. See [Extend Claude Code](https://code.claude.com/docs/en/features-overview) and the [MCP architecture overview](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture).

## What supports a completion claim

For the hypothetical task, completion would involve examining the changed function, any available test results and the release note against the requester's requirements. A transcript records the interaction, including reported actions and tool results. The resulting repository state establishes what changes actually exist. Anthropic distinguishes transcripts from outcomes in [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents).

If a test was requested but no completed result is available, its outcome remains unresolved. A harness can make that gap visible through its records, allowing the next decision to account for unfinished verification.

Part 2 of 8 in the series [LLM harnesses and governance](https://vikrammohan.com/thought-leadership/llm-harnesses-and-governance/).

Previous part: [Part 1: How large language models work and what they need to complete a task](https://vikrammohan.com/thought-leadership/llm-harnesses-and-governance/how-large-language-models-work/)

Next part: [Part 3: How LLM context, memory and handovers support long-running work](https://vikrammohan.com/thought-leadership/llm-harnesses-and-governance/llm-context-memory-and-handovers/)

Vikram Mohan is not a solicitor or barrister. Nothing on this site is legal advice. For legal advice, speak to a regulated legal professional.

© Vikram Mohan - All rights reserved. No liability accepted for content on this website. [LinkedIn](https://www.linkedin.com/in/mohanvikram/) · [Privacy](https://vikrammohan.com/privacy)