State Resumability
State resumability is the property that an agent or workflow can pause, crash, hand off, or wait for a human, then continue from the correct state without pretending nothing happened.
Core idea
Agents do long, stateful work. They read sources, edit files, call tools, wait for approvals, run tests, and produce artifacts. If the run cannot resume, every interruption becomes a correctness risk.
Resumability requires:
- durable run identity;
- checkpointed progress;
- saved inputs and decisions;
- replay or continuation semantics;
- idempotent side effects;
- visible status;
- cleanup for abandoned runs.
Temporal's docs define the production-grade expectation: workflows should recover after crashes or infrastructure failures and resume from where they left off. LangChain's HITL docs make the same point at the agent-policy level: execution can pause for a human decision because graph state is saved. Source: Temporal docs, https://docs.temporal.io/, 2026-06-19; LangChain HITL docs, https://docs.langchain.com/oss/python/langchain/human-in-the-loop, 2026-06-19
The failure mode
Non-resumable agents create two bad options:
- Restart from scratch and risk duplicate side effects.
- Continue from memory and risk invented state.
Both are poisonous. The run either wastes work or lies about what happened.
State types
| State | Example | Resumability need |
|---|---|---|
| Conversation state | user intent, constraints, answers | continue with the same requirements |
| Plan state | completed/pending steps | avoid repeating or skipping steps |
| World state | files changed, branches, database writes | prevent duplicate/destructive side effects |
| Tool state | browser page, shell session, machine ID | reconnect or reconstruct safely |
| Evidence state | sources, traces, test logs | preserve proof |
| Human decision state | approvals, edits, rejections | make gates auditable and resumable |
| Cost/budget state | spend so far, remaining cap | stop runaway work |
Resumability levels
| Level | Description | Good enough for |
|---|---|---|
| Transcript-only | human can read what happened | short chat work, weak for agents |
| Plan checkpoint | explicit completed/pending steps | coding sessions, wiki edits |
| Artifact checkpoint | files, logs, outputs committed or stored | docs/code work with verification |
| Runtime checkpoint | shell/browser/machine/session state persists | long-running agents and computer use |
| Workflow replay | deterministic event history can recover execution | production automations and paid workflows |
Kevin's wiki work often uses plan/artifact checkpoints: logs, changed files, doctors, qmd, and commits. Agent Machines pushes toward runtime checkpoints: persistent workers, snapshots, volumes, and hibernation.
Product requirements
A resumable agent product should show:
- run ID and title;
- current phase;
- last real event;
- pending approval or blocker;
- changed artifacts;
- cost/time used;
- resume/cancel/retry buttons;
- proof bundle;
- stale-run warning.
This is a core part of Agent Product Surface. A spinner is not state. A transcript is not always enough. The user needs to know whether the system is safe to continue.
Design implications
Resumability changes architecture:
- store state outside the model context;
- use idempotency keys for side effects;
- write intermediate artifacts deliberately;
- make approval decisions durable;
- separate "retry step" from "restart run";
- expose cancellation that cleans up machines/processes;
- record enough proof for handoff.
Kevin-stack defaults
- For wiki edits, commit finished work promptly and keep
wiki/log.mdcurrent. - For long coding sessions, preserve plan status and verification outputs.
- For parallel agents, use separate worktrees so state does not collide.
- For automations, write
state.jsonand output artifacts. - For Agent Machines, prefer persistent homes, snapshots, and hibernation over disposable sandboxes when the task has meaningful state.
- For HITL, never ask a question unless the run can resume after the answer.
Failure modes
- resuming after source files changed without re-reading them;
- duplicate external actions after retry;
- approval answer detached from the proposed tool call;
- stale state hidden behind a "continue" button;
- cost cap reset on resume;
- screenshots/logs not preserved;
- cleanup skipped when a run is canceled.
Concept Position
| Field | Value |
|---|---|
| Concept family | Agent harness and runtime primitives |
| Concept owned | State resumability is the property that an agent or workflow can pause, crash, hand off, or wait for a human, then continue from the correc... |
| Category map | Concept System Map |
Timeline
- 2026-07-01 | Concepts category refresh added this page to the Agent harness and runtime primitives family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: State resumability is the property that an agent or workflow can pause, crash, hand off, or wait for a human, then continue from the correc... Source: User request, 2026-07-01
- 2026-06-19 | Created as the missing concept behind durable execution, Agent Machines persistence, human-in-the-loop pauses, automation orchestration, and proof-carrying work. Source: User request; Temporal docs; LangChain HITL docs; local Agent Machines pages, 2026-06-19