Eight Parts, One Model: Taking Apart the Agent Harness

What an agent actually is has been discussed to death. Shubham Saboo offered a more practical way to split it: agent = model + harness.

The model reads context and chooses the next action. The harness is the layer of code outside it, responsible for turning that choice into work that actually happens.

Claude Code, Codex, Antigravity, OpenClaw, and Hermes Agent are all harnesses. Put the same model in a different harness, and it can feel like a different thing entirely.

Every harness has eight parts.

1. The Loop

Send the context to the model; the model says which tools it wants to use; the harness executes them and feeds the results back for the next round. It loops until it decides the task is done.

The problem with many agents isn't that they can't call tools; it's that they don't know when to stop.

2. Tools and Sandbox

Give the model a terminal, a filesystem, a browser, and the apps you've connected. Each task runs on its own isolated machine, so a single rm -rf can't blow up the host.

The point of a sandbox is that when the model makes a mistake, the cost has a ceiling.

3. Sub-agents

Farm out peripheral tasks to run in parallel. Each sub-agent starts with a clean context and, when done, returns only a short summary.

Keeping the main context clean matters more than parallelism itself.

4. Context Management

Decide what the model can see on each turn. Skills and files load on demand, and history gets compressed before it fills up.

When a model forgets things during a long task, it's usually not because it has a bad memory; it's because the harness failed to manage what it should be shown.

5. Memory

Progress notes, git history, and skills are all persisted to disk. A new session can read what happened in the previous round and pick up from the breakpoint.

The author himself says poorly designed memory is a huge pitfall, and he'll write about it separately later.

6. Guardrails

Actions like sending email, making payments, or deleting things are paused until you approve them. Real credentials live outside the sandbox, so even a prompt injection can't steal anything.

7. Verification

Prevent the agent from handing you a summary that sounds finished. Run tests, do a browser check, or have a separate grader review it; only then does it count as complete.

What agents are best at is that confident declaration of completion.

8. Observability

Trace every model call and tool call. If you find it repeatedly editing the same line of code without getting it right, push it to try a different approach.

Repeating the same failing action is a common way agents die.

The comments were livelier than the post itself.

Jaume said one thing: the harness is the product. Shubham Saboo personally agreed: yes, the harness is the product. The model can be swapped; the harness is engineering that gets built up over time.

Thomas's observation was more direct: half of the online debate between Codex and Claude Code is really a harness debate wearing a model's coat.

Dominik added a sharp point: an agent's personality probably lives in the plumbing. What it remembers, what it's allowed to touch, and when it stops.

Rohan asked which of the eight parts most often causes bad runs. The author's answer was memory. Failing to design memory well is a huge pitfall, and he plans to write a dedicated piece about it.

Jack offered a way to test recoverability: kill the process right after the agent creates a CRM record, then restart it and see whether it finds that record or creates another one.

Dave said that during handoff, besides what was completed, you also need to preserve what is still uncertain.

When looking at an agent product, don't rush to see which model it uses. Models can be swapped; changing the harness is far more expensive.