Harness Engineering
Everything Around the Model
A harness is what sits between a model and the world: the loop that calls it, the tools it can reach, the context it is handed, the permissions it operates under, and the surface the result is rendered into. A chat application is a harness. A terminal coding agent is a harness. A voice platform is a harness. They can run the same underlying model and produce products with almost nothing in common, which is the whole argument: past a certain point the harness determines capability more than the model does.
Harness Comparison
Four harnesses that can sit on identical weights. What differs is not intelligence but the environment, and the environment is what users actually experience.
| Harness | Loop Shape | Tool Surface | What It Optimises |
|---|---|---|---|
| Chat application | One turn at a time, human in the loop by construction | Retrieval, rendering, a small curated set | Breadth of question and quality of explanation |
| Terminal coding agent | Long autonomous runs with verification against tests | Filesystem, shell, version control, arbitrary execution | Work completed without supervision |
| Voice platform | Sub-second turns under a hard latency budget | Telephony, transfer, scoped lookups only | Responsiveness and conversational naturalness |
| Embedded assistant | Suggestion accepted or rejected inline | Whatever the host application exposes | Staying out of the way when wrong |
Swap the model underneath any row and the product stays recognisably itself. Swap the harness and it becomes a different product entirely, even with the weights untouched.
What a Harness Supplies
Nine responsibilities. A harness can decline any of them, but declining is a decision rather than an omission, and users experience the gap as a fault in the model.
How many times the model is called, what it sees between calls, and what ends the run.
Absent, the model looks: Incapable of finishing anything that takes more than one step.
What the model can actually do, how tools are described, and how results come back.
Absent, the model looks: Confidently wrong about the present, because it cannot check.
What gets loaded before each call: history, retrieved material, instructions, tool definitions.
Absent, the model looks: Forgetful, or overwhelmed and imprecise.
What is allowed, what needs approval, and what is refused outright.
Absent, the model looks: Reckless, or so cautious it is useless.
Where generated code or actions actually run, and what that environment can reach.
Absent, the model looks: Able to describe a solution and not to apply one.
What survives the session, how it is written, and how it is retrieved later.
Absent, the model looks: Starting from nothing every time, however many times you have met.
How a human interrupts, redirects, approves or cancels while work is in flight.
Absent, the model looks: Unstoppable until finished, which users experience as not listening.
How output reaches the user: streamed text, spoken audio, a diff, a document, a rendered artefact.
Absent, the model looks: Producing correct output nobody can act on.
What is recorded about each run, and whether a failure can be reconstructed afterwards.
Absent, the model looks: Mysterious. Every failure is a new failure.
Guides and Sensors
The organising idea worth keeping is that a harness acts in two directions. Guides shape behaviour before the action, sensors detect what happened after it, and a harness with only one of them fails in a characteristic way.
Everything that shapes behaviour in advance: instruction files describing conventions, skills packaging a procedure, tool descriptions that make the right call obvious, documentation the agent is pointed at, and examples of work done correctly.
Alone, it: Cannot tell whether any of it worked, so guidance accumulates without ever being pruned.
Everything that detects what actually happened: tests, linters and type checks, pre-commit hooks, output validators, evaluation suites, and human review at chosen points.
Alone, it: Detects problems it made no attempt to prevent, paying for the same mistakes repeatedly.
Guides without sensors means the same mistake is made repeatedly, because nothing observes that the guidance failed. Sensors without guides means the system detects problems it never tried to prevent, and spends its budget on rework. The pairing is the point.
Failure Modes
Scaffolding added to compensate for limitations a newer model no longer has: forced decomposition, rigid output templates, retry logic for failures that stopped occurring. The harness now constrains more than it enables.
Fix: Periodically remove scaffolding and measure. Anything that can be deleted without regression was compensating for a model that no longer exists.
Every new capability becomes another tool, until selection accuracy degrades and the definitions alone consume a serious share of the context budget. More capability produces a less capable agent.
Fix: Scope tools to the phase that needs them rather than exposing everything always. Measure selection accuracy as tools are added.
Extensive conventions and instructions with nothing checking adherence. The instruction file grows every time something goes wrong and nobody can say which lines are doing work.
Fix: Pair each significant guide with a check. If a rule matters enough to write down, it matters enough to detect violations of.
Retries, fallbacks and error suppression make a struggling agent look competent. The product appears to work while quietly costing several times what it should and degrading in quality.
Fix: Surface retry counts and fallback usage as first-class metrics. A silent recovery is still a failure that happened.
Every incident adds another thing to the prompt or another retrieval step. Nothing is ever removed, and the assembled context eventually crowds out the material that actually matters.
Fix: Budget context explicitly per component and force additions to displace something. Treat the window as a fixed allocation rather than a queue.
Work can be started and not steered or stopped. A user who sees the agent going wrong at step two can only wait for step twelve, and will simply stop trusting long-running work.
Fix: Make cancellation and mid-run correction first-class from the beginning. Retrofitting interruption into a loop that never expected it is substantially harder.
Where This Sits
Harness is the third of the engineering layers, containing prompt and context and contained by loop and graph. Its prior art is the IDE: linters, tests, docs and build tooling shaping a developer's output without changing the developer.
The nine responsibilities each have their own treatment: Agentic Loops for iteration and stop conditions, Agent Memory and Conversation Management for context assembly, Authorisation Policy for permissions, Sandboxing and Code Execution for the execution environment, Steering and Stream Safeguards for intervention, Turn-Taking for the control surface in a spoken harness, and Judge and Escalation for the sensors that gate output.