Introduction

A coding agent that performs well for ten minutes can still fail badly after two hours. It may forget the original goal, repeat finished work, declare victory before testing, or keep polishing one component while the rest of the application remains broken.

The model matters, but it is only one part of the system. The agent harness decides what the model sees, which tools it can use, how work is divided, what survives between turns, and how completion is checked.

Recent long-running software experiments point to a durable idea: plans coordinate work, artifacts preserve state, and evaluators turn vague quality goals into concrete checks.

Why a Longer Context Window Is Not a Project Plan

More context helps an agent remember, but memory alone does not create structure. A long transcript mixes useful decisions with command output, failed attempts, and stale assumptions. Eventually the model must infer which details still matter.

A harness should keep three forms of state distinct:

The transcript can contain all three, but it should not be their only home. A small plan file gives the agent a stable checklist. Test reports and screenshots give a later evaluator something concrete to inspect. The repository remains the source of truth for the implementation.

# Work plan

- [x] Define the note schema
- [x] Add API routes and validation
- [ ] Build search and empty states
- [ ] Run unit tests and browser checks

## Decisions

- Search is case-insensitive.
- Empty queries return recent notes.

## Evidence

- API tests: 18 passed
- UI verification: pending

This is deliberately boring. Long-running work benefits from state that is easy to inspect, update, and hand to another process.

Decompose by Verifiable Outcomes

Weak plans describe activity: “work on the frontend” or “improve the API.” Strong plans describe an observable outcome and its verification.

tasks = [
    {
        "outcome": "Invalid note payloads return HTTP 422",
        "files": ["app/api/notes.py", "tests/test_notes.py"],
        "verify": "uv run pytest tests/test_notes.py -q",
    },
    {
        "outcome": "Search results update without a page reload",
        "files": ["src/pages/notes.tsx"],
        "verify": "bun run test notes-search",
    },
]

Outcome-based tasks reduce ambiguity for both the implementing agent and the reviewer. They also limit cascading errors: if the API contract is wrong, the harness can stop before building a UI on top of it.

The pieces should be large enough to produce meaningful progress and small enough to verify independently. Excessive decomposition creates coordination overhead; vague decomposition leaves the agent to rediscover the project structure on every turn.

Use Artifacts for Handoffs

Long tasks often cross context resets, process restarts, or agent boundaries. A good handoff answers five questions:

1. What is the goal?
2. What is finished?
3. What evidence supports that claim?
4. What remains uncertain?
5. What should happen next?

The handoff should point to durable artifacts instead of copying large outputs into prose. A test log has more value than “tests look good.” A screenshot path is easier to verify than a long visual description. A commit or diff identifies the exact implementation under review.

Avoid treating a summary as an authoritative record. Summaries are lossy by design. The next agent should be able to inspect the files and rerun the checks that matter.

Add an Evaluator With a Different Job

An evaluator should judge the result against explicit criteria rather than continue implementing it. For a small web application, a rubric might include:

functional:
  - create, edit, search, and delete flows work
  - invalid input is rejected
quality:
  - relevant automated checks pass
  - no browser console errors occur
usability:
  - loading, empty, and error states are visible
scope:
  - implementation matches the requested feature

The evaluator can inspect the diff, run tests, and exercise the application. It should return specific failures with evidence. The implementing agent then fixes those failures and resubmits the result.

This resembles a generator-evaluator loop, but additional agents are not automatically better. A simple task may need only one agent plus deterministic tests. Add a separate evaluator when the work is long, quality is multi-dimensional, or the implementer repeatedly misses the same class of issue.

Test the Harness, Not Just the Application

Harness changes should be evaluated like application changes. Create a small set of representative tasks and compare:

• completion rate against the same acceptance criteria;
• unnecessary file changes;
• test and review failures;
• elapsed time and model usage;
• recovery after an interrupted run.

Run multiple trials when model variability matters. Record the model, harness version, environment, and task fixture. A single successful demo cannot show that a three-agent design is generally superior.

Recent work on long-running application development also offers an important warning: harness components encode assumptions about what a model cannot do. Those assumptions can become stale. Periodically remove a planner, reset, or evaluator step and measure whether it still earns its complexity.

Conclusion

Long-running agents need more than a large context window. A useful harness turns a goal into verifiable outcomes, stores durable evidence outside the transcript, and gives evaluation a clear role.

Start with one agent, a visible plan, and deterministic checks. Add handoffs and evaluator loops when measured failures justify them. The best harness is not the most elaborate one; it is the smallest system that keeps long work coherent and reviewable.

References

• Harness design for long-running application development, Anthropic, 24 March 2026
• Building effective agents, Anthropic, 19 December 2024