long-running-agents

How to make Agents survive long tasks — work that can’t fit in one session, can’t fit in working memory, and can’t fit on the model’s attention without state externalization. Per tw93 in 2026-04-27-agent-principles-architecture-engineering: increased autonomy isn’t fewer human checkpoints; it’s keeping an Agent stably progressing across a longer time horizon. That requires three pieces of infrastructure first.

Three prerequisites

Before raising autonomy, get these in place:

1. Cross-session continuation — survive a session boundary without restarting from zero.
2. In-session progress constraint — externalize “where am I” so the Agent can’t drift or declare done early.
3. Background I/O — slow file/network/subprocess calls don’t block the main loop.

The order matters. Skipping straight to autonomy is the common cause of Agent incidents.

Initializer + Coding Agent — the canonical long-task pattern

The most stable arrangement for tasks too large for one session: split into two roles.

Best fit: code generation, app scaffolding, large refactors / migrations — work that can be decomposed into independently-verifiable sub-tasks but doesn’t fit one window.

Why files instead of context

Two principles applied together:

• Progress lives in files, not context. Filesystem state survives the session, the model crash, the laptop reboot. Conversation history doesn’t.
• JSON, not Markdown, for structured state. A feature-list.json with {id, desc, status, passes} per feature is more reliably edited by an LLM than a markdown checklist; rewrites are surgical, the structure is enforceable.

Task is “done” when every entry in feature-list.json has passes: true. Not when the model says it is.

Single-session task state

Cross-session is one problem; staying on track within a session is another. The instinct is to leave it in the model’s working memory; the source’s instinct is to externalize that too:

{
  "tasks": [
    {"id": "1", "desc": "Read existing config", "status": "completed"},
    {"id": "2", "desc": "Modify DB schema", "status": "in_progress"},
    {"id": "3", "desc": "Update API endpoints", "status": "pending"}
  ]
}

Constraints:

• Exactly one in_progress at a time.
• Status updates before moving on, not after.
• Optional safety net: when N turns elapse without a status change, inject a <reminder> of current progress.

Background I/O

Once autonomy goes up, the bottleneck moves from model latency to external I/O — filesystem, network, long-running shell commands. The pragmatic pattern from the source:

• Spawn slow subprocesses on a background thread.
• Push results into a notification queue.
• Main loop checks the queue at the start of each turn — before calling the model — and decides: continue / wait / replan.

This is meaningfully simpler than refactoring the whole loop into an async runtime, and survives common failure modes more cleanly.

Crash recovery is not optional

The source’s blunt rule: any task that runs longer than ~30 minutes needs persistent state and resume logic. The TaskState shape from the openclaw walkthrough:

interface TaskState {
  taskId: string;
  description: string;
  status: "pending" | "in-progress" | "completed" | "failed";
  progress: {
    completedSteps: string[];
    currentStep: string;
    remainingSteps: string[];
  };
  context: { key: string; value: string }[];
  lastUpdated: number;
}

Save after every step. On startup, load the file and continue from currentStep; if the file is missing, start fresh. No recovery infrastructure → starting over is the only option, and a long task that crashes 80% in is a 4-hour loss.

Releasing autonomy in order

This is where the autonomy ladder (harness) matters in practice:

1. Harness present — acceptance, boundary, signal, fallback.
2. Rollback present — provider switch, workspace isolation, allowlist, audit log.
3. Autonomy raised — explicit confirmation on sensitive ops, source-sink path-cutting (prompt-injection), independent LLM verification on the critical path.

Most Agent incidents skip step 1 or 2.

Anti-patterns

• Single-Agent attempt at a task that obviously won’t fit in one window.
• “Done” inferred from the model saying so, with no feature-list.json-style acceptance check.
• Progress kept in the conversation only — first crash is a full restart.
• Slow I/O blocking the main loop — turn cadence collapses.
• Markdown-as-state for things that need structured edits.
• Raising autonomy before rollback paths exist.

OpenAI Codex: 6+ hour runs, worktree-per-change

2026-04-27-harness-engineering-codex-agent-first (OpenAI codex team) is the wiki’s strongest data point on long-running-agent feasibility. Three operational details:

• Single-task runs over six hours are routine. Many run overnight. The text: “我们经常看到单次 Codex 运行在单个任务上持续工作超过六个小时（通常是在人类睡眠时间）” — “we often see single Codex runs working on a single task for over six hours, often during the hours humans sleep.”
• Per-worktree application instance, plus ephemeral observability. Each change runs in its own git worktree with its own application instance, logs, metrics, and traces. When the task completes, everything (worktree + observability stack) is deleted. The agent can therefore experiment freely without polluting a shared environment — workspace isolation taken further than the multi-agent-orchestration worktree pattern, by attaching dedicated runtime infrastructure to each isolated workspace.
• Logs / metrics queryable by the agent itself (LogQL / PromQL). With this in place, prompts like “ensure service startup completes in under 800ms” or “no span across these four key user journeys exceeds two seconds” become mechanically actionable acceptance criteria — see agent-legibility.

Compared to the openclaw long-task pattern (Initializer + Coding Agent + feature-list.json), the Codex setup pushes more of the externalization into the runtime environment (worktree, observability) rather than into JSON-state files. Different shape, same instinct: state lives outside the conversation.

The benchmarks that justify long-running-agent infrastructure don’t exist yet (Yao 2025)

Shunyu Yao’s The Second Half argues this is exactly the kind of work the field’s evaluation conventions hide. Standard benchmarks run i.i.d. — 500 tasks, average independent results — and that frame cannot see whether the agent improved at the n+1th task because of what it learned on the first n. Yao’s concrete contrast:

A Google SWE solves google3 issues increasingly better as she gets more familiar with the repo, but a SWE agent solves many issues in the same repo without gaining such familiarity. We obviously need long-term memory methods, but academia does not have the proper benchmarks to justify the need, or even the proper courage to question i.i.d. assumption that has been the foundation of machine learning.

Implication for the patterns above: the openclaw / codex long-running-agent infrastructure (Initializer + Coding Agent, worktree-per-change, persistent feature-list.json, four-memory-types) is engineering ahead of where the eval frame can score it. The runtime stack to do sequential, memory-accumulating work exists; the benchmarks that would reward it over a stateless agent of equivalent capability do not. Yao’s general prescription — invent eval setups for real-world utility, then solve them with the recipe — applies here narrowly: the benchmarks needed are sequential-task benchmarks where memory across tasks is the load-bearing variable. Cross-link agent-evaluation‘s utility problem section.