Video summary

Anthropic Workshop: Build Agents That Run for Hours — Ash Prabaker & Andrew Wilson

Main summary

Key takeaways

Technology

Summary of technical concepts & product/harness ideas (Anthropic Workshop)

Goal: agents that run for hours (5–6+), not just demos

The talk focuses on building “harnesses”—the scaffolding around an LLM agent—so agents can sustain continuous multi-hour sessions (up to ~12 hours in a simple benchmark scenario) and, with server-side support like compaction, potentially run for days.

The problem is framed as more than model quality: long-running autonomy stresses context, planning, and self-evaluation over time.

Why long-running agents are hard (3 buckets)

  1. Context limitations

    • Finite context windows cause session amnesia (requiring memory components).
    • Context rot reduces coherence deeper into the session.
    • Context sense anxiety can make the model rush near the end, degrading completion quality.

  2. Planning weaknesses

    • Models may try to do too much in one shot, stop early, or leave partially built work.

  3. Poor judgment of their own output

    • Models can become sycophantic/self-serving, declaring work “done” when it’s incomplete or missing functional backend logic.

Two approaches to extend agent run time

  1. Improve the model

    • The talk cites a trend (e.g., Opus 3.7 → Opus 4.6) where minimal scaffolding improved runtime from ~1 hour to ~12 hours.
    • General idea: newer models become more “agentic,” better at planning and executing longer horizons.

  2. Change the harness (scaffolding / Agent SDK)

    • The Agent SDK / Claude Code primitives evolve alongside models (“co-evolving harness + model releases”).
    • Harness primitives mentioned include:
      • Core agent loop (decide actions, run tools)
      • Tool usage and integration with MCP servers
      • Sub-agents (delegation)
      • Context sources (e.g., claude.md, loaded skills, slash commands)
      • Permission system
      • Verification loops (tests/smoke tests/patch-validation)

The harness can also run long-running workflows beyond coding.

Timeline highlights (how they got to long runs)

  • Early enabling capabilities

    • Artifact/code verification
    • Computer Use (clicking/screenshot-based actions)
    • MCP tool use

  • Claude Code / long-running harness evolution

    • Ralph Loop concept:
      • Break tasks into features and iterate via new sessions or compaction.
      • Emphasized “fail predictably” rather than unpredictable success.
    • Claude Code 2.0 / Agent SDK
      • Introduced checkpoints (rewind/restore prior code state).
      • Renamed to Agent SDK to generalize beyond pure coding.
    • Skills + progressive disclosure
      • Load only relevant parts of tools/skills early to save context.
    • Programmatic tool calling
      • Write code on the fly to orchestrate tool calls and reduce context bloat.
    • Server-side compaction
      • Allows effectively indefinite runs because compaction happens on the server.
    • Agent teams
      • Sub-agents coordinate and only report back when necessary; sub-agents can communicate (parallel/internal coordination).

“State of the art” patterns: adversarial generator–evaluator harness (GAN-inspired)

Ash describes an internal experimentation direction inspired by GANs:

  • Generator: builds the app/features.
  • Evaluator (critic): tests the output using Playwright by opening live pages, clicking around, and validating behavior.

They argue this is superior to purely “self-checking” because:

  • LLM self-evaluation can be biased (LLMs can rubber-stamp their own work).
  • A harsh standalone critic is often more tractable to tune than forcing the generator to self-criticize correctly.

How the system is structured

  • Roles are split across separate context windows/system prompts/jobs:
    • Planner → Generator/Builder → Evaluator/Critic
  • The evaluator does more than read diffs:
    • It actively runs the app (browser automation/testing), producing critique and/or scores.

Key innovation beyond RA(L)F loop

They add a planner that decomposes work into high-level sprints.

The generator and evaluator negotiate what “done” means before building:

  • They exchange/iterate using files on disk to create a more contract-based definition of requirements.
  • The evaluator grades against the agreed contract rather than only the initial vague spec.

This negotiation is presented as a gap that prior loops (e.g., fixed plan files) didn’t fully solve.

Example: retro game / “solo loop fails” vs harness succeeds

Using the same model/prompt (“build a retro game maker”):

  • Solo loop:

    • Output looked complete but failed functional play/testing.
    • Example issue: arrow keys/space didn’t work as expected.

  • Harness loop:

    • Produced a more complete game (“Retro Forge”), including:
      • sprite editor improvements,
      • play mode,
      • HUD/debug overlays,
      • working physics/game logic.

Reported run: ~6 hours and ~$200, with frequent iterative play/testing by the evaluator.

Critic design: “taste” can be graded with rubrics

The talk argues that “you can’t grade taste” is wrong if you:

  • Define a rubric with multiple criteria (they list 4):
    • Design
    • Originality
    • Craft
    • Functionality
  • Adjust weighting based on model capability (e.g., reduce “AI slop” via higher weights on design/originality).
  • Use few-shot calibration against reference sites so evaluator “taste” converges with their standards.

Long-run QA: tuning is done by reading traces

They claim out-of-the-box QA is weak; early runs may “decide” to “fix later” and stop.

Primary debugging method:

  • Read agent traces
  • Compare where model judgment diverges from human judgment
  • Then tune prompts/rubrics

Tooling tips:

  • Pipe transcripts to files
  • Use another agent to graph/summarize traces
  • Replay traces

Adapting harness as models improve (harness doesn’t disappear)

As model behavior changes, harness loops may be simplified:

  • They removed context resetting between sessions when Opus 4.6 reduced context anxiety.
  • For Opus 4.5, they needed specific sprint decomposition/cadence.
  • For Opus 4.6, they could run more end-of-generation evaluation rather than per-sprint.

Core loop remains generator–evaluator–planner, but some components can be dropped as the frontier moves.

“Final-ish” recommended setup + takeaways (practical checklist)

They propose a simplified architecture that still uses:

  • Planner–Generator–Evaluator loop
  • File-system shared state (rather than relying on long context windows for state)
  • A structured “contract” negotiated via files
  • Evaluator tooling like Playwright to test/rate real behavior

Five main takeaways

  1. Self-evaluation is a trap → use adversarial evaluator
  2. Compaction ≠ coherence (lossy summaries can drift)
  3. Structured hand-offs / clean contexts are strong patterns
  4. Don’t assume aesthetics are ungradable → write rubrics
  5. Read traces and iterate on the harness as models change

They also list “productizable primitives” already available in Claude Code/related tools:

  • auto mode (safer execution)
  • custom sub-agents
  • harsh system prompts + detailed re-break
  • Playwright MCP / Code for Chrome MCP
  • skills for packaging rubrics

Q&A highlights (important clarifications)

  • Evaluator tuning approach

    • Tune critics for reuse based on recurring model weak points (e.g., design/aesthetic failures), but adapt rubrics by app type.

  • Does the evaluator run indefinitely?

    • Not framed as “unlimited tokens”; looping continues until rubric satisfaction or stop criteria.
    • They emphasize restart behavior when progress stalls (models may discard work and restart if rubric isn’t improving).

  • Playwright MCP / why not watch live?

    • They prefer trusting automated testing rather than observing everything live (a trust gap vs “test-and-return”).

  • Human-in-the-loop

    • Target is minimal human involvement; hooks are optional stop/continue points.

  • Traceability

    • Manual trace reading is still best; they sometimes have agents inspect traces with custom prompts.

Main speakers / sources

  • Ash Prabaker (Applied AI engineer, Anthropic)
  • Andrew Wilson (Applied AI team, Anthropic; solution architect based in London)

Original video