Agent recovery checkpoints
Price durable recovery against repeated work
Checkpoints add storage and coordination, but restarting a long task can repeat model calls, document processing and operator effort. Compare the whole recovery path.
In this article
Identify the expensive work worth preserving
A short read-only lookup may be cheap to repeat. A workflow that parses many documents, obtains approval and submits an external mutation has more state worth retaining. Checkpoint decisions should reflect those differences.
Measure the cost and duration of each stage, including external API limits and human waiting time. Approval cannot be treated like a model call that is simply rerun at a known token price. Re-requesting it consumes attention and can change the decision context.
Preserve completed consequential effects regardless of their computational cost. A cheap mutation still needs a durable identity if repeating it could create the wrong business result.
Avoid saving every intermediate token
Useful checkpoints record business state, operation identifiers and the information needed to continue. Saving every internal model event indefinitely can create large storage, privacy and debugging costs without improving recovery.
Choose bounded summaries or references where they preserve the necessary meaning. Keep the exact approved payload and operation result when those are required to establish authority and outcome. Different record types can have different retention policies.
Measure checkpoint size and write frequency under realistic tasks. A design that looks inexpensive for one run can produce substantial I/O when many workers checkpoint simultaneously.
Include coordination overhead
Durable recovery needs ownership, retries, version handling and reconciliation. These add engineering and operational complexity. A managed workflow service can provide parts of that machinery, but its task and retry semantics still need to match the application's effects.
Estimate recovery frequency and the amount of repeated work avoided. Use observed failures where available and plausible interruption scenarios where not. Label assumptions clearly rather than presenting a speculative saving as a measured result.
Do not optimise only for average cost. A rare outage affecting thousands of runs can produce a large catch-up burst and operator backlog.
Choose checkpoints at meaningful boundaries
A practical starting point is after costly deterministic preparation, at approval transitions and around each consequential operation. Add finer checkpoints when evidence shows repeated work is expensive or recovery time is unacceptable.
Test the resulting design with interrupted runs and compare total work, recovery delay and manual intervention. The best choice is the simplest durable state that preserves correct effects and avoids costly repetition, with enough capacity to recover a realistic backlog.
Primary sources
AWS: workflow error handlingAWS: workflow redriveReferences checked 11 September 2026.