Durable Agents Resume, Not Restart

Here's a claim worth arguing with: for a long-running agent, restarting from scratch is worse than crashing. The crash costs you one run. The restart costs you that, plus every completed step paid for twice, plus something subtler. A model asked the same opening question again may plan differently the second time. Steps the first attempt already finished in the outside world (a booking made, a record created, a message sent) now sit underneath a second attempt that doesn't know about them and may contradict them.

Short runs hide this. If a task takes forty seconds and three tool calls, start over, who cares. But the work agents are being handed now runs for hours, waits on people for days, and touches systems that remember what it did. At that length, "just retry it" stops being a recovery strategy. It's a second, divergent execution.

The fix is older than agents. Save state as you go, and make recovery mean resume.

What actually gets saved

A durable run writes down enough, after each step, for a fresh process to continue as if it were the original. That record has three parts: the working state (what the run knows so far), the outputs of steps already completed, and which step comes next. Save those, and the process itself stops mattering. Kill it, deploy over it, move it to another machine. The run survives because the run was never only in the process.

Frameworks implement this in two main shapes. In the checkpoint shape, the runtime snapshots state at step boundaries. LangGraph checkpointers, for instance, save a snapshot at each super-step, one round of the graph, and also store each finished node's writes as it completes, so if a sibling node fails in the same round, the successful ones don't run again on resume. In the replay shape, the runtime keeps an append-only history of decisions and results. On recovery it replays that history, handing back the recorded outcomes instead of asking the model to decide again. Temporal's Event History works this way: the orchestration replays, completed steps are read from the record, and the agent picks up at the first step that never finished.

The two shapes differ in mechanics and agree on the contract: completed work is recorded once, and recovery never re-decides it.

Durability is a dial, not a switch

Saving state after every step isn't free. Each snapshot is a write, and writes take time, so runtimes let you choose how hard to lean. LangGraph exposes three durability modes: one that persists only when the run exits, one that saves asynchronously while the next step executes, and one that saves synchronously before the next step starts. The first is fastest and loses mid-run progress in a crash. The last is the safest and pays a write on every step. The middle one is likely where most teams land, accepting a small window where a crash can take the most recent step with it.

Choose per run, not per platform. A research run that only reads can tolerate losing a step. A run that creates records in other systems should be saving synchronously before it acts again, because the step it might lose is the one that already changed something.

The same mechanism covers a pause that isn't a failure at all. A run waiting on a person's approval is just a run whose next step hasn't started. If its state is saved, it can wait three days without holding a process open, and the approval wakes it exactly where it stopped. Teams often build crash recovery and human approval as separate features. Underneath, they're one feature: state that outlives the process.

One run, resumed

Take a vendor onboarding run: collect the supplier's documents, extract the tax ID and bank details, screen the company against a sanctions list, then pause for a compliance officer to approve before the vendor record is created.

Midway through the pause, the worker is replaced by a deploy. Nothing about the run notices. The approval arrives the next morning, a fresh worker loads the last checkpoint, and the run continues at the approval step with the extracted details and the screening result already in state. Nobody re-collects the documents. The sanctions screen doesn't run twice.

Restart-from-scratch would have handled the same deploy by beginning again — and its first step is asking the supplier for documents it already sent. That's the visible cost. The invisible one is a screening question answered slightly differently the second time, leaving two partial versions of one onboarding in flight.

The state the checkpoint can't hold

Machine state is only half of what a resumed run needs. A checkpoint restores what the run had computed. It doesn't restore what the run had understood: why it chose this path, what it already tried and ruled out, what "done" looks like for the whole task.

Anthropic's work on long-running agent harnesses makes the same point from the session side. Each new session starts with a fresh context window, and compaction alone wasn't enough to carry a complex build across sessions: agents would leave features half-finished, or look at partial progress and declare the job done. Their fix was written artifacts. An initializer lays down a feature list and a progress file, and sessions end by updating both, so the next session reads its bearings from disk instead of guessing.

Treat those as two layers of one design. Checkpoints carry the run's state. A short, structured handoff (what's done, what's next, what's been ruled out) carries its intent. A resumed run with state but no intent will repeat explorations you already paid for. A run with intent but no state will re-execute steps it shouldn't. Long tasks need both.

Where durability stops helping

A checkpoint is a snapshot of your own state. The outside world doesn't roll back with it. If a step sent an email or created a record and the run resumes believing that step never completed, it will do it again; durability has to be paired with steps that are safe to repeat, or with a record of effects checked before re-acting. Resuming exactly is not the same as acting exactly once.

Checkpoints also age. State saved by last month's version of your workflow may not load cleanly into this month's, and a history kept forever becomes storage you're paying to maintain. Retention is a decision: how far back is a run still worth resuming, and when do you archive it and start clean on purpose?

And some runs shouldn't resume at all. If the failure was a bad plan rather than a dead process, faithfully continuing the plan just reaches the wrong destination with better reliability. Recovery needs an escape hatch, a way for a person to inspect the saved state, correct it, or kill the run, not only a resume button.

None of this argues against durability. It argues for treating it as a design surface rather than a framework checkbox: what gets saved, how often, for how long, and what a resumed run is allowed to redo.

Work with us

If your agents lose hours of work to a deploy, a crash, or a three-day wait for approval, and restarting them risks doing the early steps twice, that's a durability gap, and closing it is deployment work we do. Tell us where your long runs break through Trida AI's intake.