An honest disclaimer first: this site belongs to people who build durable-execution infrastructure. The obvious incentive is to tell you every agent needs it, the honest answer is that most don't, and knowing which side of that line you are on is worth more than any feature list.
So here is the test actually used, rather than the one that sells the product.
The test: three conditions, all required
an agent needs durable execution only when all three of these are true.
1, the run is long
Not in wall-clock milliseconds, but in consequence, A run is long when a restart throws away meaningful work: a research-and-write pipeline that runs for forty minutes, a batch job that fans out across hundreds of calls, an agent that accumulates context over many steps. A three-second classification call is not long. If losing the run and starting over costs you nothing, this condition is false.
2. It touches the outside world
reads do not count. If a step calls an API that changes state, charges a card, sends an email, writes to a third-party system, posts a message, then the effect can land while its result is never recorded. that gap is where the interesting failures live, an agent that only thinks and returns text has no external effect to duplicate, and this condition is false.
3, re-running is expensive or unsafe
Expensive in tokens, time, or money. Unsafe because the external effect is not idempotent, calling it twice sends two emails or charges twice. If a re-run is cheap and harmless, you do not need durability; you need a retry, and maybe a log line.
When all three hold, a crash is not an inconvenience, it is a correctness bug: recovery either loses work or duplicates a side effect. And When any one is false, simpler tools are usually the right answer.
If one is false, this is what you actually need
These are not consolation prizes, A queue plus a status column, or a framework's own checkpointer, is often the smaller and more maintainable answer. Reaching for durable execution before the three conditions hold is how teams pay real complexity for imagined reliability.
The dangerous case is not knowing
The failures do not come from agents that obviously need durability or obviously do not. They come from teams that assumed the answer and found out otherwise.
Two symmetric mistakes:
- Treating it as just a job. A queue plus a "retry on failure" policy works until the run is long and effectful, then a crash mid-tool-call re-fires the effect, in the durability benchmark, naive retry re-fired four already-applied effects in a six-step run.
- Reaching for a workflow engine too early. Encoding a two-second, pure call as a durable workflow buys operational surface you never needed. The engine is excellent; it is just answering a question you did not ask.
The cost is asymmetric, over-engineering costs you time and complexity up front. under-engineering costs you a duplicate charge at 3 a.m., once, in production.
What durability actually buys, when all three hold
If you pass the test, the value is specific, not "reliability" in the abstract:
- Resume from the exact cursor, not the last snapshot, replaying the recorded result of completed steps instead of re-executing them.
- Recorded operation results, an idempotent tool-execution ledger so a retried operation returns its stored result rather than firing the external call again, with leases so a stale worker cannot double-write.
- Atomic event plus state. The event and its cursor-aligned state snapshot commit together, so a crash cannot wedge them apart.
- Branching with inherited state, fork at an exact boundary to change a later step without re-running the prefix.
- Replay-to-live delivery so an observer catches up from a cursor and continues live, without an application-built handoff.
Notice how little of that is about "not crashing." It is about what is true after the crash.
Two clarifications
- "Long" is about consequence, not the clock. A two-second call to charge a card is not a long run, but it is consequential and irreversible. Honestly The time is not the point; the recovery cost and the effect are.
- "External" includes writes you cannot undo. If the only way to reverse a step is a compensating action, treat it as an external effect even when it is in your own infrastructure.
The honest caveat, even when all three hold
A durable ledger does not make external effects exactly-once by itself, it closes the duplicate window only when the downstream honors the stable idempotency key. Without that, reconciliation remains your job. the ledger makes the ambiguous window queryable instead of invisible, which is a smaller claim, and a true one.
Run the test
Three questions. And Long run, external effects, costly or unsafe to re-run ? but three yeses means durability is worth the infrastructure. Fewer than three means ship the simple thing, and revisit when one of the answers changes, because it usually does, quietly, as the agent gets more useful.