Your Agent Crashed at Hour 6. Here's Why It Didn't Restart From Zero.

Your agent has been working for 6 hours, called dozens of tools, and is one step from finishing a report a client is waiting on. Then a deploy restarts the process mid-task. Durable execution is the pattern that lets an agent resume from its last completed step instead of starting the entire run over.

What Does Durable Execution Actually Mean for an AI Agent?#

Durable execution is the pattern that checkpoints an AI agent's progress after every completed step, so a crash, a redeploy, or a rate limit only costs the current step, not the whole run. On restart, the runtime replays its recorded history, skips finished work, and resumes exactly where the process stopped.

This is the same idea distributed systems call event sourcing: instead of storing only the current state, the system stores the sequence of events that produced it, and can always reconstruct where things stand by replaying that sequence. Temporal, one of the older durable execution platforms, models this as a Workflow (the orchestration code) plus Activities (the actual LLM calls, tool calls, and API requests), with every step written to a recorded Event History; on restart, the workflow code replays against that history, and each Activity call short-circuits to its recorded result instead of actually re-executing. Source

This matters more for agent workloads than for a typical microservice retry, because a single step, one LLM call chained through a few tool calls, can cost real money and take real seconds to minutes, not milliseconds. Losing that step to a restart is not just wasted compute, it is a wasted API bill.

The runtime never re-runs a finished step; it reads the recorded result and moves on.

If you have not covered what an agent actually is first, our what is an AI agent primer is the foundation this post builds on. Everything below assumes an agent that calls tools and an LLM across more than one step, not a single request and response.

Why Doesn't a Simple Retry Loop Already Solve This?#

A plain retry loop that just re-runs a failed function from the top will call the same LLM prompts and repeat the same side effects it already finished before the crash. Durable execution instead persists the result of each completed step, so a retry replays the run's history and skips whatever already finished instead of doing it again.

Inngest makes the cost concrete: in its own February 2026 write-up, it frames the problem as doubling or tripling inference spend on every retry, and says its step-level caching means you pay for each LLM call exactly once, since a completed step returns its stored result instead of calling the model again. Source Under the hood this is usually at-least-once delivery paired with idempotent step caching, which behaves like exactly-once from the outside even though the underlying retry mechanism can technically fire more than once. If you already build in n8n, you have met a lighter version of both ends of this: Retry On Fail is the plain-retry-loop end, and a Wait node that survives a restart is a primitive durable step, not the full checkpoint-and-replay model.

The difference is not whether it retries, it is whether it remembers what already finished.

The gap between the two only grows with run length. A retry that repeats 2 finished LLM calls after a crash is annoying. One that repeats 40 finished calls, several tool writes, and a payment confirmation is a production incident.

What Are the 4 Building Blocks Every Durable Agent Needs?#

Every durable agent runtime rests on 4 primitives: checkpointing state after each step, idempotent tool calls so a replay never double-charges or double-sends, durable waits that survive a restart instead of a process just sleeping, and a way to pause for a human approval that can resolve minutes or days later without burning compute.

Checkpointing is the baseline: every completed step, an LLM call's output, a tool's return value, a routing decision, gets written to durable storage before the run continues. Idempotency covers what checkpointing alone cannot: Restate's own documentation notes that LLM responses specifically must be recorded for replay because LLMs are non-deterministic, and the same discipline applies to any tool call with a side effect, a charge, an email, a database write. Source None of the 4 stand alone: a runtime that checkpoints but skips idempotency will happily replay a duplicate charge, and one that adds durable waits but no checkpointing still re-runs the reasoning that led up to the wait.

Miss one of these and a runtime only solves part of the crash-recovery problem.

Durable waits are the primitive that is easy to miss: a plain sleep call dies with the process, but a durable wait is a promise the runtime persists, so it survives a restart and resumes when the event or the timer fires. Restate's own framing of this is specific: an agent waiting on a human approval suspends without charging for the waiting time, whether that approval lands in minutes or days. Source That is also why human-in-the-loop belongs on this list as a first-class primitive rather than a footnote; Google's Agent Executor, announced May 21, 2026, lists resuming after exactly this kind of interruption as a core capability, not an add-on. Source

