PLAN → DRY-RUN → ACTION → EVIDENCE. Use dry-run when the consequences of a wrong action are expensive, destructive, public, or difficult to reverse.
What is a dry run for an AI agent?
In a dry run, the agent follows the same planning and decision path it would use in a live run, but it does not apply the final external mutation. Instead, it returns a preview: files that would be changed, records that would be updated, commands that would be executed, messages that would be sent, or browser actions that would be taken.
The value is not merely psychological reassurance. A useful dry-run exposes scope errors before they become state changes.
A good dry-run answers four questions
- What objects will be touched? Files, records, accounts, pages, recipients, repositories.
- What exact operation will happen? Create, edit, delete, send, publish, move, rename, execute.
- Why is each action necessary? The action should connect back to the PLAN.
- What evidence will be checked after the live run? The preview should already define verification.
Dry-run vs read-only
Read-only is a permission boundary: the system cannot write. Dry-run is an execution mode: the system may have write capability, but deliberately suppresses mutation and shows the intended result. Read-only protects by capability restriction; dry-run protects by preview.
Dry-run vs simulation
A simulation may model a simplified environment rather than exercising the real decision path. A strong dry-run should use the same inputs, selection logic, target resolution, and policy checks as the live action wherever possible. The closer it is to live execution without mutation, the more useful the preview.
Dry-run vs sandbox
A sandbox allows real actions inside an isolated environment. Dry-run applies no real mutation. They solve different problems and can be combined: first dry-run, then execute inside a sandbox, then verify.
Dry-run vs staging
Staging is a separate environment that resembles production. Dry-run is a mode of an operation. A mature workflow may use both: PLAN → DRY-RUN → ACTION in staging → EVIDENCE → ACTION in production → EVIDENCE.
What a dry-run should output
Would modify 3 files. Would delete 0 files. Would send 1 request. Scope: D:\70_AI only. Expected evidence after live run: file hashes change for A and B; C remains unchanged; outside-scope read remains denied.
A weak dry-run says “No changes were made.” A strong dry-run tells you exactly what would have changed and why.
When dry-run is especially valuable
- File deletion, bulk rename, migration, or cleanup.
- Database updates and batch edits.
- Email, Slack, publishing, or any external communication.
- Infrastructure and configuration changes.
- Browser automation with purchases, submissions, or irreversible forms.
- Agent workflows that cross multiple tools or accounts.
Approval gates
Dry-run often pairs with a human approval step. The sequence becomes: agent produces a preview, a person or policy checks scope, then the agent receives permission to execute. Approval is most useful when it is attached to the concrete preview rather than a vague request such as “May I continue?”
Dry-run still needs evidence
A correct preview does not prove that the live run succeeded. After ACTION, the workflow still needs EVIDENCE. That is why dry-run belongs inside the broader Plan → Action → Evidence protocol instead of replacing it.