What a Harness Actually Is, and Why It's the Real Product
A model takes messages and returns tool calls. Everything else is the harness — and it explains almost all the variance between agent systems that share the same model.
The word gets used without definition, and the definition matters — because once you can see the harness as a distinct thing, it becomes obvious that it's where most of the quality difference between agent systems lives.
The definition
A model takes messages and returns text or tool calls. That's the whole interface. Everything else — every part that makes an agent useful rather than a chat completion — is the harness.
Concretely, the harness is:
The loop. What runs after a tool call, when to stop, what happens on error, how many turns are allowed.
Context assembly. What goes into the array, in what order, what gets trimmed, what gets re-injected each turn, what's held as structured state instead.
The tool layer. What tools exist, how they're described, what they return and in what shape, how errors are phrased, what's batched, what's forbidden.
Verification. What checks run, when, and what happens on failure.
State and persistence. The work ledger, the scratchpad, what survives a restart.
Permissions and blast radius. Which credentials, which approvals, what's reversible.
Presentation. How work is surfaced for review, what progress is shown, how failures are reported.
Why it's where the differences are
Two teams with identical model access build agents that differ enormously in usefulness. The model is a constant; the harness explains the variance.
More specifically, most of what people experience as "the agent is unreliable" traces to harness decisions:
- Losing a constraint at turn twenty → context assembly.
- Picking the wrong tool → tool descriptions.
- Treating an empty result as "nothing exists" → tool result formatting.
- Reporting partial work as complete → loop's completion check.
- Going wrong in an unrecoverable way → permissions and reversibility.
⚠️ Each of those gets attributed to the model, and none of them is a model problem. Which is why "we tried a better model and it didn't help" is such a common report.
💡 The implication for effort
If the harness explains the variance, effort should go there. In practice attention goes to prompts, because prompts feel like the interface to the model's intelligence and the harness feels like plumbing.
The reordering worth making:
- Tool design. Descriptions, granularity, result shapes, error text. Highest return, most neglected.
- Verification. Building an oracle changes what's possible, not just what's likely.
- Context assembly. Position, stability, structured state.
- Loop semantics. Termination, budgets, partial results, escalation.
- Prompts. Last, and smaller than you expect once the above are right.
→ A common experience: fixing tool descriptions and context assembly makes the prompt shorter, because half of it was compensating for those.
Why it's the durable part
Model capability is available to everyone and improves for everyone. Harness quality is specific to your system, embeds your domain knowledge, and doesn't arrive with a version bump.
That's also why it's where the commercial competition sits. Products differentiating on harness quality — context handling, review presentation, recovery, permissions — are competing on ordinary software engineering, which is defensible in a way model access isn't.
✅ Reading your own harness
For a system that isn't working well, go through the list and ask what each part does:
- What's in the array on a failing turn, exactly?
- What does each tool return when there's nothing to return?
- What happens when a tool fails twice?
- How does the loop know it's done?
- What can this agent do that it should never be able to do?
- How does someone review its output?
Most systems have two or three parts that were never designed, just defaulted. Those are usually where the failures are.
The takeaway
The model takes messages and returns tool calls; everything else is the harness — loop, context, tools, verification, state, permissions, presentation. That's where the variance between agent systems lives, where most "model problems" actually originate, and where effort returns the most. Fix the tools and the context before the prompt, and expect the prompt to get shorter when you do.