Harness Engineering: How Anthropic Gets Claude to Work for Six Hours Without Breaking Down

> Claude was given one task: "build a clone of claude.ai." A single agent ran for 20 minutes and cost $9. The result: core functionality completely broken. > > The same task, run by a three-agent harness, took 6 hours and cost $200. The output: a fully functional 2D game maker with AI-assisted generation, a playable test mode, and shareable links. > > The difference isn't just time and money. It's Anthropic's systematic thinking about harness engineering.

---

1. The Breaking Point of Long-Running Agents

Agents can do more and more, but they still have a structural flaw: the context window is finite, and complex engineering can't fit in one window.

Imagine engineers on a project working in shifts. Each incoming engineer knows nothing about what the previous shift did. No handover docs, no code comments, no git log. They can only guess. Guess wrong, and they burn hours restoring the project to a working state.

That's Claude's real situation without a harness.

Anthropic ran internal tests: Opus 4.5 looping in the Claude Agent SDK with only a high-level prompt — "build a clone of claude.ai." Two failure modes appeared:

Mode one: biting off more than it can chew. The agent tries to build the entire app in one go. Context exhausts, features are half-done, no docs, no comments. The next-round agent gets a half-finished product, spends massive time trying to understand what happened, then tries to fix it. After fixing, context exhausts again. The loop repeats.

Mode two: premature victory declaration. Early rounds built some features; the incoming agent sees "progress already exists" and declares the task complete. In reality, core functionality isn't done.

Both problems share the same root cause: the agent has no mechanism to understand "current state" and "remaining work." Every restart is amnesia.

---

2. First-Generation Harness: Initializer + Coding Agent

Justin Young's first-generation solution on the Anthropic engineering blog is remarkably simple: two agents, each handling one phase.

2.1 Initializer Agent

The first session is dedicated to "laying the foundation." It implements no features — only environment prep:

• init.sh: one-command script to start the dev server
• feature_list.json: expands the user's high-level prompt into 200+ concrete feature descriptions, all marked passes: false
• claude-progress.txt: a progress log recording what each round did
• Initial git commit: marks the project's starting point

The key insight: the feature list must be locked on day one. If the Coding Agent decides "what to do today" itself, it will either overreach or miss core features. The 200-item JSON list is a todo list — the agent doesn't need to "understand" the whole project, only "read" the next unfinished task.

JSON format was chosen deliberately. Claude has a stronger "editing impulse" on Markdown files — it can't resist rewriting, deleting, and merging sections. JSON's structure is more rigid; with one system-prompt line like "deleting or editing tests is unacceptable," the agent complies better.

2.2 Coding Agent

Each subsequent session does only three things:

1. Read state: pwd → git log → claude-progress.txt → feature_list.json → init.sh 2. Pick one feature: find the first entry with passes: false 3. Finish it: implement, test, git commit, update the progress log, mark passes: true

At each round's end, the environment must be in a "clean state" — code ready to merge to main. No major bugs, orderly code, complete docs.

2.3 Fixing the Testing Gap

Another failure mode: the agent implements a feature but never tests it, then marks it complete.

Anthropic's fix: give it Puppeteer MCP. The agent clicks, types, and screenshots like a real user. End-to-end verification with Claude's own screenshots is closer to real usage than any unit test.

There are limits: Claude can't see native browser alert modals, so features depending on such modals have higher bug rates. That's the current toolchain boundary.

---

3. Second-Generation Harness: Planner + Generator + Evaluator

The first generation solved "continuous work," but a ceiling arrived quickly. Prithvi Rajasekaran found that for more complex tasks, the bottleneck isn't "how to chain sessions" but "how to guarantee quality."

Inspired by GANs, he designed a three-agent architecture.

3.1 Core Insight: Generators Don't Criticize Themselves

Ask an agent to evaluate its own output and it tends to rate it highly. Even for an obviously mediocre design, it says "overall pretty good." This is especially fatal for subjective tasks — "is this design good?" has no binary answer.

Separating the worker from the judge is the lever. Tuning a standalone Evaluator to be skeptical is far easier than making a Generator critique its own work.

3.2 The Four-Dimension Scoring Rubric

