How to Build Agents That Run for Hours (Without Losing the Plot)

A company shows an agent building a browser from a single prompt. The run lasts five or six hours, and the finished application looks impressive. What usually remains invisible is the harness: the machinery that keeps the agent moving, preserves its progress, and determines whether the result actually works. That missing machinery is the subject of Ash Prabaker and Andrew Wilson’s session, drawing on their work in Anthropic’s Applied AI team and the experiments described in Harness design for long-running application development.

Wilson, a London-based solution architect, starts with the speed of the change. He recounts Boris Cherny’s anniversary description of Claude Code: early versions struggled with Bash commands and string escaping; later versions could sustain much longer work and write much of Claude Code itself. In Wilson’s retelling, roughly 20-minute runs had given way to runs lasting days.

Sustained work still breaks down in three distinct ways:

• Context: a fresh session forgets what happened before. Within a session, accumulated context can become less coherent; near the limit, a model may rush to finish, a behavior the speakers call context anxiety.
• Planning: the agent attempts too much at once, leaves a feature half-built, or exhausts its context before reaching a usable stopping point.
• Self-judgment: the agent accepts an incomplete result. A button looks finished even though no backend exists behind it.

The third failure is especially deceptive: a convincing interface can hide an application that does not perform its central task.

One route to improvement is to put more capability into the model weights. Wilson illustrates that progress with METR’s task-completion time horizons, describing a rise from approximately one hour for Sonnet 3.7 to twelve hours for Opus 4.6 at 50% success with a minimal scaffold. Here, the hours measure the time a human expert would need for the tasks, not uninterrupted agent runtime. The chart therefore concerns the difficulty of work an agent can complete, rather than how long a process can stay alive.

The other route is to improve the scaffolding around the model. The Claude Agent SDK supplies the core loop: Claude decides what to do, calls tools, receives results, and continues. Around that loop sit MCP connections, sub-agents, project instructions such as CLAUDE.md, skills, slash commands, and permissions. An application combines these primitives into a harness suited to its task.

The history is a sequence of changes on both sides. Sonnet 3.5 and artifacts made coding and visual iteration more useful; computer use added screenshots and clicks, while MCP supplied a standard way to connect tools. In February 2025, Sonnet 3.7 arrived with strong SWE-bench positioning and Claude Code entered research preview. That preview was also a way to learn how developers used the model and feed those lessons into model improvements. By May, Opus 4 and Sonnet 4 brought better context management and task completion, Claude Code became generally available, and the Claude Code SDK exposed its harness. Context, planning, and verification were advancing together.

Geoffrey Huntley’s Ralph Wiggum technique appeared in July 2025 and, Wilson recalls, attracted much wider attention around December. Its recognizable core is simple: repeatedly feed a prompt into a coding agent. The useful version includes planning, a breakdown into features, and selection of one task to execute in a fresh session. Predictable failure gives the developer something concrete to inspect and improve.

The Claude Code Ralph Wiggum plugin makes a consequentially different choice:

In the plugin, a maximum iteration count and a completion promise provide exit conditions. If Claude tries to stop before completion, the hook returns it to the task. Repetition, context renewal, and stopping are separate design decisions, even when all three are packaged as a loop.

Sonnet 4.5 became more aware of consumed tokens and the approaching context limit. Claude Code 2.0 added checkpoints and rewind, while the Claude Code SDK became the Agent SDK to reflect uses beyond coding. Wilson reports roughly 30-hour Sonnet 4.5 runs, without specifying a benchmark. With Haiku 4.5 and Opus 4.5, specialized roles also became more practical: inexpensive sub-agents could handle delegated work, Opus could plan, and Sonnet could execute.

Two further mechanisms reduce the amount of material the model must carry:

• Skills use progressive disclosure. Load the front matter first, the body when the skill is needed, and supporting references or executable code afterward. Instructions that are irrelevant to the current task need not occupy the window from the beginning.
• Programmatic tool calling keeps intermediate work in code. Instead of returning every tool result to the model and asking it to process the pile, generated code runs a sequence of calls and returns the result that matters.

Both approaches preserve context for decisions rather than filling it with material that could remain outside the conversation.

