Durable Execution, Idempotency, or Both

Mostafa Dhouib·September 8, 2026·6 min read

Durable Execution, Idempotency, or Both

The short answer. Durable execution guarantees the process survives: if the worker dies mid-workflow, execution resumes from the last recorded step rather than from the beginning. Idempotency guarantees the effect happens once: if the same operation is attempted twice, the world changes once. Neither implies the other. A durable workflow that replays a step whose acknowledgement was lost will perform that side effect twice, correctly, according to its own record.

The two halves of one failure

Something goes wrong mid-operation. Two questions follow and they have different answers.

Where do we resume? Answered by durable execution. The engine records each completed step, so recovery starts from the last one rather than from the top.

Did the side effect happen? Not answered by durable execution, because the engine only knows what it recorded, and the gap between an effect occurring and being recorded is precisely where the failure lives.

The dangerous case is exact: the step ran, the external system performed the action, the acknowledgement was lost, and the engine never recorded completion. On resume it replays the step. Everything behaved correctly and the charge went through twice.

The decision table

Which do you need

Long-running processes with no irreversible effects. A research task, a batch analysis, a report. Durable execution alone is fine, because replaying a step costs compute rather than correctness.

Short operations with irreversible effects. A payment, a message to a customer, a deletion. Idempotency alone is usually enough; if the whole operation is seconds long, resuming mid-way matters less than not doing it twice.

Long-running processes with irreversible effects. Both, and this is where most real systems sit. An agent that runs for twenty minutes and sends emails is exactly this, and it is the case where buying one and assuming it covers the other bites.

The mistake worth naming

"We use a durable workflow engine, so we get exactly-once."

Durable execution is at-least-once with recorded progress. The engine ensures every step eventually runs to completion; it cannot ensure a step ran only once, because it cannot observe an effect it did not record. Exactly-once delivery across a network boundary is not available, and what stands in for it is at-least-once delivery plus idempotent effects.

That is not a limitation of any particular engine. It is a property of the problem, and the vendors are usually clear about it in their documentation while the teams adopting them are not.

What each layer needs from you

For durable execution: the process expressed as steps whose boundaries are meaningful, deterministic replay for anything the engine re-executes, and a distinction between waiting and being stuck. That last one is worth stating: a workflow blocked forever on a condition that will never be true is durable and useless. Convergence loops need a progress measure and a give-up state like any other loop.

For idempotency: a key derived from the intent rather than the attempt, generated by the party that formed the intent, a deduplication window longer than your longest retry path including operator reruns, and deduplication at the last boundary that can still cause the effect twice.

The third option people forget

Before reaching for either, ask whether the operation can be expressed as a desired state rather than an action.

"The record should have these values" applied twice reads the current state, sees a match, and does nothing. No key, no engine, no window. Infrastructure adopted this because at fleet scale retries are continuous rather than exceptional.

It needs three things to hold: the intent describes a state rather than an action, the system reads actual state before acting rather than trusting its own record, and convergence is genuinely a no-op when the world already matches. Where all three hold, retry is free and both other mechanisms become less load-bearing.

It does not cover everything. Sending an email, charging a card, and launching a physical process have no state formulation, and those are exactly the operations that need an idempotency key.

For agent systems specifically

Agents make this urgent because they retry enthusiastically, their record of what they did is the least trustworthy record in the system, and they frequently cannot tell whether a previous attempt landed.

Prefer tools whose contract expresses a state. "Ensure this record has these values" over "update this record." Decided in the tool's contract, not the prompt.

Have tools read before they write, so a repeated call is observably a no-op.

Generate idempotency keys from the task, not the attempt, for the actions that cannot be expressed as state.

Reconcile afterwards. Prevention fails silently, so compare what the agent reports it did against what the target system holds. An agent's report and the destination's row count are two independently maintained records of one reality, and comparing them is the only way to see what prevention missed.

FAQ

Does durable execution give exactly-once semantics? No. It is at-least-once with recorded progress. The engine guarantees every step eventually completes; it cannot guarantee a step ran only once, because it cannot observe an effect that occurred but was never recorded. Exactly-once across a network boundary is not available, and at-least-once plus idempotent effects stands in for it.

Do I need both durable execution and idempotency? If your process is long-running and has irreversible effects, yes. Long processes with no irreversible effects need only durability, since replaying a step costs compute rather than correctness. Short operations with irreversible effects usually need only idempotency.

How does a durable workflow cause a double charge? The step runs, the external system performs the action, the acknowledgement is lost, and the engine never records completion. On resume it correctly replays the step from its own record, and the effect occurs twice with every component behaving as designed.

Is there an alternative to both? Sometimes. If the operation can be expressed as a desired state rather than an action, applying it twice is a no-op provided the system reads actual state before acting. That removes the need for keys and windows, but it does not cover genuinely non-idempotent actions like sending an email or charging a card.

What does this mean for AI agents? Agents retry frequently and their own record of what they did is the least reliable record available. Prefer tools whose contract expresses a state, have them read before writing, derive idempotency keys from the task rather than the attempt, and reconcile the agent's report against the target system afterwards.