The core claim
A raw LLM is not an agent. It becomes one when connected to a harness. The useful unit of evaluation is therefore the model-harness pair, not either component in isolation.
The 2026 Agent System and Harness Design survey decomposes an execution harness into observation, context, control, action, state, and verification. Code as Agent Harness adds a code-centric view: code is not only an output but the executable substrate for tools, memory, control, coordination, and verification. These are useful taxonomies, not performance proofs.
Controlled evidence supports a narrower claim. In The Scaffold Effect in Coding Agents, two fixed models were tested across three harnesses on 50 Terminal-Bench Pro tasks. Harness choice changed tokens per solved task by up to 40 times, while paired pass-rate differences stayed within 0 to 8 percentage points and were mostly not statistically significant. The harness can dominate cost and failure behavior without dominating task accuracy. Conversely, model quality or model-harness compatibility can remain the binding constraint. Report the pair, the task set, and the budget.
This page uses agent harness in its runtime sense: the system that owns the agent loop, tools, context, state, and permissions. A repository can also provide a repository harness around that runtime: its instructions, setup, task state, and verification gates. The distinction matters because a project can improve its repository harness without replacing Claude Code, and a team can switch runtime harnesses without discarding every project practice.
This page covers what is inside the runtime. For the repository layer, see Repository Harness Engineering. For feedback loops, executable workflow graphs, stopping rules, and judgment boundaries, use Loop & Graph Engineering. For a dated comparison of specific products across CLI, IDE, and cloud, see the Agent Harness Landscape.
The LLM is one stage in the reliability loop. Context, policy, guarded execution, verification, observability, constraints, and feedback determine whether the model's proposal becomes an accepted result.
Choose the right entry point
| Question | Canonical page |
|---|---|
| What does a runtime harness contain, and how do its controls work? | This Agent Harness Engineering page |
| How should loops, workflow graphs, state transitions, stopping rules, and judgment be designed? | Loop & Graph Engineering |
| How should independent Claude Code sessions exchange evidence without spreading drift? | Cross-Session Messaging: Coordination safety |
| Which runtime, orchestrator, framework, or adjacent project should I compare? | Agent Harness Landscape |
| What does a specific coding-agent product support? | Agent Tools: Beyond Claude Code |
| What distinguishes a runtime, repository, evaluation harness, and orchestrator? | Glossary |
| Which Claude Code release introduced a behavior? | Claude Code Releases and its machine-readable history |
The pages remain separate on purpose. Engineering concepts change more slowly than product inventories, licences, feature evidence, and popularity signals. Combining both would make the architectural reference inherit the catalog's dated snapshot and maintenance cycle.