The November pattern described in Effective harnesses for long-running agents starts with a request such as building a browser, a Slack clone, or a Salesforce clone. An initializer translates that request into persistent artifacts: feature_list.json, a progress file, a Git repository, an initialization script, and flags recording whether features pass their tests. The team preferred JSON for the feature list because its models were less likely to overwrite it than Markdown; the format itself does not prevent destructive edits.

Each subsequent coding session follows a bounded procedure:

1. Establish the working directory and read the progress record.
2. Run the initialization script and a smoke test so the server starts from a known working state.
3. Select exactly one feature whose tests do not pass.
4. Implement it and exercise the application with Puppeteer.
5. If verification succeeds, commit the code and mark the feature as passing.
6. If unfinished features remain, begin another session with fresh context.

The durable artifacts carry the state across sessions. The agent does not have to reconstruct the launch command or infer completion from a previous conversation’s confident prose.

For example, a feature record can make a pending browser check explicit:

{
  "category": "functional",
  "description": "A user can send a message in a channel",
  "steps": [
    "Open an existing channel",
    "Enter a message and submit it",
    "Verify that the message appears in the channel",
    "Reload and verify that the message remains"
  ],
  "passes": false
}

This illustrative record remains pending until the session verifies the behavior. A rendered message box alone would not satisfy the listed checks.

Wilson positions Sonnet 4.6 as a workhorse approaching Opus-level capability at Sonnet pricing, and Opus 4.6 as particularly strong at planning and tool selection. He describes the latter’s METR advance as roughly four to twelve hours on the earlier task-horizon measure. Alongside the models, agent teams enabled peers to communicate directly instead of routing every exchange through a main agent. Server-side compaction and generally available million-token context windows expanded the options for continuing within a session.

Wilson reports seeing fully featured applications that work out of the box after roughly three to five hours. His larger point is that the harness remains a moving target: identify a model’s gap, compensate for it in scaffolding, improve the model against that capability, and eventually remove the compensation. A component that was essential for one generation can become unnecessary overhead for the next.

Prabaker’s experimental harnesses target a familiar failure: ask an agent to review its own pull request, and it often approves work that deserves another pass. These experiments support both application demonstrations and investigations into better autonomous behavior during post-training. The architectural analogy comes from generative adversarial networks: a generator builds while a separate evaluator applies pressure. This application loop borrows the division of roles; it is not itself GAN training.

The generator and evaluator have separate contexts, system prompts, and responsibilities. The evaluator does more than read diffs. It opens the live application with Playwright, navigates pages, clicks controls, tries workflows, and sends a critique back to the builder. That creates an independent encounter with the output instead of asking the same session to admire and revise its own work.

Why would another LLM be less generous? It still has preferences and biases, including a tendency to like LLM-style output. Prabaker’s practical observation is narrower: tuning a dedicated critic to be demanding is tractable, while making a builder reliably self-critical is much harder. Recognizing flaws in a painting or a meal does not require being able to produce a better one. The harness exploits that gap between criticism and construction.

A working web application also has to look and feel right. Prabaker treats these judgments much like other evaluations: make the desired qualities explicit enough that a critic can apply them. The team’s rubric has four dimensions—design, originality, craft, and functionality—with greater weight on design and originality when the model already handles functionality well. Reference sites and short examples calibrate the evaluator toward the team’s taste, including what should count against generic purple-gradient aesthetics.

The resulting cycle is concrete: the generator produces a page; the evaluator launches Playwright, navigates, captures screenshots, scores the rubric, and writes a critique; the generator revises. Prabaker describes HTML-and-CSS-only examples running for about four hours over five to fifteen rounds.

The useful behavior is not just incremental polish. If originality stays low, the builder can abandon the design and start again. Prabaker contrasts that with a single generation or a loop that keeps patching the same approach. Separating the roles makes it easier for one agent to reject a direction in which the other has already invested substantial work. The museum example shown here depicts the resulting virtual gallery, with framed paintings, blue walls, and a checkered floor.

To move from attractive pages to complete applications, the harness adds a planner. It expands a one-line request into high-level workflows and sprints, deliberately avoiding a detailed technical blueprint. An incorrect implementation decision made at the beginning can otherwise propagate through every later sprint. The arrangement resembles a product manager, an individual contributor, and QA, each with its own context.

