index

A persistent agent separates the lifetime of a task from the lifetime of the process running it. The task can wait for a build, pause for input, survive a worker restart, and continue with the same objective and working state. Persistence comes from the software around the model: durable records, recoverable execution, and a defined path from an unfinished action to its next step.

Anthropic’s managed-agent architecture separates the session log, the harness that runs the model/tool loop, and the sandbox that executes work.¹ Meta’s Muse architecture makes another implementation of the same broad distinction, separating the agent runtime from durable application state, credentials, and permission enforcement.²

These boundaries allow a long-running task to outlive any individual model call or worker. They also make failures local: a lost process becomes something the system can recover from using the records it already holds.

The task state machine

A task moves through a small set of states:

queued -> running -> waiting_on_tool -> running -> done
                   -> needs_user
                   -> failed -> retry or stop

Each state identifies what can happen next. A running task belongs to a worker. A waiting task records the operation or event that can wake it. A task needing user input retains the question and the point at which work paused. Completion records the resulting artifact and the checks that establish it.

The task record contains the objective, owner, allowed operations, deadline, remaining budget, and current status. These fields remain authoritative even when the model’s context is compacted. A summary can help the next model call understand the task, while the durable record determines what it is permitted and expected to do.

An event log records transitions such as tool_requested, tool_completed, checkpoint_saved, and user_approved. Sequence numbers establish their order. The current state can be reconstructed from those events or stored alongside them for efficient lookup.

Session state and working files

Three forms of state have different roles:

The distinction makes recovery precise. A worker can reconstruct its context from the session history, identify the current artifact revision, and resume according to the task state. A container’s filesystem alone does not contain all three guarantees.

A small implementation can represent them with a few tables:

tasks(id, objective, status, owner, lease_until, version, deadline, budget)
events(task_id, sequence, kind, payload, created_at)
actions(id, task_id, request_key, status, external_id, result)
checkpoints(task_id, last_sequence, summary, artifact_revision)

Unique event sequences and action request keys give each record a stable identity. A transaction can update the task state and append its corresponding event together, avoiding a status change without an explanation in the log.

Checkpoints and context reconstruction

A checkpoint records the last processed event, a compact account of the work, and the artifact revision it describes. Recovery loads that checkpoint and the subsequent events. The worker does not need to replay every model call to discover the next unfinished operation.

Raw events remain useful after compaction. A summary may omit the details of a failed command or the reason an alternative was rejected. Keeping the original result allows the agent or a reviewer to retrieve it when it becomes relevant again. Anthropic’s managed-agent design explicitly separates durable session history from the model’s working context.¹

Long-term facts have a different lifecycle from task events. A project decision, user preference, or file pointer benefits from a source and update time. Retrieval selects the relevant facts for the current task, while the event log retains the complete execution record.

Model-level context management complements this storage. Meta describes context compaction and subagent coordination in Muse Spark 1.1. The model can use context more effectively, while the surrounding system preserves information across restarts and decides which state remains current.

Recovery across an external action

The most difficult restart boundary occurs after an external action succeeds but before the worker records the result. Consider an agent submitting a report. The remote service accepts it, then the worker crashes before saving the returned identifier. Locally, the action still appears unfinished.

Recording the request before sending it establishes intent, but the outcome is uncertain until it can be reconciled. Recovery follows one of three paths:

1. Retry with the same idempotency key under the external service’s documented contract.
2. Query the service using a stable identifier or request metadata.
3. Retain an uncertain state for resolution when neither operation is available.

Stripe’s idempotency API is a concrete example of the first mechanism.³ The key identifies the operation across attempts. Its retention period, parameter matching, and handling of errors determine which retries the guarantee covers.

A local events table and a remote API usually do not share a transaction. The action record bridges them by retaining the information needed to discover what happened. This is what prevents an ordinary process restart from becoming a duplicate message, report, or purchase.

Worker leases and fencing

A lease assigns a task to a worker for a limited period. The worker renews it while active; after expiry, another worker can take over. This provides recovery when a process disappears without releasing its task.

Expiry does not guarantee that the original process has stopped. A paused worker can resume after a new owner has started. A monotonically increasing ownership version resolves that case: each state-changing operation includes the version, and the store rejects an older owner’s writes.

