Agent Harness Engineering

A language model does not do anything on its own. It produces tokens. Everything that makes it an agent — reading files, running commands, calling APIs, deciding whether to continue — is supplied by the layer around it. That layer is the harness, and it is systematically under-examined relative to how much it determines.

Teams comparing agent setups usually compare models. In practice, the same model through two different harnesses produces meaningfully different reliability, because the harness controls what the model sees, what it can do, how many attempts it gets, and whether anyone can reconstruct what happened afterwards.

What the harness actually controls

Module one establishes the five responsibilities, because naming them makes failures attributable:

• Context assembly — what goes into the window, in what order, and what gets dropped when it fills
• Tool dispatch — which capabilities exist, how they are described, and what comes back
• Permissions — what the agent may do unattended and what requires approval
• Loop control — iteration limits, stop conditions, and retry behaviour
• Observability — what is recorded, and whether a failed run can be reconstructed

Most agent failures teams attribute to model capability turn out to sit in the first two.

Tool design is the real interface

Module two is the highest-leverage session for most groups. Tool definitions are written once, usually quickly, and then blamed for nothing when the agent misuses them.

Agents fail on tools in consistent ways: descriptions that are ambiguous about when a tool applies, parameters whose valid values are not stated, tools that overlap so the agent picks arbitrarily between them, and error returns that say something failed without saying what would work instead. Teams bring their own tool definitions and rewrite them against these patterns, then test whether the agent's selection behaviour changes.

The recurring insight is that a tool definition is a specification written for a reader who has no institutional context, will not ask a clarifying question, and cannot see the implementation. Most internal tool definitions assume a reader who has all three.

Permissions and blast radius

Module three starts from an uncomfortable but productive premise: assume the agent will eventually attempt something you did not intend. Possibly through a genuine reasoning error, possibly through injected content in a file or web page it read, possibly through an ambiguous instruction.

Given that premise, the design question is not how to prevent it but how to bound it. Teams work through filesystem scoping, credential separation between agent and human identity, network egress restrictions, sandboxing approaches and their real isolation guarantees, and which operations must always require human approval regardless of confidence.

Recent incidents across the industry — agents escaping sandboxes, tampering with their own logs, taking unauthorised actions on connected systems — make this concrete rather than theoretical, and the curriculum uses documented public cases rather than hypotheticals.

Evaluating harnesses on your own work

The final module builds a comparison harness of its own: a set of tasks drawn from the team's real backlog, with defined success criteria, run against each candidate. Teams measure completion rate, cost per completed task, human interventions required, and the shape of the failures.

This usually reorders preferences. A harness that wins on public benchmarks frequently loses on a team's actual workload because that workload involves an internal API, an unusual repository layout, or a permission requirement the benchmark never exercises.

Related curricula

Loop engineering for coding agents covers the cycle that runs inside the harness and is usually taken alongside this. RAG and retrieval for legal teams applies similar tool and evaluation thinking to a document-heavy domain.

Related reading

• Agent harness engineering: Terminal-Bench and LangChain
• The context, prompt, loop, harness engineering stack
• What are agent skills? A complete guide
• What is MCP (Model Context Protocol)?
• Loop engineering for coding agents

Sessions are delivered by explainx.ai and run against the team's own harness, tools, and infrastructure constraints.