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.
System state — reasoning and world model — is explicitly captured and externalised to allow recovery after aborts or failures.
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 serialisation contract that strips sensitive fields before persistence. Validate the contract with a test that diffs serialised 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 · Memoise 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