02 Nov 2025 AI Engineering 5 min read

Durable Execution for Agents

Agents that run for hours or days cannot keep their state in process memory. We define durable execution, compare event-history replay with checkpoint snapshots, survey the late-2025 engine landscape from Temporal to LangGraph 1.0 and Microsoft Agent Framework, and state plainly 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 — a deploy, an out-of-memory kill, a node failure — every completed step is gone. The agent restarts from zero, repeats every LLM call, and pays for every token a second time. Any partial tool effects remain in the outside world regardless.

For a 30-second task this 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 they inherit the central requirement of distributed systems: execution state must survive the process that produced it. That requirement has a name and, since 2025, 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.

The practical consequence: recovery costs no tokens. A workflow that failed after 40 of 50 tool calls resumes at call 41. No hand-written state machine in Redis, no manual checkpoint code, no restart logic scattered through the agent loop. The durability lives in the runtime, not in the application.

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 spread matters. An external cluster, a single binary, an in-process library, a framework layer: durability is no longer tied to one operational model. Teams can pick the weight class that matches their infrastructure instead of adapting their infrastructure to the engine. Small teams are often served by a library; regulated environments benefit 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 also does not improve decisions. A resumed agent continues the plan it had; a wrong plan durably persisted is still wrong. Context windows do not grow because state sits on disk — long histories still need summarization before they reach the model. And determinism has a maintenance cost: deploying changed workflow code while old executions are in flight requires explicit versioning or patching, an effort most teams underestimate.

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, and retention policies will become part of agent design rather than an afterthought. At Blue IT Systems we now treat durability as the first architectural decision for any agent that outlives a single request. Everything else layers on top.