Why It Matters
Agents are exactly the kind of long-lived, side-effecting workflow durable execution was built for: model calls, tool calls, sleeps, callbacks, retries, and user interactions must survive crashes without duplicating actions or losing context.
Problem
- Ordinary process memory loses workflow state on crash, deploy, timeout, or machine restart.
- Ad-hoc retry logic can duplicate side effects, skip recovery cases, or restart expensive work from the beginning.
- Logs are often good enough for debugging but not strong enough to reconstruct executable control flow.
- Agents intensify the problem because each task may contain many model calls, external tool effects, user interruptions, and long waits.
Key gap: Durable execution fills the gap between stateless request handling and reliable long-running programs by making step history part of the runtime contract.
Method
Keep orchestration deterministic, move every external or random operation into a durable boundary, persist each completed boundary's result, and recover by replaying the workflow until the first boundary without a recorded result.
- Start a workflow and persist its input.
- Run deterministic orchestration code until it reaches a durable operation.
- Execute the step/activity and persist its output before advancing the workflow.
- If the process fails, restart the workflow with its checkpointed input.
- During replay, return stored outputs for completed steps instead of running their code again.
- Resume normal execution at the first step with no checkpointed output.
- Handle external effects through idempotent steps, retries, and recorded operation identities.
- Version or patch workflow code so in-flight histories can still replay after deploys.
Claims
C1 · source-supported
Durable execution persists workflow progress so applications can recover from crashes, restarts, and failures without starting from the beginning.
Scope: DBOS and Temporal public docs.
- E-durable-definition: DBOS describes durable workflows built on Postgres that recover from failures where they left off, while Temporal describes crash-proof execution that resumes after crashes, network failures, or infrastructure outages.
C2 · source-supported
DBOS recovery re-executes workflows from checkpointed inputs and returns stored step outputs until it reaches the failed or uncompleted step.
Scope: DBOS Architecture docs.
- E-dbos-recovery: DBOS stores workflow inputs and step outputs, detects interrupted workflows, restarts them with checkpointed inputs, returns checkpointed outputs for completed steps, and resumes at the first step without a checkpoint.
C3 · source-supported
Temporal uses event sourcing to restore workflow state by replaying workflow code against recorded history while ignoring already-recorded side effects.
Scope: Temporal SDK documentation.
- E-temporal-replay: Temporal uses event sourcing to recover workflow objects; when workflow state is restored, code is re-executed from the beginning, and side effects such as activity invocations are ignored because they are recorded in event history.
C4 · source-supported
Durable execution requires deterministic orchestration code: random values, wall-clock time, external I/O, service calls, and database reads must be inside durable steps or activities.
Scope: DBOS Architecture, AWS Durable Execution SDK, and Temporal SDK docs.
- E-determinism: All three sources state that code replayed by the durable runtime must be deterministic, and that non-deterministic work such as time, random values, external I/O, service calls, database reads, or SDK calls belongs in durable operations, steps, or activities.
C5 · source-supported
Steps should be idempotent because failure during a step can cause the runtime to retry that step during recovery.
Scope: DBOS Architecture docs and AWS Durable Execution SDK framing.
- E-idempotency: DBOS says steps should be idempotent because if a workflow fails while executing a step, the step is retried during recovery, while completed checkpointed steps are not re-executed.
C6 · source-supported
AWS Step Functions Standard Workflow redrive preserves successful-step results and execution history while restarting from the failed, aborted, or timed-out step.
Scope: AWS Step Functions redrive docs.
- E-step-functions-redrive: AWS states that redrive continues failed Standard Workflow executions from the unsuccessful step, preserves successful-step results and execution history, and appends redrive events to the original event history.
C7 · source-supported
Durable execution creates upgrade and history-size constraints: changing step order can break replay, and large histories or large step payloads can become performance or retention problems.
Scope: DBOS Architecture and Temporal SDK docs.
- E-upgrades-history: DBOS warns that breaking changes to steps or step order can make old checkpoints hard to recover and offers patching/versioning; Temporal warns that large execution histories can hurt performance and that workflow code changes while workflows are open can break replay assumptions.
Agent Infrastructure Takeaways
- An agent trajectory should be a recoverable workflow history, not just a chat transcript.
- Every non-deterministic agent operation belongs behind a durable boundary: model call, tool call, memory read, memory write, clock, random choice, external API, user callback.
- Model calls are side effects for replay purposes. Record the prompt, model identity, parameters, returned text, tool-call JSON, usage, and errors before advancing.
- Idempotency keys are required anywhere the agent can charge money, send mail, create files, open tickets, mutate databases, or call external services.
- The workflow body should be boring deterministic orchestration. Agent creativity belongs in recorded steps, not in replay-sensitive branching.
- History size becomes a product constraint for long-running agents. Summarization is useful, but the raw committed events still need retention and provenance rules.
- Workflow-code upgrades are runtime migrations. Changing an agent graph while old runs are live requires versioning, patching, or explicit cutoff behavior.
Caveats
- This is background reading synthesized from product documentation, not a single peer-reviewed paper.
- Durable execution does not make side effects exactly-once by magic; external systems need idempotency or transactions.
- The deterministic replay model can conflict with highly dynamic agent graphs unless graph evolution is versioned.
- Replay recovers execution state, not semantic correctness. A recovered agent can still pursue the wrong goal.
- Different platforms expose different durability, retention, history, redrive, and operational tradeoffs.
- Durability can preserve bad actions too, so authorization and sandboxing still need independent enforcement.