An AI agent in production is a distributed system wearing a trench coat. It chains ten model calls, hits three external APIs, provisions a sandbox, writes to a database, and maybe moves money — and any of those steps can be the one that's in flight when the pod gets rescheduled. The naive answer is "retry the whole thing." For an agent that just did something with a side effect, retrying the whole thing is how you double-charge a customer or spin up two VMs where you meant one.
Durable execution is the primitive that fixes this, and it is exactly one idea: a function that, after a crash, resumes from the last step it finished — because every completed step was journaled, so on recovery those steps are replayed from the journal instead of re-executed. Ten LLM calls deep, the eleventh crashes, you restart, and calls one through ten are not re-run; the engine hands back their recorded results and continues. That's it. Everything below is a different bet on where that journal lives and what it costs you to operate.
The decision that actually matters#
Skip the throughput benchmarks for a moment. The choice that will shape your system is shape, not speed:
- A library inside your app, backed by your own database. DBOS is the clearest example: workflows are functions, state is rows in your Postgres, recovery is standard SQL. Nothing extra to run, and the durability lives where your data already does. The tradeoff is that the durable engine shares your application's fate and your database's load.
- A service you call into. Temporal defined this category and Restate refined it: a separate engine owns the journal and the retries, isolated from your app. You run a cluster (or pay someone to), and in exchange a bad deploy of your app can't corrupt in-flight workflow state. This is the choice for multi-day workflows and serious scale.
- A functions / queue-replacement platform. Inngest and Hatchet come at it from the jobs-and-events side: durable step functions that also give you queues, scheduling, and fan-out. If your agent work is event-driven — fires on a webhook, a cron, a queue message — this shape fits the trigger model you already have.
- An agent-native runtime. Golem is the wildcard: durable execution built on WebAssembly, marketed specifically at agents that must never lose state or duplicate work. Younger and more opinionated, but aimed squarely at this use case.
The non-obvious part: most agent teams reach for one of these too early. If all you need is "resume the LLM loop after a restart," your agent framework's own checkpointer already does that — LangGraph checkpoints every superstep, for one. Durable-execution engines earn their keep when the agent orchestrates side effects across systems the framework doesn't own: the payment, the provisioned infra, the write to the system of record, the saga that must be compensated if step 4 fails. That's the line. On the LLM-loop side of it, use your framework. On the side-effect-orchestration side, use one of these.
The engines#
How to choose without a bake-off#
Start from your failure model, not a feature grid. Ask three questions:
- Does a retry of any step cause harm? If the agent's steps are all idempotent reads, you may not need durable execution at all — a checkpointed framework loop is enough. If a step charges, provisions, or writes non-idempotently, you need exactly-once, and you need one of these.
- What operational surface can you carry? If the honest answer is "as little as possible," DBOS embedding into your Postgres beats standing up a Temporal cluster. If you already run serious infra and want the durable engine isolated from your app's blast radius, Temporal or Restate is the adult choice.
- What triggers the work? Long-lived, code-shaped workflows point at Temporal/Restate/DBOS. Event- and queue-shaped work points at Inngest/Hatchet. Agent-first-and-willing-to-bet-on-WASM points at Golem.
The trap is treating this as a performance question. All six will out-run your LLM calls by orders of magnitude; the model is your bottleneck, not the journal. What differs is what breaks when you break — how much infra you run, how isolated the state is, and how cleanly a half-finished agent run recovers at 3 a.m. without a human. Pick for the failure you're most afraid of, not the throughput you'll never hit.
