The Harness Is the Agent

A racing team does not win on the engine alone; the same engine in a badly built car loses every race. The model is the engine, and the harness, the loop, the tools, the memory, the guardrails, is the car built around it. When an agent works or fails, it is usually the car, not the engine, and that is what this piece argues.

When an agent does something impressive, we credit the model. When it goes off the rails in production, the cause is almost always somewhere else: the loop that never knew when to stop, the tool call that was allowed when it should not have been, the context that quietly dropped the one fact that mattered. The model is the part everyone talks about. The harness is the part that decides whether any of it works.

By "agent harness" I mean everything that sits between a model that predicts text and an agent that gets work done. The model takes tokens in and returns tokens out. That is all it does. To turn that into an agent you have to add a loop that calls it repeatedly, a way to turn its words into real actions, a way to decide what goes into each call, somewhere to keep state across steps, rules about what it is allowed to touch, and a way to check whether the result can be trusted. That surrounding machinery is the harness.

It is tempting to treat the harness as glue code around the interesting part. I would argue it is the other way around. The model is a fixed, probabilistic dependency you mostly cannot change. The harness is the system you own.

Start with what the model cannot do on its own. A model call is stateless: it has no memory of the previous step unless you put that memory back into the prompt. It is non-deterministic: the same input can produce a different output, so you cannot lean on any single response. And it cannot act: it can only describe an action in text. Every property we actually want from an agent lives outside those constraints. Continuity across steps is state you carry. Recovery from a bad step is control flow you write. The ability to do anything at all in the world is a tool you expose. The model proposes; the harness disposes.

What a harness is made of

This is where the engineering actually is:

• The control loop. When do you call the model again, when do you stop, how many steps are you willing to spend. A surprising share of agent failures are not wrong answers but loops that never terminate, or that give up one step too early.
• The tool interface. How a line of model output becomes a validated, real action. This is where a typed contract matters far more than a clever prompt.
• Context assembly. The real work of prompting is not a static string. It is the code that decides, on every turn, what goes into a finite window: which results, which history, which instructions, and what to leave out.
• State and memory. Carrying the facts that matter across steps without pushing the entire history back through the model every time.
• Guardrails and policy. What the agent is allowed to do, under whose authority, with what approvals. Least privilege applies to an agent exactly as it does to any other program.
• Verification. Checking that an output is grounded in what the tools returned, and catching the drift that a fluent, confident, wrong answer hides.

Put those together and you get a loop with a gate in it. The model chooses the next step; the harness decides what is actually allowed to happen, runs it, folds the result back into context, and goes again until the work is done.

Swap the model and the point becomes literal: the six responsibilities do not move.

The harness is where you engineer

Here is the part I care about most. The harness is the only place you can add determinism, tests, and governance to a system whose core is none of those things. You cannot unit test a model's judgment. You can test the loop's termination, the tool schema's validation, the policy's decisions, and whether a claim cites real evidence. Those are ordinary software properties, and they belong to the harness.

That is why I build the tools I build, and all of them live in the harness, not the model. AgentTrustCI turns three expectations, that the agent only calls approved tools, that its answers are grounded, and that it follows the intended sequence, into regression tests that run in CI next to your unit tests, so behavior is gated at build time instead of discovered in production. ToolContractGate does the runtime half: every tool call is checked against a versioned contract with deterministic rules and no model in the decision path, so a tool surface that has drifted from what was approved is blocked rather than trusted. openapi-mcp derives the tool surface itself from an approved API specification, so an agent's capabilities stay tied to what the service actually promises. None of these touch the model. All of them are harness.

The honest counterpoint

Better models do shrink parts of the harness. A model that follows instructions more reliably needs fewer retries and less corrective scaffolding, and that is real progress. But it does not remove the harness, and I would argue it makes it matter more, not less. Boundaries, tool contracts, and verification are inherently outside the model, because they are exactly the decisions you do not want the model making for itself. And a more capable model raises the stakes: it can accomplish more, which means it can also do more damage when it is wrong. The more an agent can do, the more the harness has to hold.

Build it like it matters

So treat the harness as a first-class artifact, not an afterthought. Keep the model swappable behind an interface, so you can adopt a better one without rewriting your system. Make the loop and the tools testable. Treat context assembly as code you review, not a prompt you tweak. Put policy at the tool boundary, where it can be enforced deterministically. And verify outputs against evidence rather than trusting fluency.

The model will keep improving on its own. The harness only improves if you build it.