Long-Running Agents: Durable State and Safe Recovery

Reviewed and updated October 8, 2026.

A long-running agent needs to know what has already happened when its process stops. Conversation history alone is not a reliable action ledger. Before adding more memory, decide which facts, approvals and external effects must survive a restart.

Durable execution records progress so an interrupted workflow can resume. Temporal's Event History documentation describes replay from a persisted event log. An agent still needs a boundary between replaying recorded decisions and making a new model or tool call.

Persist decisions and effects separately

Record the task identifier, current state, selected model and prompt version, tool arguments, observed results and relevant source versions. Treat a model response as a recorded result when replay must reproduce an earlier decision. Re-running generation during recovery can produce a different plan.

For side effects, keep the logical operation identifier, attempted action, approval record and provider receipt or verified state. Distinguish planned, approved, executing, succeeded, failed and unknown outcomes. “Unknown” is important when the external service might have completed an action but the response was lost.

An illustrative replacement workflow

Consider an agent that prepares and submits a replacement order after review. This is a proposed recovery design, not a report of a running system.

1. Save the proposed order and the specific version approved by a reviewer.
2. Create a stable operation key for that submission and persist it before calling the order API.
3. Call an endpoint that enforces duplicate handling for the key, then save the returned order identifier.
4. If the connection drops, query the order status using the operation key or another supported reconciliation mechanism.
5. Resume from verified state. If the outcome cannot be established safely, pause for an operator instead of submitting again blindly.

Temporal's Activity guidance explains that retries can repeat an external operation after a worker crashes and that idempotency keys must be enforced by the receiving service. A saved checkpoint does not provide that external guarantee.

Bound retries and waiting

Set per-operation timeouts, maximum retry behavior and a task deadline. Retry transient transport failures differently from permission denials, invalid arguments or a changed business state. Record why a task is waiting and when an operator should inspect it.

Approvals also expire or become invalid when their target changes. Recheck the current resource version, user permission and approval conditions before continuing. A restart is not permission to execute an obsolete proposal.

Choose the amount of durability the work needs

A short read-only query may only need ordinary request handling. A scheduled batch job can use a queue and a simple status record. Multi-step tasks with external changes or human waits may justify a durable workflow engine. The application still owns state schemas, migrations, retention, cancellation and operator tools.

Test interruption before a call, after external completion but before recording it, while waiting for approval and during deployment of a new workflow version. Verify that cancellation prevents further authorized actions and that an operator can inspect and resume the correct task.

See AI automation for work that spans systems and human review. Request a project review with the steps, side effects and recovery behavior the workflow requires.