Harness engineering

If the model is the decision-maker, the harness is the runtime infrastructure that lets it act — the scaffolding around the model that handles:

A useful analogy: if the agent is the driver, the harness is the car, the dashboard, the rules of the road, and the telemetry system. The driver decides; everything around them determines what they can safely do and how well they can see the consequences.

The term is borrowed from an older practice: the test harness, the scaffolding of drivers, stubs, and fixtures that wraps a unit of code so it can be exercised in isolation — supplying its inputs, invoking it repeatedly, and capturing its outputs for inspection. An agent harness plays the same role for a model: it wraps the model in a controlled, observable environment, feeds it inputs (prompts, context, tools), and captures its outputs (tool calls and their results) so they can be validated and fed back. In both cases the harness is not the thing being run — it is the rig that makes running it safe, repeatable, and observable.

Recall that Agent = Model + Harness: the model is supplied by a third party and improves on its own schedule, so the harness is the part of the system a team actually controls — and, in practice, the part that most determines whether an agent is useful and trustworthy. The harness shapes what an agent can do far more than the choice of model alone; two agents powered by the same model but run inside different harnesses will behave very differently.

The motivation is trust and reliability. A capable model let loose without constraints produces work that is hard to review and easy to get wrong. A well-designed harness constrains the solution space so the agent is more likely to do the right thing, and so that when it does go wrong, the problem is caught early and cheaply.

Harness engineering is easily confused with two neighbouring practices that also shape an LLM’s behaviour. The difference is one of altitude:

The three nest rather than compete: the harness is what assembles and manages the context on each turn, so context engineering is one of the concerns a harness handles. A rough division of labour — prompt engineering tunes the words, context engineering tunes the information, and harness engineering builds the machine that delivers both and acts on the results.

Birgitta Böckeler (Thoughtworks) frames the controls in a harness as two complementary kinds:

Both kinds come in two flavours: computational (deterministic tools such as linters and test suites) and inferential (semantic checks performed by an LLM). When an agent struggles, the harness-engineering response is to treat it as a signal — identify what is missing (a tool, a guardrail, a piece of documentation) and add it.

For production and multi-agent systems, harness engineering broadens into something close to platform engineering for agents: defining agent lifecycles, enforcing permission boundaries, wiring observability pipelines, and coordinating multi-agent workflows. The concern is the reliability, governance, and operational characteristics of agentic systems, rather than the raw capability of the underlying model. It is an emerging discipline, analogous to platform engineering in the DevOps world.

The payoff shows up at the orchestration layer. Orchestration tools such as OpenAI Symphony — which spawn an autonomous agent per task and expect each to return a validated deliverable — are explicitly designed to run against codebases built on harness-engineering principles. Without the guides and sensors a harness provides, autonomous, unsupervised agents have nothing to keep their output trustworthy.