Durable AI agents are agents that survive failure. If the server crashes, a deploy restarts the process or a model API times out, a durable agent does not start over and does not lose its work. It picks up from the last saved step. That matters as soon as an agent runs for more than a few minutes: research that takes an hour, a coding task that spans a day, or a watcher that runs for weeks. This guide explains how durable execution works for agents, why long-running agents need it, and how the main options compare in November 2026.
The short version
Why long-running agents need durable execution
A normal chat request lasts seconds. If it fails, you press retry and lose little. An agent is different. It calls a model, runs a tool, reads the result, calls the model again, and repeats this dozens or hundreds of times. The longer that loop runs, the more likely it is that something breaks in the middle.
Common causes of a broken run:
- The process is restarted by a deploy or an autoscaler.
- The machine or container dies.
- A model provider returns an error or a rate limit.
- A tool, such as a payment API, times out without saying whether it worked.
- The laptop running the agent goes to sleep.
Without durability, each of these means starting again, paying for the same tokens twice, and sometimes running the same action twice. With durability, the agent continues from where it stopped. Think of it as the save button in a long document: you still lose the last few seconds, but not the whole afternoon.
The four building blocks of durable AI agents
1. State checkpoints
After each step, the agent writes what happened to storage: the model answer, the tool result, the current plan. The transcript itself is often the checkpoint. Temporal's Pi integration says it plainly: "the transcript is the conversation state."
2. Retries
A step that fails is tried again, usually with a wait in between (backoff). Good systems retry only the failed step, not the whole run.
3. Resume after a crash
When a new process starts, it reads the stored state and continues the unfinished work. It does not need the memory of the process that died.
4. Idempotent and replay-safe tools
This is the part most teams miss. If the agent crashed while a tool was running, did the tool finish? Reading a file twice is harmless. Sending an invoice twice is not. A tool is idempotent when running it twice has the same effect as running it once, for example because it sends an idempotency key with the request. Durable agent frameworks ask you to declare which tools are safe to replay and treat the rest with care.
Durable does not mean exactly once
The main options for durable agents
There are two families. General durable execution engines make any code durable, including agent loops. Agent-native harnesses build durability into the agent itself. Here are the options we see most often, with links to their own docs.
Temporal
Temporal splits work into Workflows, which hold the logic, and Activities, which talk to the outside world. It records every event in a history. When a worker fails, another worker replays the Workflow code against that history and continues. The price is that Workflow code must be deterministic, so model calls and tools go into Activities. In October 2026 Temporal showed the Pi coding agent running on Temporal with failover across machines.
Cloudflare Durable Objects and the Agents SDK
In the Cloudflare Agents SDK, each agent is a Durable Object with its own SQL storage, scheduled work and recoverable execution. An object that is evicted or crashes is restarted by an alarm and continues. We covered the wider idea in our post on Cloudflare Project Think.
Pi Durable
Pi Durable is an experimental TypeScript harness from Earendil, released with Pi 1.0 on 1 October 2026. Every model request and tool call is a task that stores a checkpoint before it moves on. Tools declare whether they are replay-safe. It stores state in SQLite, JSONL or a Cloudflare Durable Object, and Rivet runs it inside Rivet Actors. Temporal took a different route: its pi-temporal project runs the Pi coding agent on Temporal instead of Pi Durable's own storage. Our Pi Durable guide goes into detail.
Restate, Inngest, DBOS and LangGraph
- Restate describes itself as a lightweight runtime that turns agents, workflows and services into durable processes. Completed steps are stored, and code resumes where it left off.
- Inngest runs functions as steps and stores each step result. On failure only that step retries, and the run can resume on another machine.
- DBOS is a library. You add annotations to your code and it gains durable execution backed by Postgres, without a separate orchestration server.
- LangGraph saves graph state through checkpointers. In-memory checkpointers are lost on restart, so production setups use the Postgres saver.
Comparison table
| Option | Type | Where state lives | Tool safety | Good fit |
|---|---|---|---|---|
| Temporal | General durable execution engine | Event history in a Temporal cluster | Activities with retry and timeout policies; you add idempotency | Teams that already run Temporal or need cross-machine failover |
| Cloudflare Agents SDK | Agent runtime on Durable Objects | SQLite inside each Durable Object | Depends on the harness you run inside it | Many small agents at the edge, one per user or task |
| Pi Durable | Agent-native harness (experimental) | SQLite, JSONL, IndexedDB, Durable Objects or custom | Per-tool replay declaration | TypeScript teams that want durability inside the agent loop |
| Restate | Durable runtime | Restate server journal | Journaled steps | Low-latency services and stateful agents |
| Inngest | Hosted step functions | Inngest platform | Per-step retries, stored results | Event-driven agent steps without running infrastructure |
| DBOS | Library | Your Postgres | Checkpointed steps | Teams that trust Postgres and want no extra service |
| LangGraph | Agent framework with checkpointers | Configured checkpointer, e.g. Postgres | Up to your nodes | Graph-shaped agents already built on LangChain |
A caution about comparisons: many of the head-to-head articles online are written by one of the vendors. The table above sticks to what each project says in its own documentation. Pricing and limits change often, so check them directly.
How to choose
- 1Start from your existing stack. If you already run Temporal or Postgres, the cheapest path is often to put the agent loop on what you have.
- 2Decide how much failure you must survive. A process crash is easier than losing the whole host. Temporal's Pi post notes that Pi Durable's local SQLite store survives process crashes but may lose the newest commits on power or host failure.
- 3List your tools and mark them. For each tool, write down: safe to repeat, repeat with an idempotency key, or never repeat. This list matters more than the framework.
- 4Test a crash on purpose. Kill the process in the middle of a run and check what happens. Temporal's demo does exactly this by killing the active worker every 15 to 40 seconds.
- 5Watch costs. A resumed model call may be sent again and cost tokens again. Set budgets per run.
Durability pairs well with clear goals and retry loops. Our posts on resilient agent loops and Codex Goals cover the other half of long-running work. Durability is also what makes proactive AI agents practical, since a watcher that runs for weeks will meet every kind of failure.
How Halmob helps
Halmob builds durable agents: long-running agents that keep their state, retry after failures and resume where they stopped, for work that spans hours or days. We also build software factory pipelines that turn a spec into reviewed, tested pull requests, which only work when every step survives a crash. If you are deciding between Pi Durable, OpenClaw, Hermes Agent or another platform, our agent platform consultancy helps you choose, set up and roll it out. Contact us to talk through your use case.