Planner, Generator, Evaluator: Anthropic's Three-Agent Harness for Long-Running Agents That Never Forget

When agents run for hours across context resets, Anthropic's three-role harness — Planner, Generator, Evaluator — with structured handoff files prevents context drift and compounding errors across sessions.

Longer context windows are a footgun. When a long-running agent works in a single expanding window, it accumulates "context anxiety" — the model starts wrapping up prematurely and cutting corners as it senses the session ending. Anthropic's engineering blog addresses this directly with a harness built around context resets, not compression.

The three roles

Planner — runs once at the start. Takes the high-level requirement and expands it into a structured product spec: a JSON feature list where every feature has a clear acceptance criterion. JSON over Markdown is intentional — models are less likely to accidentally overwrite or mangle a structured file than a freeform doc.

Generator — runs in each fresh session. Reads the feature list and progress file, picks one pending feature, implements it, commits to git, and updates the progress log. One feature per session, never a multi-feature sprint, to avoid the one-shot failure mode where the model tries to do everything and finishes nothing cleanly.

Evaluator — also runs each session, separately from the Generator. Opens a browser (Playwright or similar), exercises the just-committed feature end-to-end, and writes structured pass/fail feedback to a shared file the next Generator session reads. The separation is load-bearing: when a model self-evaluates its own output, it tends to confidently praise mediocre work. An external evaluator creates actionable feedback loops.

The handoff artifacts

Three files are the project's memory across context resets:

feature_list.json    # Planner output; marks each feature passing / failing / pending
progress.md          # Per-session summary: what ran, what the next session picks up
CLAUDE.md            # Env setup, dev server commands, repo conventions

At the start of every Generator or Evaluator session, the harness prepends instructions to read these three files and check git log --oneline -20 before writing a single line of code. The agent's memory is the files plus the commit history — not the conversation history.

The sprint contract

Before each Generator session starts implementing, the harness asks Generator and Evaluator to agree on testable success criteria for this session's feature. This "sprint contract" bridges the gap between the Planner's abstract spec and the Evaluator's concrete browser tests. Without it, you get endless disagreement about what "working" means.

Minimal implementation sketch

def run_session(role: str, feature_list_path: str, progress_path: str):
    prompt = f"""
You are the {role}. Before doing anything else:
1. Read {feature_list_path} — find the next pending feature
2. Read {progress_path} — understand what the last session completed
3. Run `git log --oneline -20` and verify the dev server starts

Then: {'implement exactly one feature and commit' if role == 'Generator' else
       'test the last committed feature and write pass/fail to progress.md'}
"""
    response = client.messages.create(
        model="claude-opus-5",
        max_tokens=8096,
        messages=[{"role": "user", "content": prompt}],
        tools=[bash_tool, file_read_tool, file_write_tool],
    )
    # run agentic tool-use loop until stop_reason == "end_turn"

The critical point is what happens between sessions: the harness resets the conversation, re-reads artifacts from disk, and starts completely fresh — not from a compacted summary.

When to strip components

Every component in a harness encodes an assumption about what the model cannot do on its own. As models improve, previously necessary scaffolding becomes overhead. If your model self-evaluates reliably on the task, collapse Generator and Evaluator into one. If the Planner simply restates the prompt, skip it. Audit your harness assumptions after every model upgrade — the right harness for Claude 3 is probably over-engineered for Claude 5.

Sources: Effective Harnesses for Long-Running Agents — Anthropic Engineering · Harness Design for Long-Running Application Development — Anthropic Engineering