Writing ·
Agent workflow recovery plan: how to resume without replaying work in 2026
An agent workflow recovery plan reconciles checkpoints, side effects, and approval state before a resumed run is allowed to act again.
By Youssef Hemimy · agent reliability · recovery · checkpoints
An agent workflow recovery plan should resume only after it reconciles the checkpoint, the side effects, and the next safe action. If the harness cannot prove what already landed, the correct move is to pause and repair the state rather than replay the whole workflow.
- 4
- recovery choices
- 3
- state buckets to reconcile
- 1
- checkpoint ledger
- 0
- blind reruns
Checkpoint
last known workflow state
Reconcile
which side effects landed
Decision
resume, skip, pause, or repair
Audit
new attempt and recovery note
Recovery rule
A recovery path is allowed to be conservative. Pausing is better than replaying work when the harness cannot prove what already happened.
Recover the state before recovering the task
A recovery plan is not a rerun policy. It is a state policy. Start by reading the last checkpoint and deciding which side effects already landed. That is the same logic behind idempotent agent tool calls and it depends on the same boundaries as production agent tool contracts.
The recovery decision table
| Observed state | Recovery choice |
|---|---|
| Checkpoint is intact and effects are reconciled | Resume from the next safe step. |
| Checkpoint is intact but an effect already landed | Skip the completed step and continue from the remaining work. |
| Checkpoint is incomplete or contradictory | Pause and require repair before the run acts again. |
| Next action is destructive and the evidence is thin | Route to human review before the workflow continues. |
What makes the plan durable
Durable recovery needs a stable workflow identifier, an explicit checkpoint record, the current approval state, and a recovery note that explains the next action. The point is not to hide failure. The point is to make recovery reviewable enough that the next operator can trust the path forward.
- Store the checkpoint and the recovery note together.
- Record which step was already completed.
- Re-check approval state before any risky resumed action.
- Distinguish a repaired resume from a fresh run.
- Preserve the audit trail even when the workflow pauses.
Where to use it
This plan belongs anywhere the workflow can produce a real side effect and then stop halfway through. It pairs naturally with AgentOps when you need the harness to recover cleanly, and with kill switches when recovery should stop rather than continue.
FAQ
What is the first step in a recovery plan?
Read the checkpoint and reconcile what already happened before you let the run choose a next step.
Why not just rerun the task from the top?
Because rerunning can repeat side effects. If a message was already sent or a record was already written, replay creates duplicates instead of recovery.
What should the recovery decision branch on?
Branch on the checkpoint, the observed side effects, and whether the next action is still safe without a human review.
How does this relate to retries and idempotency?
Retries make progress possible, and idempotency makes retries safe. Recovery uses both, but it also needs the checkpoint history so it can stop when the evidence is incomplete.
Building something that has to hold up?
We do this work for teams — agent reliability hardening, custom MCP servers, and full-stack AI systems built to survive production.