In frontend design experiments, Rajasekaran built four judging dimensions:

Design quality: Does the design feel like an organic whole rather than assembled parts? Do colors, fonts, layout, and imagery jointly create a distinct atmosphere and identity?

Originality: Is there evidence of custom decisions, or all template defaults and AI-generated patterns? A human designer should be able to spot deliberate creative choices. Unmodified stock components and the purple-gradient-with-white-cards "AI slop" look all count as failures.

Craft: Technical execution — typographic hierarchy, spacing consistency, color harmony, contrast. This is a competence check, not a creativity check. Claude already does this well by default; failure means the fundamentals are broken.

Functionality: Usability apart from aesthetics. Can a user understand what the interface does, find the primary action, and complete a task without guessing?

Design quality and Originality carry the highest weight. Craft and Functionality are already Claude's strengths and don't need extra pushing. The point is pushing the model from "safe but mediocre" toward "risky but distinctive."

3.3 Division of Labor

Planner: receives a one-sentence prompt and expands it into a full product spec. E.g., "Create a 2D retro game maker" became 16 feature points across 10 sprints. The Planner is deliberately told not to specify implementation details — if it gets technical details wrong, errors cascade downstream. Define only deliverables; let the Generator find its own path.

Generator: works by sprint, one feature at a time. React + Vite + FastAPI + SQLite stack. Self-assesses at each sprint's end, then hands off to QA.

Evaluator: uses Playwright MCP to click through the running app, test API endpoints, and inspect database state. Scores against the four dimensions; hard thresholds decide sprint pass/fail. Failures get concrete feedback and the Generator redoes the work.

3.4 Sprint Contract

Before the Generator writes code, it and the Evaluator negotiate a "contract": what this round delivers and how completion is verified. Contracts are extremely fine-grained — Sprint 3's level editor alone had 27 verification criteria. This "align first, then implement" mechanism prevents "I thought I was done, but you never tested that" mismatches.

---

4. The Brutal Cost/Quality Comparison

Rajasekaran ran a stark comparison. Same prompt:

> "Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode."

| Dimension | Solo Agent | Full Harness | |------|-----------|-------------| | Duration | 20 min | 6 hours | | Cost | $9 | $200 | | Core functionality | broken | working | | Feature richness | basic editor | + AI-assisted generation + sound/music + shareable links | | UI quality | wasted layout, rigid workflows | full-screen canvas, consistent visual identity |

The solo agent's problem isn't just "doing less." It failed its most basic promised features — the link between entity definitions and game runtime was broken; the game couldn't run.

The harness output isn't just "more features." It delivered things the Generator wouldn't have thought of on its own: AI-assisted sprite generation, level design, sound effects and music. The Planner required "weaving AI features into the spec," and the Generator complied. A solo agent lacks that layer of product thinking.

---

5. Model Evolution Changes the Harness

Harnesses aren't static. Every model upgrade changes which harness components are load-bearing.

Opus 4.5 had a trait: context anxiety. It would wind down early as it approached what it believed was the context limit. This made compaction (compressing conversation history so the agent keeps working) insufficient — the agent would get anxious and quit before actually exhausting context. So the first-generation harness had to use context reset (fully clearing the context window and letting a new agent take over).

Opus 4.6 improved this: plans more carefully, sustains agentic tasks longer, better code review and debugging. So Rajasekaran ran an experiment: delete the sprint structure entirely and let the Generator run two hours in a single continuous session. It succeeded. The shift in the model's capability boundary directly made a core harness component unnecessary.

But the Evaluator stayed. Stronger models do more, but a gap remains between "can do" and "does well." The Evaluator has value only outside the Generator's capability boundary — inside it, it's overhead; outside, it's essential.

Anthropic's conclusion is clear: with every new model release, re-audit the harness — remove components that are no longer load-bearing, and add new capabilities the previous model couldn't handle.

---

6. From Game Maker to Digital Audio Workstation

The simplified harness was used on a harder project: a digital audio workstation (DAW) in the browser.

Prompt: "Build a fully featured DAW in the browser using the Web Audio API."

