Harness Engineering

An agent is a loop: the model observes its context, decides on an action, executes it through a tool, observes the result, and decides again. Most of the attention goes to that loop — the prompt that frames it, the model that runs it. But the loop is only the visible half of a production agent. The other half is the harness: the runtime that hosts the loop, supplies its tools, bounds its behavior, records what it did, and recovers it when something breaks.

The vocabulary is catching up to this reality. Where teams once spoke of prompt engineering, the more experienced now speak of harness engineering — building the execution environment around the loop, not just the words inside it. A clever prompt with a poor harness produces a demo. A modest prompt with a strong harness produces a system you can run on Monday and still trust on Friday.

In our engagements, the pattern is consistent: teams spend weeks tuning the model and the prompt, and an afternoon on the harness. Then the agent reaches production and the failures are almost never about the prompt. They are timeouts, duplicated side effects, runaway tool loops, unobservable errors, and permission boundaries that were never drawn. The harness is the majority of what makes an agent reliable, and it is consistently the least-invested part of the stack.

This paper treats the harness as a first-class engineering artifact. It covers the components — the tool layer, the execution sandbox, context and state management, the governor, observability, and recovery — and the reliability properties that hold them together. It closes with a reference architecture you can check your own agent against.