02 Nov 2025 AI Engineering5 min read

Durable Execution for Agents

Agents that run for hours or days cannot leave their state in process memory. We define durable execution, compare event-history replay with checkpoint snapshots, and survey the late-2025 engine landscape from Temporal to LangGraph 1.0 and Microsoft Agent Framework. We also state clearly what durability does not solve: side effects, decision quality, and context growth.

Agents That Die With the Process

An agent is a loop: a model plans, calls tools, observes results, and plans again. In most frameworks, this loop lives in process memory. When the process dies — because of a deployment, an out-of-memory kill, or a node failure — every completed step is lost. The agent restarts from zero, repeats every LLM call, and pays for every token a second time. Yet the side effects of tools that already ran remain in the outside world.

For a 30-second task, such a restart is an annoyance. For a research agent that runs six hours, or an approval workflow that spans five days, it is disqualifying. Long-running agents are distributed systems and inherit their central requirement: execution state must survive the process that produced it. Since 2025, that requirement has not only a name but mature tooling.

A task arrives — the agent plans its next step. 1/4

What Durable Execution Actually Means

Durable execution is a programming model. The runtime records the result of every side-effecting step — an LLM call, a tool invocation, an HTTP request — in a persistent log. The orchestration code around those steps must be deterministic. After a crash, the runtime re-executes that code; recorded steps return their stored results instead of running again, and the program arrives at the exact point of failure with identical local state. Temporal calls this replay. The effect is crash-proof execution.

In practical terms, recovery consumes no additional tokens. A workflow that failed after 40 of 50 tool calls resumes at call 41. It needs neither a hand-written state machine in Redis nor manual checkpoint code or restart logic scattered through the agent loop. Durability belongs to the runtime rather than the application, which is what makes multi-day execution economically viable.

Two Roads to Resumability

Engines in the Temporal tradition persist an event history. Temporal stores one history per workflow in Cassandra, MySQL, or PostgreSQL and replays deterministic workflow code against it; non-deterministic work — every model and tool call — runs inside activities whose results are recorded exactly once. Restate 1.2 (February 2025) compresses the same idea into a single binary with its own distributed log. DBOS Transact takes the library route: annotate functions in your own process and store execution state in the Postgres database you already operate.

LangGraph snapshots state instead. After each graph node, a checkpointer writes the channel values to an in-memory, SQLite, or Postgres backend; resumption loads the latest checkpoint and continues at the next node. There is no replay — and no record of what happened inside a node. Both models deliver the same guarantee. They differ in granularity, storage growth, and how they tolerate code changes while executions are in flight.

The Engine Landscape in Late 2025

The tooling consolidated in 2025. LangGraph 1.0 shipped on 22 October 2025 — the first stable major release of a durable agent framework, after production use at Uber, LinkedIn, and Klarna. Temporal's integration with the OpenAI Agents SDK entered public preview on 30 July 2025. Microsoft Agent Framework, the merger of Semantic Kernel and AutoGen, reached public preview on 1 October 2025 with checkpointing and pause/resume built into its graph workflows.

The range of operating models matters: an external cluster, a single binary, an in-process library, or a framework layer. Durability is no longer tied to one infrastructure pattern. Teams can choose the weight class that fits their environment instead of adapting the environment to the engine. A library is often enough for small teams; regulated settings benefit more from the auditable event log of an external cluster.

Engine	Model	State store	Status on 2 Nov 2025
Temporal	Event-history replay via external cluster	Cassandra, MySQL, PostgreSQL	GA; OpenAI Agents SDK integration in public preview
Restate	Event log in a single binary	Embedded RocksDB plus object-store snapshots	1.2 since 18 Feb 2025
DBOS Transact	In-process library with decorators	Any Postgres-compatible database	TypeScript 2.0 since 29 Jan 2025
LangGraph	Node-level state checkpointing	In-memory, SQLite, Postgres checkpointers	1.0 stable since 22 Oct 2025
Microsoft Agent Framework	Graph workflows with checkpoints	Pluggable checkpoint storage	Public preview since 1 Oct 2025

Waiting for Days Is a Feature

Durability changes what an agent may wait for. A durable workflow can block on a human approval for a week: the code reads as a synchronous await, but no process runs and no memory is held during the wait. Timers, retries with backoff over hours, and human-in-the-loop interrupts become ordinary control flow instead of external cron jobs and message queues.

This is the mechanism behind multi-day agent processes: draft, wait for review, revise, execute. LangGraph 1.0 exposes it as interrupts on top of checkpoints; Temporal as durable timers and signals. In both systems the wait costs storage, not compute — and it survives every deploy that happens in between. On the bill, that is the difference between a running container and a row in a database.

What Durable Execution Does Not Give You

Replay restores results; it does not undo effects. Steps execute at-least-once: if a process crashes after a tool ran but before its result was recorded, the step runs again. Tools with side effects — sending mail, charging cards, creating tickets — still need idempotency keys. The engine guarantees the orchestration, not the semantics of what it orchestrates.

Durability does not improve decision quality either. A resumed agent continues its existing plan; if that plan is wrong, the error is merely persisted reliably. Context windows also do not grow because state sits on disk — long histories still require summarization before reaching the model. Determinism adds maintenance cost as well: deploying changed workflow code while old executions remain in flight requires explicit versioning or patching, and teams often underestimate that work.

Finally, checkpoint and history stores are a trust boundary. Serialized agent state contains prompts, tool outputs, and occasionally credentials in transit. Whoever can write to that store decides what a resumed agent believes it has already done. Encrypt the store and restrict write access accordingly.

Outlook From November 2025

We expect durability to become a default property of agent runtimes rather than an add-on. The signals of 2025 point in one direction: a checkpointing framework reached 1.0, a durable-execution vendor ships first-party agent SDK integrations, and Microsoft put checkpoints into its unified framework at launch. Within a year, writing an agent loop without persistence should look as odd as writing a web service without logs.

Two questions remain open. First, convergence: event-history engines and checkpoint frameworks will likely meet in the middle — histories with snapshot compaction, checkpoints with step-level records. Second, cost: durable LLM transcripts are verbose, so retention policies must become part of agent design rather than an afterthought. At Blue IT Systems, we therefore treat durability as the first architectural decision for any agent that outlives a single request. Everything else layers on top.