Agent Resumption Patterns: Restarting Without Starting Over

Saving state is the easy half. The interesting problems appear when you try to start again: the transcript you restore was written for a world that may have changed, and the reason the run stopped tells you a great deal about whether resuming is even the right move.

Three things stop an agent, and they want three different responses. Treating them identically is how a resumed run repeats an action, or picks up a task a human already finished by hand.

Why it stopped determines how to resume

A crash — the process died, the machine went away, the connection dropped. Nothing about the task changed, so this is the clean case: restore and continue, checking only that the last in-flight operation completed or did not.

A limit — the turn ceiling, the token budget, or a timeout. The agent was still working and was cut off deliberately. Resuming needs a decision about the budget, because restoring and continuing on the same policy just hits the same wall again a few turns later.

A pause — a human interrupted, or an approval gate was reached. Here the world has very likely changed, because that is usually the point of pausing. The resumed agent needs to be told what the human did, not just handed back the transcript it had. Human-in-the-loop design covers structuring those handoffs.

Verify the world before continuing

A restored transcript asserts facts about the workspace that were true when it was written. Before the agent acts on any of them, check the ones that are cheap to check.

In a repository, compare the current revision against the one recorded in the checkpoint. If it moved, someone else has been working, and the agent's plan may reference code that no longer exists. Also confirm the files it believed it had modified are in the state it believed.

When the check fails, the safe response is not to abandon the run — it is to re-establish. Drop the stale tool results, keep the summary of intent, and let the agent re-read the parts of the workspace it needs. That costs a few turns and prevents a patch applied to a file that has since been rewritten.

Replay versus restore

There are two ways to get an agent back to where it was, and they have very different risk profiles.

Restore loads the saved conversation and continues from it. No tool calls are re-executed, so nothing is repeated. This is what you want almost always, and it depends on having checkpointed the conversation rather than only the workspace.

Replay re-executes the recorded tool calls to rebuild state. It is tempting because it needs less stored data, and it is dangerous because every non-idempotent call runs a second time. Reserve it for sessions whose tools are all pure reads, and treat any write tool as a hard stop. Agent checkpointing covers storing enough that you never need to replay.

Rehydrate the context, do not just reload it

The naive resume feeds the model the exact transcript it had. That works, and it inherits every problem the original context had — including the accumulated tool output that was probably contributing to the failure.

A better resume reconstructs. System prompt verbatim, because constraints must never be lost. Then a compact statement of the task, what has been established so far, what has already been tried and failed, and what the immediate next step was believed to be. Then the last couple of turns in full.

Put the "already tried and failed" list in explicitly and near the end of the context. Without it, a resumed agent frequently retraces its own dead ends, which is the single most common wasted-cost pattern in resumed runs. Summarisation in agent loops covers producing that summary well, and the lost-in-the-middle problem covers why position matters.

The first action after a resume

Treat the first tool call after resumption as the riskiest one in the session. It is the call most likely to duplicate an action that already completed, because the interruption may have landed between the call being issued and its result being recorded.

Two defences. Make the first action a read that confirms current state rather than a write — cheap, safe, and it grounds the model in reality. And ensure the write tools are duplicate-aware, so a repeated call recognises its own operation identifier and returns the original result instead of acting again.

If neither is available for a particular tool, that tool should require explicit human confirmation on the first post-resume invocation. It is a small amount of friction in an already unusual code path.

Budgets carry across, or they mean nothing

A run that stopped because it exhausted its budget and then resumes with a fresh budget has no budget. This sounds obvious and is one of the most common implementation mistakes, because the budget usually lives in the process that died.

Store cumulative spend in the checkpoint and have resumption load it. Then a resume is a deliberate decision to extend, made by whoever has the authority to spend the extra, rather than an accident of how the counter was scoped. Agent token budgets covers setting the ceilings.

Cap the number of resumes as well. A task that has been resumed four times is not a task that needs a fifth attempt; it is a task that needs a person. Automatic resumption without a cap converts a stuck agent into an open-ended bill. Why agent costs are unpredictable covers where that variance comes from.

When not to resume

Discard and restart when the workspace has diverged substantially, when the transcript contains a long stretch of failed attempts that would only be re-read, or when the task turned out to be misunderstood at the start. A clean run with a corrected prompt often costs less than salvaging a confused one.

The test is simple: would a competent person reading the checkpoint note pick this up, or start again? Resumption is a cost optimisation, and like any optimisation it is worth applying only when it actually saves something. Long-running agents covers the surrounding operational design.