This fencing check also matters at the tool boundary. Rejecting a stale database write after an external action has already happened cannot undo the action. The executor needs enough ownership information to reject stale work before performing it.

Artifact revisions provide a related check for collaborative work. A checkpoint can name a commit or content hash. On resume, a difference between that revision and the current workspace identifies changes made by another worker or a person. Recovery can then reconcile the new state rather than restoring an obsolete copy.

The restart sequence

With these records in place, resuming a task has a defined sequence:

claim task and obtain the current ownership version
load objective, permissions, checkpoint, and later events
reconcile pending actions with their external systems
compare artifact revision with the current workspace
construct context from the current task and relevant evidence
continue within the remaining budget

The sequence resolves uncertainty before asking the model for its next action. It also reduces unnecessary work: a completed deployment or tool call can be observed and recorded rather than launched again.

Waiting becomes inexpensive under this design. A task waiting for a build does not need a continuously running model loop. A completion event can wake a replaceable worker, which resumes from the durable state.

Permission as application state

An approval has a scope: the action, destination, and artifact it authorizes. Binding it to the action arguments or an artifact revision makes it usable during recovery. The worker can determine whether the operation now being attempted is the one that was approved.

Authorization is enforced by the executor. A tool may technically support deletion while the current task permits only reading. The task’s permission record restricts the operation independently of what the model proposes.

Meta’s published Muse design places permission enforcement and credential handling outside its agent runtime.² That separation lets the application check external actions without making the generated code responsible for protecting the credentials it could otherwise access.

Provenance serves a similar role for information. A document or web page is task data, even when its contents resemble instructions. Retaining that distinction in context and checking actions against the task record limits how external text can redefine the work.

Completion and evaluation

Completion can be expressed as a predicate over recorded evidence. A code task may require a saved diff and passing checks. A research task may require a report with source-backed claims. A deployment task may require a successful build and a verified live artifact.

Anthropic’s long-running development work treats evaluation as part of the agent system.⁴ Separating the evaluator from the worker’s self-assessment gives the completion record meaning beyond the model saying it has finished.

Recovery tests exercise the same design at its boundaries: before a tool call, during execution, after remote completion, and after checkpoint persistence. Duplicate wake events, expired leases, and revoked permissions test whether the task remains coherent under changes in ownership and authority.

Budgets bound the lifetime of unsuccessful work. Elapsed time, model spending, tool invocations, and repeated failures can each have a limit. A transient transport error can be retried; an invalid request or revoked permission needs a different transition.

The resulting system has continuity that can be inspected. Its last checkpoint, pending action, wake condition, and remaining budget describe what is happening even while no model call is running. That is the operational basis for an agent that can resume work reliably over hours or days.

References

Footnotes

1. Anthropic, Scaling Managed Agents: Decoupling the brain from the hands, April 8, 2026. Durable sessions, replaceable execution, and credential separation. ↩ ↩²

2. Tarek Sheasha, Meta, How We Built Safety Into Muse, September 8, 2026. Runtime isolation, durable state, credentials, and permission enforcement. ↩ ↩²

3. Stripe, Idempotent requests. A concrete external API retry contract. ↩

4. Anthropic, Harness design for long-running application development, March 24, 2026. Agent development and evaluation design. ↩

Durable records bridge the lifetime of a replaceable process.

1. Read checkpoint

   Recover the task state and the last recorded action identity.

2. Reconcile action

   Determine whether the external action completed before the failure.

3. Resume safely

   Reuse a confirmed result or retry under the service’s idempotency contract.

4. Commit progress

   Record the outcome before moving to the next task transition.

Recovery needs a way to distinguish an unfinished action from a finished action whose result was not recorded.

The same restart procedure must account for actions on both sides of an external boundary.

Case	Durable evidence	Recovery question
Before action submission	An intent or checkpoint only	Is submitting this action still authorized?
After external completion	The outside system may have acted	Can an operation ID or status query recover the result?
After outcome commit	A durable result is recorded	Can the next state proceed without repeating the effect?

A retry loop alone cannot provide exactly-once effects across independent systems.