When to reach for it
- State loss in long-running or resource-intensive workflows is critical and must be prevented.
Recorder.
Snapshot the state so the run can be resumed, not restarted.
The system state (including reasoning and world model) is explicitly captured and externalized so a run can be recovered, resumed, or replayed across steps, sessions, and processes — not only after an abort.
In practiceWhen a batch-extraction agent crashes mid-run, the recorder's persisted step log lets a fresh instance skip the API calls already completed and continue from the point of failure.
When it backfires
- Tasks are short, stateless, or easily repeatable from scratch.
The tradeoff
Increased resilience and resumability are gained against higher storage costs and persistence overhead.
What it actually does.
Every step is recorded for later replay.
Two ways this pattern will hurt you.
Snapshots persist sensitive intermediate state
Every checkpoint includes whatever lived in working state — including PII or secrets the agent saw transiently while reasoning.
Fix · Define a serialization contract that strips sensitive fields before persistence. Validate the contract with a test that diffs serialized state against an allowlist.
Replay diverges because the world moved on
The step log records the inputs but re-executes tools on resume. An external result that has since changed makes the resumed run diverge from the one that was interrupted.
Fix · Memoize side-effecting tool outputs in the record and replay them, rather than re-calling; mark genuinely non-replayable steps so resume restarts from the last safe boundary.
Where Recorder is native.
Microsoft Agent Frameworkdurable run stateNative
Keep going