The Agent Harness Is the Product: Building for Work That Lasts Hours

When an agent answers a question in thirty seconds, the model can look like the whole system.

When an agent works for six hours, edits fifty files, uses twelve tools, survives a failed command, compresses its context, asks for approval, and resumes tomorrow, the illusion disappears.

The model is the reasoner. The harness is what keeps the reasoner employed.

In 2026, this distinction has moved from architecture trivia to product strategy. Long-running agents are useful precisely because they can cross the boundary between a response and a project. That requires infrastructure built for continuity.

TL;DR

An agent harness runs the loop around a model: it manages sessions, context, tools, environments, approvals, artifacts, retries, and progress. For long-running work, design the harness around durable state and observable milestones, not one immortal conversation. Keep the interfaces stable while allowing model-specific scaffolding to evolve.

The harness is everything around the model call

A production harness typically owns:

• the agent loop
• tool discovery and routing
• session history
• context compaction
• execution environments
• files and intermediate artifacts
• approvals and policy checks
• progress events
• retries and recovery
• traces, cost, and evaluation hooks

That list explains why two products using the same model can perform very differently. The surrounding system decides what the model can see, do, preserve, verify, and recover from.

OpenAI's Agents API architecture separates the harness, execution environment, and application server. Anthropic's description of managed agents uses a similarly useful decomposition: an append-only session, a harness that manages the loop, and a sandbox where work happens.

The names matter less than the separation of concerns.

Long-running does not mean one endless context window

It is tempting to imagine a long-running agent as a chatbot that simply refuses to stop. That design collapses under its own history.

Context fills with stale plans, verbose tool output, abandoned approaches, and repeated instructions. Compaction helps, but a summary is not a perfect continuation of lived experience. Important details disappear; irrelevant details survive because they sounded important at summary time.

The durable state of a project should live outside the model context:

• a task plan with explicit status
• files and generated artifacts
• test results
• decisions and rationale
• unresolved questions
• source-control history
• structured action receipts

The context window is working memory. The workspace is institutional memory.

Design for shifts, not marathons

Anthropic's work on effective harnesses for long-running agents compared the problem to engineers working in shifts. Each fresh session needs to understand what exists, what changed, what remains, and what state the workspace is in.

That suggests a simple operating rule: every work segment should leave the project easy to resume.

A clean handoff includes:

• current objective
• completed milestones
• next highest-value step
• known failures or risks
• commands or tests already run
• exact state of modified artifacts

This is not merely a prompt technique. It is a data model for continuity.

Use artifacts as anchors

Agents reason more reliably when progress becomes inspectable.

A plan should be a file or structured record, not a promise buried hundreds of messages ago. Research should produce a source table. Data work should produce a notebook or query. Code changes should exist in version control. A draft should be saved before critique begins.

Artifacts do three jobs:

1. They preserve work across context resets.
2. They let humans inspect progress without reading the full trace.
3. They give evaluators concrete outputs to test.

If the only proof of progress is the agent saying "I made progress," the harness is missing a load-bearing surface.

Checkpoint around consequences

Not every token needs a checkpoint. Every meaningful state transition does.

Useful checkpoint moments include:

• after a plan is approved
• before an irreversible external action
• after a coherent set of file changes
• when a dependency or assumption changes
• before context compaction
• after validation succeeds

A checkpoint should capture enough state to resume or roll forward safely. For code, that may be a commit plus test results. For operations, it may be a workflow state and idempotency key. For research, it may be a source-backed evidence bundle and hypothesis shortlist.

The goal is not to rewind the model's thoughts. It is to preserve the work's state.

Recovery is a first-class user experience

Long tasks fail. Networks time out, tools rate-limit, sandboxes restart, credentials expire, and models choose a bad path.

A mature harness can distinguish:

• retryable failure: temporary network or service issue
• repairable failure: malformed input, failing test, incomplete artifact
• policy stop: approval or authorization required
• terminal failure: the requested outcome is no longer achievable

Do not restart the entire mission for every failure. Resume from the last valid checkpoint, preserve evidence, and tell the user what changed.

This is where background queues remain useful, but the harness operates at a different level. A queue decides when work gets a worker. The harness decides how the agent thinks, acts, persists, and recovers once it has one. See Background Agents and Work Queues for the infrastructure layer underneath.

Make progress observable

"Still thinking" is not a progress model.

Emit events tied to meaningful state:

• plan created
• source collection complete
• implementation milestone passed
• validation failed
• approval requested
• artifact ready for review

Users need enough information to decide whether to wait, intervene, or redirect. Operators need enough information to diagnose a stuck run. Evaluators need enough information to compare strategies.

Keep private reasoning private. Expose plans, actions, evidence, state transitions, and outcomes.

The scaffolding must be disposable

Harness design has a strange maintenance problem: a workaround that helps today's model may hinder tomorrow's.

Anthropic's 2026 harness research describes systematically removing components to learn which pieces remained useful as models improved. This is the right instinct.

Separate durable contracts from temporary scaffolding.

Durable contracts include:

• session and artifact formats
• tool schemas
• approval records
• policy decisions
• progress events
• evaluation datasets

Temporary scaffolding includes:

• unusually detailed planning prompts
• forced context resets
• model-specific role decomposition
• repetitive reminders added to fix one model behavior

Version both, but do not confuse them. Stable interfaces let you improve the harness without migrating every product integration.

Evaluate the whole system

Model benchmarks cannot tell you whether the harness survives real work.

Evaluate missions that require:

• multiple context windows
• tool failures and retries
• interruption and resumption
• conflicting evidence
• human approval
• artifact validation
• cost and time limits

Measure final outcome quality, but also measure recovery rate, wasted work after failure, resume accuracy, approval clarity, and artifact completeness.

For a deeper evaluation strategy, see Benchmarks Are Not Production Evals.

A practical reference architecture

A strong default looks like this:

1. The application creates a session with a goal, constraints, budget, and policy scope.
2. The harness builds a plan and records milestones.
3. The environment provides isolated compute, files, and allowed network access.
4. The model works through tools and writes durable artifacts.
5. The harness emits structured progress and checkpoints.
6. Policy gates pause consequential actions for approval.
7. Validators inspect outputs before milestones close.
8. The session compacts or restarts using artifacts as the source of truth.
9. The final result includes deliverables, evidence, and an action receipt.

Start simpler than this when the task allows. Complexity should purchase measurable reliability.

Summary

Long-running agency is not a model feature you switch on. It is a systems property.

The model supplies judgment. The harness supplies continuity: a place to work, a record of what happened, a way to recover, and a contract with the application and the user.

Build the harness so no individual context window has to be heroic. That is how an impressive demo becomes dependable work.