Durable execution and the runtime spectrum

A framework runs the loop; something has to keep the loop alive across the minutes, hours, or days a real agent run spans, surviving process crashes, deploys, and the long waits on models, tools, and humans. Chapter 45 reached for Step Functions; this chapter widens the lens to the whole durable-execution category (Temporal, Restate, DBOS, Inngest) that has become central to serious agent systems, and places it on the spectrum between a free loop and a managed state machine. The theme: agents are unusually long-lived and failure-prone, so durability of execution is a first-class concern, and there is now a mature category built for it.

Why agents need durable execution

Recall the failure modes from Chapter 25: a worker dies mid-run, a deploy interrupts a fleet, a tool takes an hour, a human approval arrives tomorrow. A plain in-process loop loses everything on any of those; the event ledger lets you reconstruct state, but you still hand-write the checkpoint-and-resume logic. Durable execution engines make that automatic: they persist every step of a workflow so that if the process dies, execution resumes from the last completed step on another worker, with no state lost and no bespoke checkpoint code. For an agent, whose runs are long and whose steps (model calls, tool calls) are exactly the things you want to not re-run on a crash, this is a natural fit, and "agents on durable execution" is one of the defining architectural patterns of 2026.

The mechanism most of them share is worth understanding, because it constrains how you write agent code. Durable engines achieve crash-resumption by deterministic replay: on recovery, they replay the workflow's history, feeding each previously-completed step its recorded result instead of re-executing it, until they reach the point of failure and continue live. This is exactly the replay discipline the book built by hand, now as infrastructure, and it imposes the same rule: the workflow body must be deterministic, with all nondeterminism (model calls, tool calls, time, randomness) pushed into recorded steps ("activities"). Write an agent loop that calls datetime.now() in the workflow body and durable replay breaks, the same record-at-the-edges rule, enforced by a different master.

The engines

• Temporal is the category's heavyweight: a durable-workflow engine where your workflow is code (Go, Java, Python, TypeScript) and the engine persists its every step, with built-in retries, timers, and signals. "Temporal for AI agents" is a well-trodden pattern, the agent loop as a durable workflow, tool and model calls as activities, so a crash mid-investigation resumes without re-spending the tokens already burned. It is the pick when you want durability with full code-level control and are willing to run (or buy) the Temporal service.
• Restate is a lighter durable-execution runtime with a similar journaling model, aimed at lower operational weight than Temporal.
• DBOS takes a library approach: durable execution built on Postgres, so your workflows are durable without a separate orchestration service, just your database, which appeals when you already run Postgres and want durability without new infrastructure.
• Inngest is event-driven durable functions with a step model, popular for AI workflows specifically, where each step.run is a durable checkpoint and the developer experience is tuned for the serverless, event-triggered shape Part 4 described.

Where it sits on the spectrum

The workflow-versus-loop decision now has a middle, and the full spectrum is worth drawing because it is the real menu for "where does the agent's control flow live":

The rows are not exclusive; the mature pattern composes them. A common 2026 shape: an AgentCore or Fargate worker runs a LangGraph loop inside a Temporal workflow, so the framework gives idiomatic control flow, the durable engine gives crash-resumption of the expensive steps, and the Hive platform around all of it gives budgets, verification, and scheduling. Each layer solves a different problem, and conflating them, expecting a framework to give you durable execution, or a durable engine to give you a budget ledger, is how designs end up with a gap exactly where the 3 a.m. incident lands.

Ray, and the distributed-compute angle

One more runtime worth naming for completeness: Ray is the distributed-compute framework used to scale agent fleets and the training/RL loops behind them, Ray Serve for serving, Ray's actor model for stateful parallel workers. It is not a durable-execution engine or an agent framework; it is the substrate a very large fleet's compute might run on, one rung below the fan-out bundles. Most teams reach the AWS-native bundles (distributed map, SQS-plus- Fargate) before they need Ray, but at the scale where you are also training the models, Ray is the layer that unifies the two.

Don't be confused: durable execution vs event sourcing. Both give you crash-recovery and both appear in this book, but they are different mechanisms. Event sourcing records what happened (an append-only log you fold into state) and you write the resume logic; it is data. Durable execution records where the code is (a workflow journal the engine replays) and the engine resumes automatically; it is a runtime. They compose, an event log for audit and replay-debugging, a durable engine for automatic crash-resumption, but you do not need both for every system: a small fleet may be fine with the ledger alone, while a mission-critical long-running agent wants the engine on top. Choose by how expensive a lost run is and how much resume logic you want to own.

👉 Next: the protocol landscape, where MCP and A2A are joined by the newer standards (ACP, AG-UI) and a map of which protocol solves which boundary, agent-to-tool, agent-to-agent, agent-to-frontend.