Knowledge tree
On this page

Agent Harness

The program around a model that supplies instructions, tools, a runtime, and checks so it can work on an environment.
Updated 28 Aug 2026

A model by itself does not read a repository, execute commands, or know a project’s rules. The harness is the program that puts those pieces around the model and maintains the agent loop.

The model proposes decisions. The harness assembles context, exposes tools, runs actions in a runtime, and returns the results. Codex, Claude Code, and OpenCode are examples of harnesses that make different choices around those pieces.

What the harness adds around the model Project instructions, skills, tools, and deterministic checks feed the harness. The harness prepares context and tool access for the model, executes requested actions in the repository, shell, or tests, and returns results. Inputs and capabilities Project instructionsSkillsToolsDeterministic checks Harness Prepare contextExpose and run tools Model Choose the next step Runtime / environment RepositoryShellTests Context + toolsDecisionRequested actionResult What the harness adds around the model Project instructions, skills, tools, and deterministic checks feed the harness. The harness prepares context and tool access for the model, executes requested actions in the repository, shell, or tests, and returns results. Inputs and capabilities Project instructionsSkillsToolsDeterministic checks Harness Prepare contextExpose and run tools Model Choose the next step Runtime / environment RepositoryShellTests Result
Figure 1. The harness prepares the model call and connects model decisions to tools and a runtime; execution happens in the environment and results return for the next decision.

Project instructions

Instruction files give the agent rules that are not present in the user’s immediate request. Codex uses AGENTS.md, Claude Code uses CLAUDE.md, and OpenCode supports its own rule and compatibility mechanisms.

The filename is a harness convention. What matters is that the program discovers the file and places its instructions in model context. Those files should stay focused: a large manual becomes repeated input across many inferences.

Skills and tools

A skill explains how to approach a class of task. It may contain instructions, references, and scripts. For example, a document-review skill can describe what to inspect and provide a deterministic script that validates the file structure.

A tool is a capability the model can ask to run: read a file, execute a command, or call an API. The harness shows the definition to the model, receives the tool call, and performs the operation. Tool Use covers that path in more detail.

Runtime

Actions happen in an environment such as a local shell, VM, sandbox, or cloud workspace. The runtime determines which files, binaries, network paths, and services are available.

The same model can complete a task in one harness and fail in another because its instructions, tools, or environment differ. If the test runner is not installed or the repository is not mounted, better model output cannot supply the missing capability.

Deterministic checks

The LLM does not need to solve every subproblem. Counting findings, validating JSON, and running tests are better handled by scripts when the rule is exact. The model can interpret the result and decide what to do next.

In this repository, editorial rules guide the agent, while npm run test:content checks invariants that should not depend on the model remembering them. The harness combines both kinds of work in one task.

Results and observability

To understand a run, it helps to see tool calls, results, errors, token usage, and validation outcomes. This does not require an elaborate architecture. A clear command and result history already helps separate a model problem from a tool or environment failure.

The harness also decides how much output goes back into context. It can keep a full log in a file while sending only relevant lines to the model, which connects directly to Context Engineering.

References