Anthropic's Agent Harness Design Changed How I Think

Anthropic's engineering post on effective harnesses for long-running agents contains one idea that quietly demotes most of what people call "agent architecture": the harness is not orchestration code. It is a set of files. An agent that works across many context windows does not need a clever framework wrapped around it — it needs a progress log, a machine-readable feature list, a setup script, and a disciplined git history, because those artifacts are the only memory that survives when the context window dies. I read the post while running my own multi-agent pipeline against this website's production database, and the uncomfortable, useful experience was checking their design against a harness I had already built by trial and error. Where we converged, I now understand why my choices worked. Where we diverged, they were usually right.

Here is their design, my production translation of it, and the rules I now follow on every harness I build.

What Anthropic actually built

The setup in the post is concrete: they had Claude build a clone of claude.ai over many sessions — far more work than fits in one context window — and engineered the environment until fresh sessions could make reliable incremental progress. The design has two agent roles and four artifacts.

The roles: an initializer agent runs once at project start to establish infrastructure, and a coding agent runs in every subsequent session, making incremental progress. The detail everyone skims past, and the most clarifying sentence in the post: the two are separate agents only because they have different initial prompts. Same system prompt, same tools. The harness is not a cast of specialized personas — it is one capable agent pointed at different jobs by different briefings. Most "multi-agent architecture" diagrams collapse under that observation.

The artifacts: claude-progress.txt, a running log of what each session did; feature_list.json, a couple hundred end-to-end feature descriptions, each with a passes boolean; init.sh to launch the environment; and a git history of small, descriptive commits. Each session starts by reading the progress file and git log, running a baseline check, then taking on one feature, verifying it end-to-end — in their case driving the app through browser automation via a Puppeteer MCP server — before flipping its boolean and committing.

The design exists to kill three observed failure modes: premature completion (Claude declares victory on the whole project far too early), context fragmentation (fresh sessions with no idea what came before), and incomplete testing (features marked done that never survived an end-to-end check).

The same skeleton, on unglamorous production work

My harness does not build a chat app; it pushes SEO remediation across hundreds of blog posts on a live Laravel platform — batch workers rewriting content, a verification gate scoring output, apply scripts touching a production database. Different domain, same skeleton, which is exactly the claim I want to defend: this design transfers because it is about state, not about coding agents specifically.

The mapping, artifact by artifact:

• Their claude-progress.txt is my status file — node states, decisions made, invariants, open items. Every session, human or agent, reads it first.
• Their feature_list.json with passes booleans is my machine-readable pipeline graph plus per-batch manifests marking each unit DONE or PENDING. One feature at a time became one batch per worker, with explicit index ranges so parallel workers cannot collide.
• Their init.sh is my scripts directory — fetch, apply, verify, all re-runnable.
• Their git discipline is my git discipline, plus something their setup did not need: row-level backups before any database write, because my "features" mutate production data, and reversibility has to be explicit when there is no git revert for a database row.

And their Puppeteer-verified end-to-end testing is my scripted verification gate: a checker that scores every rewrite against hard criteria before anything ships. Which brings me to the three failure modes — because I hit all three before I had names for them.

Premature completion is real and it is sneaky. Agents optimize for the satisfying summary; "the batch is complete" arrives before the batch is complete. The fix is exactly what Anthropic found: completion is a property of the artifact, not the transcript. A unit is done when the manifest says DONE and the gate passed — an agent's prose claim of doneness is weather.

Context fragmentation killed my earliest multi-session attempts: each new session re-derived the world, differently, and drift compounded. The progress-file-plus-git-log startup protocol ended it. I later formalized the pattern — durable task state across sessions and explicit handoffs between sessions are both children of this lesson.

Incomplete testing is why my gate runs in a separate context from the builder. Their coding agent tests through a browser because self-assessment without execution is exactly how false passes booleans happen. Mine goes further: the verifier is a different session entirely, with no investment in the draft it judges. Generator and evaluator sharing a context is how you get grade inflation from your own pipeline.

The rules I now build by

Condensing their post and my production mileage into the checklist I actually use:

1. State lives in files, addressed by path, readable by a cold session. If a fresh context cannot reconstruct the project from disk, you do not have a harness — you have a long prompt.
2. The worker that does the work updates the state, immediately. Orchestrators summarizing afterward is how manifests learn to lie. (Crash between doing and marking, and rule 3 saves you.)
3. Every unit is idempotent. Safe to run twice, because eventually it will be.
4. One unit per session. Their one-feature rule is not a throughput limit; it is what makes verification, commits, and blame tractable.
5. The evaluator is not the generator. Scripted gates where possible, separate contexts always.
6. Reversibility is designed, not assumed. Git where git works; explicit backups where it does not.

Notice what is absent: model cleverness. The harness assumes a competent agent and engineers everything around it — the same conclusion I keep reaching from different directions, whether structuring parallel workers as a swarm or splitting work across forked subagents. My my-ai-crew repository, where I keep my orchestration experiments, has been converging on this file-backed shape for months; Anthropic's post mostly gave me permission to delete the clever parts.

Where the pattern stops

Honesty about the boundary: this design is for work that decomposes into verifiable units. My pipeline qualifies because a script can judge a rewrite against hard criteria. Work whose quality is genuinely a judgment call — strategy, novel design, anything tasteful — does not get better by being harnessed; it gets churned. And even inside a good harness, some gates should stay human. Mine sits before anything irreversible touches production. The harness's job is to make that human gate cheap — one review of verified, backed-up, ready-to-apply changes — not to eliminate it.

If you are building toward long-running agents, start embarrassingly small: a progress file, a task list with booleans, a startup ritual of reading both, one unit per session. That is the whole secret, and it fits in a directory listing. The framework you were about to write can wait, probably forever.

Harnesses that must run unattended against real systems — content operations, data pipelines, engineering workflows — live or die on the boring half: scope, gates, and recovery. Designing that half around an existing stack is client work I take on, and my services page is where it starts.