# The agent harness is becoming a runtime

> OpenCode 2.0, Pi 1.0, Codex, and Claude Code point toward a different question: how should useful work survive beyond a single conversation?

Author: HARTRO
Published: 2026-10-02
Updated: 2026-10-15
Topics: Agents
Canonical URL: https://hartro.com/blog/agent-harness-runtime/

![Source code on a computer screen. Editorial photograph by Fili Santillán.](https://hartro.com/assets/stories/source-code.webp)

Close the terminal halfway through an agent's task. Open a different interface. Ask what is still running, what changed, and where the agent needs your attention.

I would use that exercise when choosing a harness. I want to know what survives an interruption and how I can recover the work.

A harness is the software around a model: the loop that supplies context, executes tools, records progress, and decides when work can continue. Its importance grows with the amount of responsibility we give the agent. A lost response is irritating. A lost deployment state, experiment, or background job is an operational problem.

By runtime, I mean a system that gives tasks an identity and a lifecycle: where they execute, which state survives interruption, and how someone can inspect, resume, or stop them. A shared server can keep work running when a client disconnects. Recovering after the server or its execution environment fails requires additional machinery.

OpenCode and Pi show two ways of approaching this. OpenCode is becoming a shared service behind several interfaces. Pi is keeping its core small while experimenting with a separate durable substrate. The implementations differ, but both confront a question that a chat window handles poorly: what is the lifetime of the work?

## From an answer to an ongoing task

The early coding-assistant interaction was easy to understand. Select code, request a change, inspect the suggestion. The developer held most of the state: which files mattered, what had already failed, whether tests were still running.

A tool-using agent takes on more of that burden. It searches the repository, edits files, launches commands, and interprets the results. Once tasks extend across context windows or involve background workers, the harness must preserve facts that cannot safely live only in a model's working memory.

Anthropic's earlier work on long-running agents illustrates this with explicit progress records, incremental implementation, and verification between sessions. The useful principle is continuity: a fresh context should inherit enough evidence to continue from the actual project state. [Anthropic's long-running harness design](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)

![People and applications connect to an agent runtime that records task identity, context, progress, and recovery state. Tool calls flow to an execution environment, and evidence flows back.](/assets/blog/agent-runtime.svg "A conceptual separation of responsibilities, not a claim that every harness implements every layer.")

## OpenCode: several interfaces, one running system

In [OpenCode 2.0](https://anoma.ly/notes/opencode-2-0/), the background server becomes the default shared process behind the terminal, web, and desktop interfaces. The release also introduces code-based tool composition, asynchronous shell work and subagents, and a library interface to the same underlying implementation. MCP tools are discovered and composed through Code Mode rather than all occupying the active context upfront.

The change I care about is being able to open another interface onto the same ongoing task.

For a team, that raises useful questions. Can a task continue while its original interface disconnects? Can someone inspect its progress without disturbing it? Are running commands represented by durable handles, or merely mentioned in a transcript? A shared service makes those questions possible to answer; reliability still has to be demonstrated.

## Pi: make the boundary explicit

[Pi 1.0](https://earendil.com/posts/pi-1-0/), released on October 1, takes a different route. Its additions include Codemode, deferred tool loading, virtual-model extensions, and transcript-aware changes to prompts and tools. Earendil is also releasing Pi Durable as a separate experimental package for longer-running agent applications, rather than making the minimal coding harness absorb every new responsibility.

I like the separation. A small loop is easier to understand and customize. A durable application has additional obligations: reconnecting clients, persisting state, coordinating work, and explaining recovery. Combining them can be convenient, but keeping the boundary visible makes the tradeoff easier to reason about.

Pi Durable is experimental. Its announcement is evidence of a design direction, rather than proof that every long-running workflow is already solved.

## Codex and Claude Code are working on the same underlying problems

There are two layers to distinguish here: the coding products people use directly, and the providers' infrastructure for building agent applications. Features of one should not be assumed to exist in the other.

At the infrastructure layer, OpenAI's current [Agents API architecture](https://developers.openai.com/api/docs/guides/agents-api/architecture) separates the managed Codex harness from its execution environment. The harness maintains the session and routes work; the environment supplies compute and files. Applications can use hosted environments or connect their own. This makes the distinction between an agent's ongoing session and the machine executing its tools explicit.

Claude Code's October 14 releases offer a useful view of the less glamorous work. Version 2.1.299 adds idle compaction; 2.1.300 expands telemetry and fixes problems involving resumed transcripts, background sessions, and container replacement. Session recovery and observability appear alongside customization because they determine whether prolonged agent work remains understandable. [Claude Code 2.1.299](https://github.com/anthropics/claude-code/releases/tag/v2.1.299), [Claude Code 2.1.300](https://github.com/anthropics/claude-code/releases/tag/v2.1.300)

Separately from Claude Code, Anthropic's [managed-agent architecture](https://www.anthropic.com/engineering/managed-agents) treats the session, harness, and sandbox as distinct components. Across coding products and application infrastructure, these designs suggest a convergence in the problems being addressed. They do not make the offerings interchangeable.

## Test recovery before choosing a harness

I would compare these designs by what survives a failure. Model support and tool count tell me less about that.

| Design emphasis | Useful when | Question to investigate |
| --- | --- | --- |
| Minimal, extensible loop | You need to understand and adapt agent behavior | How much lifecycle machinery will you build yourself? |
| Shared local service | People move between interfaces on the same machine | What survives a client disconnect or process restart? |
| Managed harness and configurable environment | You want an application to dispatch durable tasks | Which state and recovery responsibilities remain yours? |
| Integrated coding workspace | Review, execution, and human steering belong together | Can reviewers reconstruct what happened and why? |

These are overlapping design choices, not exclusive product categories. A system can support several of them.

Run the same failure exercise on a representative task in each candidate system. Start with a long test, then try these interruptions separately:

| Interruption | Evidence to inspect |
| --- | --- |
| Disconnect the client | Can another interface locate the task and its running command? |
| Restart the harness service | Does it recover recorded state and identify work that stopped? |
| Terminate the execution environment | Does it detect lost processes and explain what must be rerun? |
| Change a requirement or revoke a tool | Does subsequent work respect the change, and are earlier effects visible? |

Compare the recovered task with the actual files, running processes, and completed commands. A transcript saying a test was launched is weaker evidence than its recorded result.

I would choose the simplest harness that passes these recovery checks for the work I need.

*Product details checked on October 15, 2026. Release announcements describe their authors' implementations; the comparison above is my interpretation, not an independent product benchmark.*