Your Agent Is Only as Reliable as Its Harness

The model gets the attention. The harness decides whether the agent does its job.

Many people do not know what an agent harness is, and you can hear it in how they describe agents. A typical sentence: “The LLM then executes the action”, or “the LLM makes the tool call.”

That sounds harmless, but it is wrong, and it matters. The model executes nothing. It produces text that says “call this tool with these inputs”. The harness takes that text, runs the tool and hands the result back to the model.

So there are three things, and they get mixed up all the time. The model is the brain. The harness is everything around it. The agent is the two together. If you do not know who does what, you do not know where to look when something goes wrong.

What a harness is#

The short version: the model is the brain, the harness is everything else that turns it into an agent that works reliably.

A model on its own only produces text. It can suggest what to do, but it cannot open a file, send a message or remember yesterday. The harness gives it hands, rules and a memory, and keeps a hand on the wheel.

In practice, the harness consists of:

• Instructions and context: what the agent is told and what it gets to see.
• Tools: what it can actually do, such as searching, reading files or calling an API.
• Memory: what it keeps from one step, or one session, to the next.
• Permissions: which of those tools and data it may use.
• The loop: plan, act, check the result, repeat.
• Approvals: the points where a human has to say yes.
• A log: a record of what happened and why.
• Stop rules: when the agent must finish, give up or hand over.

Anthropic describes the harness in more technical terms as “the loop that calls Claude and routes Claude’s tool calls to the relevant infrastructure” . Microsoft puts it this way: “If the model supplies the intelligence, the harness is everything around the model.” Different words, same idea.

The loop at the center#

An agent does not answer once. It works in rounds, and the harness runs every round. The model suggests the next step. The harness decides what happens with it: it checks whether the call is allowed, asks a human where that is required, runs the tool and passes the result back.

Take away a piece and you see what breaks. No check, and the agent never notices its own mistakes. No approval, and it acts on things it should have asked about. No stop rule, and it loops until the budget is gone.

Three comparisons, and where each one breaks#

No single comparison covers it, so here are three, each with its limit. The one I use is engine and car.

Engine and car. The model is the engine, the harness is the rest of the car: steering, brakes, fuel line, dashboard. Nobody would call an engine on a workbench a vehicle. The comparison breaks because a car’s engine rarely changes, while a model can be swapped in an afternoon. It also hides that the harness is not passive: it decides when the model is called and what it gets to see.

Horse and harness. A horse is strong and has a will of its own. The harness does not make it stronger; it makes the strength steerable and usable. But a horse harness is passive leather, whereas an agent harness runs the loop itself, controls what the model sees and can stop it. A horse also knows the road. A model without context does not.

Operating system and application. An operating system gives programs files, permissions, processes and a way to shut them down. A harness does the same for a model. The limit is predictability: an operating system is deterministic, a model is not. A harness cannot guarantee the outcome, it can only bound it.

Where you can see harnesses today#

Coding agents in the terminal#

Coding agents show the harness most openly. In Claude Code’s default manual mode, reading files is allowed, but running shell commands and editing files require approval, according to the Claude Code permissions documentation . Permissions and approvals are a visible product feature here, not a hidden setting.

For long tasks, the harness has to do more. In an engineering post from 26 November 2025 , Anthropic describes that agents struggle to make steady progress across several context windows, because each new session starts without memory of earlier work. Their answer was a harness answer: an initializer sets up the environment, each session leaves a progress file, and descriptive git commits let later sessions recover a working state. Same model, but with a memory made of files.

Agent platforms from vendors#

The big vendors now name the harness as a product layer. Microsoft is one example: its documentation describes it as “a runtime” between your agent design and the model that decides when to call the model, what to send it, and which tools to call. On 28 October 2026, Microsoft introduced the same technology as the Microsoft Copilot harness across several of its products.

The direction matters more than the brand: agents that run on triggers instead of prompts and that get their own accounts. Microsoft’s October post says these features roll out through its Frontier program and that further access and cost controls are “planned for in the coming months”. The more independently an agent works, the more the harness has to carry.

A personal assistant with approval before every action#

I use a personal assistant myself, and its harness follows one rule. It may read and prepare on its own. Sending, committing to something and deleting happen only with my explicit yes.

It is the same idea as the manual mode of a coding agent, just applied to everyday work: the agent gets room to prepare, and the harness holds the line where something leaves my hands.

What makes a good harness#

Six things to check, in roughly this order:

1. Context#

The agent should get what it needs for this task, not everything you have. Too little context makes it guess. Too much makes it slow, expensive and inconsistent.

2. Tools#

Few tools, clearly described, each with a narrow purpose. A tool the agent can misuse will eventually be misused.

3. Limits#

Permissions follow the task, not the convenience of the builder. Read access is the default, write access is earned.

4. Approvals#

Decide up front which actions need a human yes. Irreversible and external actions, such as sending, deleting or paying, belong on that list.

5. Traceability#

You should be able to reconstruct what the agent did and why. If you cannot, you cannot improve it, audit it or trust it.

6. Error handling#

Define what happens when a tool fails, an answer is wrong or the loop goes in circles: retry, escalate, stop. An agent without stop rules is a cost risk.

If I plan an agent, I build the first four first: context, tools, limits and approvals. The one teams underestimate most often is the last: error handling.

How you recognize that the harness is the problem, not the model#

A simple test: keep the task, swap the model. If the same mistake survives, look at the harness.

A few more symptoms point away from the model:

• The agent forgets. It repeats work or contradicts itself between steps or sessions.
• It declares victory too early. Anthropic observed exactly this in long-running coding tasks.
• It invents what it could look up. A missing tool or missing context often looks like a hallucination.
• You cannot explain what happened. Without a log, every failure looks like bad luck.

Then keep the model and change the setup: better context, fewer tools, a clear stop rule. If the results improve, you had a harness problem.

One more point. Anthropic notes that harnesses “encode assumptions about what Claude can’t do on its own” . As models improve, some of those assumptions become dead weight. A harness is not something you build once; you revisit it.

Three questions before you build#

1. What may the agent do without asking, and who is asked for everything else?
2. How will you find out what it did and why?
3. What stops it when it fails or loops?

If you cannot answer these, a better model will not save the project. Picking the model is the easy, reversible part. The harness is where your decisions live, so make them on purpose.