"Durable" Agents Aren't Durable. Read the Fine Print.

The word doing all the work in the demo

This month the agent conversation stopped being about clever prompts and started being about time. LangGraph is shipping durable execution. Anthropic's MCP ecosystem is maturing into stacks that keep agents alive across hundreds of tool calls. OpenAI's agent runtime now expects sessions measured in hours, not seconds. The pitch to every technical decision-maker pushing a pilot into production this quarter is the same: your agent can run for a long time, and if the process dies, it comes back.

That pitch hangs on one adjective. Durable. And most of the people signing off on architecture right now are reading that word to mean something it does not mean.

We want to draw one line and then hammer it for the rest of this post, because it is the line that separates "my agent kept running" from "my agent kept running correctly."

Execution durability is not state durability

When a framework says durable execution, it means the workflow is resumable. The orchestrator persists a log of steps: called tool A, got result B, moved to node C. If the worker crashes at step 40, a new worker replays the log and continues from step 40 instead of step 1. This is real engineering and it is genuinely useful. It is also, almost exactly, what Temporal has done for microservice workflows for years. The agent frameworks borrowed the pattern, and they borrowed the word.

Here is what that word does not cover. Execution durability guarantees the sequence of steps survives a crash. It says nothing about whether the accumulated state those steps produced is correct, versioned, or recoverable to a known-good point in time.

Think about what a long-horizon agent actually carries: a vector store of retrieved context, a running summary of what it has decided, scratchpad memory, a set of files it has edited, a database it has been writing to. That is the agent's knowledge. The checkpoint the framework saves is a pointer into a workflow graph plus a serialized blob of that state at the moment of the last node. Resume from it and you get the state exactly as it was, including whatever was wrong with it.

So picture the failure mode nobody demos. Your agent is 30 tool calls into a 4-hour run. Around call 18, a bad retrieval poisoned its working summary with a wrong fact. By call 30 it has made six decisions on top of that fact. The process crashes. Durable execution kicks in, replays the log, and faithfully resumes from call 30, wrong fact and all. The workflow is durable. The state is corrupt. The agent keeps running, confidently, off a cliff.

That is durability in name only. You did not lose the run. You lost the ability to say what the agent knew and when it knew it.

The three things a checkpoint has to be

A checkpoint that only lets you resume is a resume token. A checkpoint you can actually trust as recovery has to be three things, and this is the checklist to walk into your next vendor call holding:

• Point-in-time addressable. Can you recover the agent's state as of call 17, before the corruption, and not just "the latest checkpoint"? Resume-from-latest is worthless when latest is the problem. If the answer is "we keep the most recent N steps," that is a crash buffer, not a history.
• Versioned and diffable. Can you see how the state changed between call 17 and call 18 and point to what drifted? Recovery without visibility just moves you to a different unknown-good state. This is the same reason your AI rollback strategy is more broken than you think: rolling back to an opaque snapshot is a coin flip, not a fix.
• Independent of the runtime. If the checkpoint lives only inside the framework's own execution store, then a corrupted store, a bad migration, or a framework upgrade takes your recovery path down with it. That is a single point of failure you are not monitoring, dressed up as a feature.

Run those three questions against the durable-execution feature you are being sold. Most current implementations pass the first badly, ignore the second, and fail the third outright. They persist state to resume it, not to audit or restore it.

Why this is the wrong quarter to get it wrong

The reason to care now rather than later is that architecture decisions are being frozen right now. Buyers are picking their agent runtime, wiring their memory layer to it, and committing. Once your state persistence is entangled with your orchestrator's internal checkpoint format, retrofitting real recovery means re-plumbing the thing you built your product on. The evaluation window is open this month and closes the moment the pilot ships.

And the longer the horizon, the worse the exposure. A 10-second agent that corrupts its state fails fast and visibly. A 3-day autonomous agent corrupts its state on day one and compounds the error across 900 tool calls before anyone notices the output is wrong. Length of run, the exact thing these frameworks optimize for, is what turns a small state bug into an expensive one. We made the general case for treating memory as a first-class asset in why AI agents need memory backups now; durable execution does not close that gap, it hides it behind a reassuring word.

What to actually do

Separate your two durability questions and answer them with two different tools. Let the framework own execution durability; that is what it is good at, and resumable workflows are worth having. Own state durability yourself, deliberately, as a layer that does not live inside the orchestrator.

Concretely: snapshot the agent's knowledge, its memory, context, edited files, and vector state, on a cadence you control, to a store the framework cannot corrupt. Version those snapshots so you can diff them. Keep enough history that point-in-time recovery is real and not just last-known. Then, when an agent drifts, you can answer the only question that matters in the incident channel: what did it know, when did it know it, and can we put it back.

That is exactly the layer SaveState builds: versioned, point-in-time snapshots of agent state that sit outside your runtime, so "durable" means recoverable and not just resumable. If you are evaluating a durable-execution framework this quarter, take the three-question checklist above into the call. The vendor who is confident about execution will usually go quiet on state. That silence is the whole story.