How to Design an Agent Harness: six decisions that turn a model into a worker you can leave alone

Your agent says the job is done and the tests never ran. It's sharp for twenty minutes, then forgets a rule you gave it at the start. You retype the same three instructions every session. You can't walk away, because there's always another approval waiting to be clicked.

A better model fixes none of it. All of that lives in the software wrapped around the model: what it gets told, what it keeps, what it's allowed to touch, and who checks the result. That wrapper is the harness. You already have one. The only question is whether anyone designed it.

What is Agent Harness

Six things sit between the model and the work:

The loop that keeps it going, the tools it can call, what stays in its memory, what survives a crash, what it's allowed to touch, and who decides the job is done.

Half of that came in the box. Your vendor built the loop, the built-in tools, and the memory handling, and you can't change much of it. The other half is yours: your instructions file, your tests, your permissions, your definition of done. That half exists whether or not you ever thought about it. Every rule you keep retyping into chat is part of it.

People started calling this layer "the harness" in early 2026. Before that it had no agreed name, which is most of why it went unmanaged for so long.

Real use cases

DoorDash built theirs as a platform. Every agent runs in its own throwaway virtual machine that boots with the repos, tools and credentials already in place. The work itself is written as YAML playbooks that mix agent steps with ordinary scripted steps. Everything reaching an internal system goes through one gateway that hands out only the tools a playbook declared and logs every call. They ran 130,000 automated tasks in a single month, including over 25,000 code reviews a week.

OpenAI built theirs as a repository. No platform at all. They treat the repo as the harness: the instructions file is kept to about 100 lines and works as a table of contents into a real docs folder, and architectural rules are enforced by custom linters instead of written as prose the model can skip. Three engineers merged roughly 1,500 pull requests in five months this way.

Anthropic built theirs as a role split. Three agents with different jobs. One turns a single sentence into a spec. One implements it. One drives the finished app in a browser and grades it. They communicate only by writing files to each other. It works, and it cost 6 hours and $200 where the unharnessed run took 20 minutes and $9. Over twenty times the price for a much better result, which is the trade nobody advertises.

Three completely different shapes. What they share is that none of it came in the box.

The six decisions

This is the part that pays. Each one is short: what it is, exactly what to do, what it's worth, and when to skip it.

1. The loop, and where it stops

Your harness sends the model your task plus everything that has happened so far. The model replies with either a request to run a tool or a final message. If it's a tool request, the harness runs it, glues the result onto the history, and sends the whole thing again. Repeat until the model stops asking for tools. That's the entire loop, in every product on the market.

The vendor owns that inner loop. What's yours is everything around it: what happens when it stops, and whether it starts again.

Do this:

Someone went through fifty published agent loops by hand. Only 74% even stated what counted as finished, and only 32% kept any memory between runs. This is the cheapest fix on the list and the one most often skipped.

2. The tools it can see

The model can't see your systems. It sees a menu of function descriptions, and that menu is the entire world as far as it's concerned. Two things about that menu are worth your attention.

Do this:

Skip it if you're running one agent on one repo with the built-in tools only. The token savings are real but they're not your bottleneck yet.

3. What stays in memory

Everything the model knows about your task lives in one buffer. When the buffer fills, older material gets summarised and thrown away. You don't pick what goes, and the model doesn't tell you it happened.

Do this:

One study measured how often an agent broke a written policy rule and found violations going from zero, with the rule in full view, to 30% after compaction, and to 59% on the worst model. Where the rule survived summarising, violations stayed at zero. Pinning it fixed the problem completely. That paper is a single author and unreviewed, so treat the number as a strong hint rather than a fact. The fix costs an afternoon either way.

4. What survives a crash

Your agent will die mid-task. The window fills, the process crashes, you close the laptop. Whatever lived only in the conversation is gone.

Do this. Four files in the repo, and the agent is told to keep them current:

Then make the agent commit after every change that works. Small commits with real messages. Rollback becomes `git revert`, review becomes reading diffs, and you get a full history for free instead of building a checkpoint system.

If you're building something with many separate features, add a fifth file: a plain JSON list of every feature marked passing or failing. It's the cheapest progress tracker there is and the agent can update it itself.

if it isn't in a file, it doesn't exist.

5. What it's allowed to touch

An agent running on your laptop has your SSH keys, your VPN session, and every CLI you're logged into. It doesn't need to be malicious for that to end badly. It needs one poisoned web page in its context.

Do this:

Anthropic reported that adding proper sandboxing cut permission prompts by 84% internally. That's the real argument: it isn't only safer, it's much less annoying, which is why it actually sticks.

6. Who says it's done

The agent that wrote the code is the worst available judge of whether the code works. It graded itself, and it grades generously.

Do this:

There is no published data on retry policy. How many times to retry, with what backoff, whether to retry at all or restart clean. Everyone has an opinion, nobody has numbers. If you find yourself tuning this for days, know that you're in genuinely unmapped territory.

The weekend version

If you build five things and nothing else, build these, in this order.

Everything past this is optimisation.

Conclusion

You don't get to opt out of having a harness. You have one right now. It's whatever accumulated: every workaround added at 2am, every rule pasted into a config and forgotten, every permission clicked through because clicking was faster than reading. The decisions in it all got made. Just not by you.

And it isn't free. Anthropic's own harnessed run cost more than twenty times the unharnessed one. That's the actual question to answer before you start: a harness earns its keep on work you couldn't hand off at all, and never on work where you were trying to save twenty minutes.

Start with the stopping rule and the four files. Both are an afternoon. Both survive the next model release, which is more than most of this will.