Durable Agent Execution Architecture

Durable execution lets a long-running agent survive crashes, pauses, approvals, retries, and deploys by recording progress in a log and replaying it deterministically.

Agents fail in boring ways: process dies, model times out, browser blocks, human approval takes hours, tool side effect partially succeeds. A durable runtime prevents the agent from starting over and re-spending the whole run.

The reusable concept behind this architecture is State Resumability. This page describes the event-log/replay architecture; State Resumability describes the product and workflow property agents must preserve.

Core Pattern

Durable execution is event-sourced:

All nondeterminism must enter through recorded steps: model calls, tool calls, timers, random IDs, current time, external signals. Orchestration logic must be deterministic on replay.

Components

Component Responsibility
Durable log append-only step events and results
Orchestrator deterministic driver and replay engine
Step executor model/tool/sandbox call runner
State store plan, memory, run metadata
Timer service sleeps that do not hold a process
Signal service human approvals, webhooks, external events
Idempotency layer prevents duplicate side effects
Snapshotter caps replay cost for long histories

Agent-Specific Requirements

  • Human-in-the-loop: approvals must pause without consuming compute.
  • Tool side effects: external writes need idempotency keys and recorded outcomes.
  • Compaction: long runs need summarized state without losing replay-critical events.
  • Observability: every step needs enough metadata to debug nondeterminism.
  • Cancellation: users need a real stop path; canceled runs should record final state.
  • Resumption: browser/session/sandbox state must be reconstructible or explicitly expired.

Failure Handling

Rollback is usually impossible because agents touch the real world. Use compensation:

  • If a message was sent incorrectly, send a correction.
  • If a resource was created twice, delete or merge the duplicate.
  • If a payment was charged twice, refund one charge.
  • If code was committed incorrectly, revert with a new commit.

This is the saga pattern applied to agent workflows.

Agent Resilience Patterns generalizes this failure-handling section into the wider control-plane map: circuit breakers, bulkheads, dead-letter queues, health checks, backpressure, canaries, and action traces. Durable execution provides the log/replay substrate; resilience patterns define the policy that decides whether to retry, stop, compensate, or escalate.

Where This Shows Up

Agent Machines need durable run state because the agent-machine is a persistent work unit. Vercel Eve makes each conversation a durable workflow. Codex automations and long project tasks need the same property: the run should be resumable, inspectable, and safe to retry.

Do not confuse agent fan-out with durable execution. Claude Code Dynamic Workflows moves orchestration into a generated JavaScript script and can resume background workflow state inside a Claude Code session, but that is still a harness-specific recovery mechanism. If a workflow must survive deploys, external webhooks, long human approvals, or side-effecting retries, it still needs an event log, idempotency, and compensation semantics. Source: X/@trq212 reply, 2026-06-02; Source: Claude Code docs, 2026-07-04


Timeline