Before implementation, the builder and evaluator negotiate an acceptance contract:

1. The generator proposes the feature it will build and the tests that should demonstrate success.
2. The evaluator challenges excessive scope, weak tests, and missing edge cases.
3. They exchange Markdown files on disk until they agree.
4. The generator builds, and the evaluator grades the result against that agreement.

The contract turns a broad user story into testable assertions without requiring the planner to foresee every technical detail. Unlike a fixed plan.md that the execution loop simply follows, this plan has an opposing reader who can reject an inadequate definition of done.

The comparison begins with the prompt “Build a retro game maker.” Prabaker runs it with the same model in a solo loop and in the planner–generator–evaluator harness. He explicitly presents the latter as an expensive experiment, not an efficient default way to build an application.

The solo result initially looks plausible. Its sprite editor has a canvas, palette, frame timeline, and live preview, although the layout is cramped and the color picker shows black swatches. Then comes play mode: entities render, and score and health are visible, but arrow keys do nothing. The space key does nothing either. The agent understood the appearance of a game maker without establishing that a user could actually play a game.

Prabaker reports that the harness run took about six hours and cost about $200. The resulting application named itself Retro Forge, created a new-project dialog, and supplied a more developed canvas. Those product choices came from the planner, not additional user instructions. Its sprite editor includes a 54-color palette, carries the eight-bit preset through from project creation, and previews a sprite at actual game scale.

A broad planner requirement for AI features also became an in-app level assistant. A user could request a castle with sprites guarding it, giving the builder and evaluator a substantial workflow to implement beyond the editor itself. In play mode, a debug HUD exposes live values useful to the evaluator. The physics loop runs, arrow keys move the player, and the player collides with castle walls. The decisive difference is that the evaluator launched the game and tried to play it.

The evaluator found ordinary integration bugs with substantial consequences: FastAPI route ordering that Prabaker says passed unit tests but could break in production, and a Boolean-logic error affecting the delete key. These appeared through application use. The contract supplied enough detail to turn the failures into repair work: the companion account identifies 27 acceptance criteria for Retro Forge’s level-editor sprint. Broad criteria tend to produce broad complaints; a precise failed assertion tells the generator what behavior to fix.

A separate QA agent was not automatically a good QA agent. Early versions found bugs and then deferred them rather than requiring a fix. The team spent substantial effort examining small layout defects, edge cases, and overly generous judgments, then incorporating those lessons into prompts.

Reading traces was the primary debugging loop. The team inspected what the agent actually did, identified where its judgment diverged from a human reviewer’s, and changed the instructions at that point. Saving transcripts to files also allowed another agent to inspect or graph them and suggest prompt changes. More runs were useful only when the team understood what it was trying to improve.

Harness design begins with the uneven capabilities of the particular model. In the talk, Prabaker attributes context anxiety to Opus 4.5 and says it disappeared in the team’s Opus 4.6 experiments, allowing them to drop session resets. The companion article places that transition earlier, from Sonnet 4.5 to Opus 4.5. Both accounts support the practical rule: remove resets when observed coherence makes them unnecessary, rather than treating a model label as a sufficient reason.

Prabaker reports that Opus 4.6 sustained a coherent two-hour continuous build without being fed one feature at a time. That changed both task decomposition and evaluation cadence:

The planner–generator–evaluator structure survived. The team removed some of the scheduling machinery around it, while retaining a filesystem that all roles could inspect.

The simplified harness produces a digital audio workstation. Prabaker describes this example as costing roughly half as much as earlier runs, although it is a different task rather than a matched cost comparison. The evaluator operates the application: setting tempo and key, laying down a melody, and building drum tracks.

The humans also listen. Their verdict is that the application is well developed, but the music is poor. In this setup, Claude could operate the controls but could not hear the result. A successful interaction test therefore did not establish musical quality. Prabaker reports reaching the developed application in only a couple of rounds.

