Long-Running Agent Harnesses: Handoffs, Verification, and Recovery

When an agent’s work expands from minutes to hours or days, failure is often not a sudden loss of coding ability. A new session cannot tell what the previous session changed, which claims are trustworthy, or where a safe recovery point exists. Anthropic’s Effective harnesses for long-running agents frames this as an engineering shift staffed by people who arrive with no memory of the previous shift, then proposes an implementable handoff harness.

The useful lesson is not that this is a universal architecture. Anthropic tested a full-stack web-app workflow. The durable principle is narrower: move progress, completion criteria, startup instructions, and verification evidence out of model memory and into artifacts that the next session can inspect.

Why compaction does not solve the whole problem

Context compaction can summarize an earlier conversation, but it does not guarantee a complete summary, a clean workspace, or stable acceptance criteria. Anthropic observed two recurring failures:

1. Attempting too much at once. The agent tries to one-shot an application, exhausts context, and leaves an undocumented half-feature.
2. Declaring completion too early. A later session sees substantial existing code and mistakes visible progress for satisfied requirements.

The first failure lacks recoverable work units. The second lacks an external definition of done. A useful harness therefore governs how a session starts, how much it attempts, how completion is proven, and what must be left for the next session.

Two roles implementing one handoff protocol

Anthropic describes an initializer agent and a coding agent. A footnote matters: these are separate agents mainly because their initial prompts differ; the system prompt, tools, and overall harness are otherwise the same.

Initializer: establish a resumable baseline

The first session creates the shared interface subsequent sessions need:

• init.sh provides a consistent way to start the development environment.
• claude-progress.txt summarizes completed work, next actions, and known issues.
• An initial Git commit establishes a traceable, recoverable baseline.
• A feature inventory decomposes requirements into individually verifiable items that begin as failing.

The initializer’s value is not more documentation for its own sake. It reduces the cost of reconstructing the project model in every context window. Each artifact should be concise, structured, and mechanically checkable; otherwise, context debt has merely moved from chat into the repository.

Coding session: deliver a small increment and a clean state

Each subsequent session reads the progress record and Git history, starts the application, and runs a basic smoke test before choosing a small set of incomplete features. It then must:

• verify behavior through a real user flow, not only by reading code;
• move a feature from failing to passing only after verification;
• create an understandable checkpoint and record remaining risks;
• avoid ending with an environment that cannot start or needs unrelated cleanup.

Every session becomes a small reviewable change instead of an undocumented transfer of half-finished work.

Four artifact layers and what each can prove

Artifact	Question answered	Main weakness
Startup script	How is the environment reproduced?	Dependency and service drift can remain
Progress file	What did the previous session believe happened?	It can be stale or self-serving
Feature inventory	Which requirements remain incomplete?	Vague checks make “passing” meaningless
Git and test evidence	Which changes are reproducible and reversible?	Tests can miss user-visible behavior

The correct sequence is therefore: read the narrative index, then verify it against repository and runtime evidence. A prose handoff should never outrank executable evidence.

Why end-to-end verification matters

Anthropic gave the web-app agent browser automation so it could start the application, operate the UI, and inspect important flows. Unit tests or a successful HTTP response do not prove that an interaction works from a user’s perspective.

Browser automation is not conclusive either. Visual judgment, native dialogs, third-party authentication, nondeterministic data, and flaky tests can all produce false signals. A practical stack is layered:

1. Static analysis and type checking reject obvious defects quickly.
2. Unit and integration tests verify contracts and logic.
3. End-to-end smoke tests verify critical user journeys.
4. High-risk actions retain human review or a non-bypassable policy gate.

This matches the evaluation guidance in the AI Agent guide: use model judgment for ambiguous quality where needed, but assign deterministic conditions to deterministic verifiers.

Limits of the evidence

The source does not provide a cross-domain benchmark or prove that two prompt roles dominate every alternative. Its external-validity limits include:

• The experiment centers on full-stack web development; research, data pipelines, and operational workflows have different state models.
• A feature list fits discretely testable requirements but may prematurely constrain exploratory work.
• Anthropic explicitly leaves open whether one general agent or a multi-agent arrangement with specialized testing and cleanup roles performs best.

Adoption should therefore measure handoff failure rate, rework time, false-positive tests, and recovery cost per checkpoint—not merely count completed features.

A minimum viable adoption checklist

1. Provide one command that reconstructs and starts the environment.
2. Maintain an acceptance inventory whose meaning the agent cannot silently weaken.
3. Start every session by reading state, inspecting Git, and running a smoke test.
4. Complete one independently verifiable increment at a time.
5. Treat test output and diffs as evidence; use prose as an index.
6. Convert repeated failures into a linter, test, tool, or policy.

For the organization-wide layer, continue with Harness Engineering: Making a Codex Repository Legible, Verifiable, and Governable. For another long-running application pattern, see Harness Design for Long-Running Apps.

Primary sources

• Anthropic: Effective harnesses for long-running agents
• Anthropic autonomous coding quickstart