Durable Execution for Long-Running Agents
Keep agents running for hours or days without losing work: checkpoints, resumable workflows, durable execution engines, and idempotent steps.
The checkpointing worker from the last lesson survives a crash mid-run. Long-running agents need more than that. Most of a long run's life is spent waiting, not computing: for a manager to approve a refund, for a CI pipeline to finish, for a customer to reply, for the "check back in three days" follow-up. Meanwhile you deploy new code twice, a worker stalls and a second one picks up the same run, and the downstream API times out halfway through creating an invoice.
This lesson turns your checkpoints into full durable execution: a step journal, runs that suspend while waiting, durable timers, leases so a run never executes twice, steps that are safe to repeat, and runs that outlive your deploys. Then you'll see how engines like Temporal, Inngest, Restate, and DBOS package the same ideas, so you can decide whether to build or adopt.
What "durable" has to cover
The previous lesson's checkpoints covered one failure: a worker dying mid-run. A run that lasts hours or days meets a longer list:
| Situation | What goes wrong without a plan | The mechanism that fixes it |
|---|---|---|
| Worker crashes mid-step | Work repeats or is lost | Checkpoints and a step journal |
| Waiting for a human for two days | A worker sits blocked, or the wait is lost on restart | Suspend and resume |
| "Follow up on Friday" | An in-memory timer dies with the process | Durable timers |
| Two workers grab the same run | Every step runs twice | Leases with fencing |
| A step half-completes in an external system | Duplicate or orphaned records | Idempotent step design |
| You deploy new prompts mid-run | The run resumes with code that doesn't match its history | Version pinning |
Each row is a small, specific mechanism. Together they're what people mean by durable execution.