The available primitives already support experiments with this pattern: auto mode offers an alternative to routinely using --dangerously-skip-permissions; a custom sub-agent can carry a demanding QA prompt; Playwright MCP or Claude for Chrome MCP can drive web applications; computer use can exercise native applications; and skills can package grading rubrics. Permission behavior is version-dependent, so auto mode should not be read as a blanket safety guarantee.

Continuous sessions also do not eliminate the need for disciplined handoffs. Compaction produces lossy summaries, and those summaries can drift. Explicit criteria, structured shared state, and clean role boundaries still matter even when a newer model no longer needs frequent resets. Reading the traces is how the team decides which safeguards to keep and which to delete.

Joanne from Poolside asks whether evaluator tuning is specific to each project. The goal, Prabaker explains, is to capture recurring model weaknesses. Examples of strong product design and generic generated design can teach a reusable distinction. The experiments center on web applications; applying the same calibration process elsewhere requires an appropriate view of quality for that domain.

An audience question then proposes fixed context thresholds for a model’s smart and degraded zones. Neither speaker endorses those thresholds. Wilson instead makes the choice empirical: fresh sessions or one continuous session should depend on the use case and evaluations. Their Opus 4.6 generator–evaluator setup worked with compaction in a single session. Prabaker still sees a place for context-reset patterns, while looking for model improvements that let him remove them.

For browser testing, a question about watching and steering the agent leads to a distinction between initial supervision and eventual trust. Prabaker recommends Playwright MCP or Claude for Chrome MCP, describing the latter as somewhat more robust. He starts by observing and reading traces, then moves toward unattended operation once the behavior is reliable. In his Opus 4.6 work, that includes reading network and console errors, navigating and zooming, and visually recognizing overlapping text.

Can more tokens keep improving the result indefinitely, or does the evaluator eventually give up? Prabaker answers with observed behavior rather than a scaling guarantee. Hooks can add human feedback, but the surprising behavior in the 4.6 experiments was the agents’ willingness to discard substantial work when they stopped improving against the rubric. An evaluator could explicitly request a fresh start. The team did not observe the anticipated pattern of simply surrendering and passing the result onward, so a dedicated intervention or resume mechanism was not central to those experiments.

The generated repository remains available for ordinary development: open it in Claude Code and continue. Wilson also leaves room for intermediate feedback when the duration of a large build is hard to predict. Autonomy and later human iteration are compatible workflows.

A related question asks whether the planner should return to manage scope. In this harness, the original specification is regularly inserted into builder and evaluator sessions as a reference point. Those two roles negotiate the exact features, tests, and contracts; the planner defines the outer product boundary without repeatedly rewriting it.

The same division can extend through a longer workflow. A synthetic-dataset generator might have its own QA agent, then pass its output to an integrator with a different QA agent. Each builder has a specific job, and each critic evaluates the output relevant to that stage. The adversarial relationship is reusable even when the whole system contains more than one generator–evaluator pair.

Asked how the team compares model–harness combinations, Wilson returns to their co-evolution. The earlier initializer could enumerate hundreds of features, forcing later sessions to execute mistaken design decisions. A stronger model permits broader creative direction and more adaptive evaluation. Cost can also justify splitting roles—for example, Opus 4.6 for planning and Sonnet 4.6 for execution. Each sub-agent’s model and prompt should be evaluated against its particular task; the answer does not establish a controlled comparison protocol for the demonstrations.

Long-lived products need more than a finished initial run. Prabaker describes starting work on a remote server, returning later, and polishing the code manually. Filesystem state makes that continuation practical because a later model can search it and reconstruct what happened. Prompts throughout the loop ask the agent to record learnings in JSON, leaving durable breadcrumbs rather than relying on the surviving conversation.

The useful handoff has two parts:

• A timestamped work log: what the agent tried, what bug the evaluator found, what fix was applied, whether it worked, and the resulting state.
• Living project documentation: a high-level description of the repository and its file structure.

Prabaker reports that these artifacts are sufficient for the team’s current human-and-Claude-Code continuation workflow. They preserve both the shape of the application and the failed approaches a new session should not have to rediscover.