• Planner: 4.7 min, $0.46
• Generator Build Round 1: 2h 7min, $71.08
• QA Round 1: 8.8 min, $3.24
• Generator Build Round 2: 1h 2min, $36.89
• QA Round 2: 6.8 min, $3.09
• Generator Build Round 3: 10.9 min, $5.88
• QA Round 3: 9.6 min, $4.06

Total: 3h 50min, $124.70

Every QA round caught issues the Generator never noticed:

• Round 1: clips couldn't be dragged on the timeline; no instrument UI panels (synth knobs, drum pads); no visual effect editors (EQ curves, compressor graphs). "These aren't edge cases — they're core DAW interactions."
• Round 2: audio recording was still a stub (button toggles but no mic capture); clip resize-by-edge-drag unimplemented; effect visualization still numeric sliders rather than graphics.

The Generator still stubs features and misses details when nobody's watching. QA's value is the "last mile" — it's not that the Generator can't do it; it doesn't know it missed something.

The final DAW is far from professional grade, but core parts are all there: arrangement view, mixer, transport. The agent can even compose autonomously with tools — setting tempo and key, laying melodies, building drum tracks, adjusting mixer levels, adding reverb. Claude can't hear, so there's still a big gap in musical taste. But the infrastructure for "end-to-end autonomous music production" is in place.

---

7. The Essence of Harness Engineering

Many people read "harness" as "better prompt engineering." That's wrong.

Prompt engineering optimizes single-conversation quality. Harness engineering optimizes continuity across conversations. It doesn't care "what Claude said this round" but "how the next round knows what the last round left behind."

Its core problems are engineering problems, not language problems:

• State transfer: how does one round's context pass to the next? (Answer: structured files, not conversation summaries)
• Task decomposition: how do you slice a goal impossible in one window into agent-digestible chunks? (Answer: feature list, sprint contract)
• Quality control: the agent doesn't know if it did well — who tells it? (Answer: independent Evaluator, hard scoring criteria)
• Environment reproduction: after every restart, how does the agent quickly restore a working state? (Answer: init.sh, git log, progress file, regression tests)

None of the answers is "write a better prompt." They're all engineering infrastructure: file formats, git workflow, test tooling, multi-agent orchestration protocols.

---

8. What Developers Can Take Away

If you're using Claude Code, Cursor Agent, or any agent tooling on complex projects, these are directly actionable:

1. Session one builds no features — only foundations. init.sh, feature list, progress log, initial commit. Day one determines the efficiency of all days after. 2. Use JSON for the feature list, not Markdown. Markdown gets "casually rewritten" by agents too easily. JSON's structural rigidity is more reliable. 3. One thing per round. Do it, test it, commit, log, then start the next round. Overreach is the most common failure mode. 4. Give the agent a "real user testing" tool. Puppeteer MCP, Playwright, or even a curl script. Unit tests aren't enough — end-to-end is the truth. 5. Separate Generator and Evaluator. For any subjective quality requirement (design, copy, product experience), never let the same agent do and judge. Use an independent Evaluator with scoring criteria and skepticism. 6. Re-audit the harness after model upgrades. Previously load-bearing components may no longer be needed. Remove overhead; add new capabilities.

---

Epilogue: The Harness Space Won't Shrink

One view holds that as models get stronger, harnesses will vanish — the model will solve everything itself.

Anthropic's practice shows the opposite. The stronger the model, the larger the harness's combination space. Things models couldn't do before can now be outsourced to the model itself. But previously unthinkable complex tasks can now be brought within the harness's scope.

The boundary moves, but the harness won't disappear. It will only shift from "helping the model do what it can't" to "helping the model catch what it didn't know it missed."

Six hours, $200, three-agent collaboration. This isn't waste. It's a paradigm leap from "chatbot" to "engineering team."

---

References

• Effective harnesses for long-running agents: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Harness design for long-running application development: https://www.anthropic.com/engineering/harness-design-long-running-apps
• Building Effective Agents: https://www.anthropic.com/engineering/building-effective-agents
• Context engineering: https://www.anthropic.com/engineering/context-engineering
• Claude Agent SDK Quickstart: https://github.com/anthropics/anthropic-cookbook/tree/main/skills/agent-sdk