How Do Temporal, Inngest, DBOS, and Restate Actually Differ?#

Temporal replays an entire workflow function deterministically, so anything non-deterministic, like an LLM call, has to sit inside a separate Activity. Inngest instead memoizes each step's result independently and, by its own account, drops that determinism requirement. DBOS and Restate take a third path: a Postgres-backed library and a journal-based server, both wrapping your existing code rather than replacing it.

Microsoft's own documentation, updated May 2026, splits agentic workflow patterns into 2 categories worth borrowing regardless of which runtime you pick: deterministic workflows, where your code defines the control flow and the LLM is just one step in it, and agent-directed workflows, where the LLM itself decides which tool to call next. Source AWS took the integration route: as of March 2026, Step Functions added Bedrock AgentCore as a native integration alongside over 1,100 new API actions across 28 services, so a state machine can invoke an agent runtime with built-in retries. Source Google's entrant is the newest and least proven: Agent Executor, open-sourced the same month, adds checkpoint-based branching for testing alternate agent paths, but it is still in preview. None of the runtimes above are mutually exclusive with your existing stack; most are built to wrap whatever agent framework or LLM SDK you already call, not to replace it.

Does Every AI Agent Actually Need This?#

Most agents do not need a dedicated durable execution runtime. A chatbot that answers in a single request and response, or a script that finishes in under a minute, gets little from checkpointing beyond what a basic try/except retry already covers. The signals that actually justify it are long wall-clock runs, expensive steps, and waits that outlive a single process.

Three cumulative signals decide how much durability machinery an agent actually needs.

Long-horizon agents are exactly the shape of workload where this stops being optional. If a run is already built around planning and re-planning across dozens of sub-goals, the crash-and-restart problem compounds with every extra hour on the clock; our guide to breaking a long-horizon task into sub-goals covers the planning side of that same problem. The 3 questions in the diagram above are cumulative, not exclusive: an agent can trip 1, 2, or 3 of them, and each one adds a specific piece of machinery instead of a single blanket verdict.

What Does Durable Execution Actually Cost You?#

Durable execution is not free. You take on a new mental model where some code must be deterministic or step-scoped, a journal or event history to debug instead of a normal stack trace, version drift risk when you change code mid-flight on a long-running instance, and either a managed platform's bill or the operational weight of running one yourself.

None of this is free; it trades a rebuild-from-scratch risk for a new operational surface.

Version drift is the sharpest edge of the 4. A workflow that has been running for days can outlive the code that started it; if you deploy a change to the logic mid-flight, a naive replay can diverge from the recorded history because the code path no longer matches what was recorded. Every mature durable execution platform ships some form of versioning to manage this, and it is worth reading before your first production deploy, not after a replay failure teaches you the hard way. None of this is a reason to avoid durable execution once the signals in the checklist above are real; it is a reason to treat the runtime as infrastructure you commit to, not a library you casually swap out later.

What Should You Actually Do Before You Reach for One?#

Start by writing down your agent's failure mode: what breaks today, how often, and what it costs when it does. If nothing has crashed in production yet, a plain retry with idempotent tool calls covers you. If a run already died 6 hours in and re-paid for every finished step, that cost is your business case for a runtime.

Pick the smallest tool that matches the actual failure: DBOS if you already run Postgres and want zero new infrastructure, Inngest if you want durable steps without adopting a new execution model, Restate if you are wrapping an existing agent framework, and Temporal, Azure Durable Task, or Step Functions with Bedrock AgentCore if you are already inside one of those ecosystems. If you want the debugging half of this story rather than the survival half, AI agent observability covers how to trace what a live run actually did, including the runs your new checkpointing just saved. Either way, write the decision down: what you checked, what you chose, and why, so the next person debugging a stuck run at 2 a.m. is not reverse-engineering your reasoning from scratch.