Agent teams and generator–evaluator harnesses are compatible. A generator and evaluator can be communicating teammates, or the generator can be the main agent with an evaluator alongside it. Claude Code and the Agent SDK share harness foundations, making Claude Code a useful place to prototype the interaction before packaging it as an application. The SDK also supports running in cloud and sandbox environments, avoiding dependence on a developer’s laptop remaining awake.

Neither speaker offers one permanently preferred orchestration shape. Internally popular primitives are shipped for broader experimentation and may later be removed. A frontend agent, backend agent, and integrator could each have a critic; a six-hour autonomous application build is simply a more specialized workflow than the default Claude Code interaction.

That flexibility does not mean sharing all context indiscriminately. When asked whether the critic receives the generator’s traces, Prabaker says the team tried it and preferred a structured handoff. The evaluator should identify an output defect, leaving the generator to diagnose its cause and repair it. Feeding the builder’s reasoning into the critic can also feed its mistaken confidence into the critic. An audience suggestion to train generators to anticipate criticism remains a possible direction, not an announced capability.

Finding the failure point across several agents remains labor-intensive. Prabaker describes custom prompts that ask Claude to scan traces and identify where a loop veered off, using that as an initial pass. The team still prefers reading the traces manually to understand the model’s decisions; he does not point to a solved trace-discovery interface.

For quality measurement, detailed rubrics provide a starting and ending signal. Separate criteria can cover visual design, API design, and code quality. With an existing repository, begin by having the evaluator establish the current state, then supply the intended change and let builder–evaluator negotiation produce the relevant contracts and tests. These measurements help assess progress within a product or run, but Prabaker says they are not very comparable across different products and runs.

The harness also carries assumptions about the application it is building. Wilson gives React, Postgres, and Node as an example of an opinionated greenfield stack. An existing application may use different technologies and design conventions. Its evaluator needs those conventions, rather than an unrelated rubric imported unchanged.

Team ownership is similarly still developing. Prabaker describes bottom-up adoption, with the original idea holder—Prithvi in this case—maintaining a composable harness that other teams adapt. Shared conversational work and observability for very long runs remain incompletely solved. Wilson recommends familiar engineering controls: version control, commits, pull requests, and Git worktrees to keep concurrent feature work from overwriting the same files.

A sprint-review-style checkpoint is straightforward to add: an evaluator reaches a specified stop condition, a hook hands control to a human, the human supplies a developer message, and the loop continues. Prabaker emphasizes that the team is exploring how much work can become autonomous, not claiming that it uses this approach for everything.

The harder question is whether a recurring human correction should become permanent. In Prabaker’s research workflow, a batch of successful and failed runs supplies material for diagnosis: inspect the failures, adjust the harness prompts, and try again. The ambition is to encode recurring steering lessons into the system so that the same intervention is no longer necessary. That leaves room for human checkpoints while making their necessity something to investigate.

Production applicability is narrower than the demonstrations might suggest. Wilson says the complete pattern is primarily suited to greenfield work unless it receives substantial project-specific testing and customization. For an existing product, a more bounded lifecycle can begin with autonomous monitoring, create an issue or feature request, hand it to an implementation agent, produce a pull request, and pass through automated and human review before merge.

Prabaker does not identify a particular internal production tool built end to end by this harness. He instead describes lessons reused in Claude Code development and monitoring or bug-fixing workflows, including assigning separate agents to generate and evaluate a repair. Adopting those parts does not require adopting the entire one-shot application workflow.

The final question makes trace reading literal: does it mean raw output, or a summary the agent was asked to write? Prabaker’s answer is to read the whole thing. A summary can identify a symptom while hiding the observation that made a wrong action seem reasonable.

During work on Claude for Chrome, the team used a physical analogy: imagine navigating a page with your eyes closed, opening them only periodically to see a static snapshot, then closing them again before acting. That is much closer to the agent’s experience than continuously watching a browser. Reading line by line lets a developer reconstruct what the model could see, why it chose an action, and what instruction or environmental change would have helped.

Those discoveries belong in durable instructions: prompt templates, CLAUDE.md, or skills that prevent the same failure in a later session. Wilson also points to Claude Code’s auto memory as a way to retain session learnings. The work of improving a long-running agent continues after identifying the bug: preserve the lesson where the next run can use it.