What is an agent harness?

A language model on its own does one thing. Text goes in, text comes out, and it forgets the exchange immediately.

An agent does more than that. It wakes on a schedule, reads a file, calls an API, remembers what happened last time, and stops when it should. None of those abilities are in the model. They are in the software wrapped around it, and that wrapper is the harness.

What a harness actually contains#

Five parts, and every agent framework has some version of all five.

The loop. The model produces an action, something runs it, the result goes back to the model, and round it goes until the work is finished or a limit stops it. The loop is what makes an agent an agent.

The tools. The list of things the model is allowed to call, and the description of each one. A tool description is prompt text, so a badly written one produces a badly behaved agent, and this is the single most common cause of an agent that works in a demonstration and fails on real input.

The memory. What survives between runs. Files, a database, a summary of prior conversations, or nothing at all.

The triggers. What wakes it. A person, a schedule, an incoming message, a webhook.

The limits. The maximum number of steps, the maximum spend, which actions need a human approval, and what happens when something fails halfway through.

Why does the harness matter more than the model?#

Because the same model behaves completely differently inside two different harnesses, and the harness is the part you control.

Give one model a tight tool list, clear descriptions and a step limit, and it completes the task. Give the same model twenty vague tools and no limit, and it wanders, calls things it should not, and spends money. Nothing about the model changed.

Researchers have started making this point directly about benchmark results, arguing that comparing agents without disclosing the harness produces numbers nobody can reproduce (arXiv). The same applies commercially. A vendor demonstration showing an agent completing your workflow is a statement about their harness, not about the model, and you cannot buy their harness by buying the model.

What a production harness needs that a demonstration does not#

A harness that runs unattended, inside a company, holding real credentials, needs a specific list of things that a weekend project does not: a tight allowlist of tools, scoped credentials, approval tiers for anything that writes, filters against prompt injection on the way in and the way out, a retry policy that does not duplicate work, a maximum runtime, an audit log, and a way to stop it immediately.

That list is the difference between an agent you demonstrate and an agent you deploy. Most of the engineering in a working agent goes there rather than into prompting.

The consequence is a budget one. When somebody estimates an agent build at two weeks, ask which of those eight things the two weeks includes. Usually it includes the loop and the tools, and the other six arrive as a surprise in month two.

What this does not cover#

The harness will not rescue a task that was never clearly defined. An agent given an ambiguous job does the ambiguous job faster, and the ambiguity surfaces as output somebody has to check, which is where the saving goes.

Nor does a good harness make a weak model adequate for a task it cannot do. The harness decides whether a capable model is usable. It does not add capability that is not there, and the honest test is whether a careful person with the same tools and the same instructions could do the task at all.

Where to start#

Name the one task first, then design the harness around that task rather than around a framework. A harness built for one specific job, with four tools and a hard step limit, is more likely to survive contact with production than a general one with thirty tools.

Then decide what happens when it is wrong, because it will be, and that decision is the one most teams postpone.

If you are choosing between the ready-made harnesses rather than building one, the three most people are comparing differ mostly on hosting and control rather than on capability. And if you would rather have somebody work out which of your tasks is worth this at all, that is where we start.