[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-dry-run::en":3,"gloss-cluster-dry-run::en":26,"gloss-next-dry-run::en":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"dry-run","agents","Dry Run","A dry run executes everything about an operation except the part that changes the world: it reads the inputs, resolves the targets, applies the rules, and reports exactly what it would have done. The output is a plan, not a result. For automations and agents this is the cheapest safety mechanism available, because the risk in an automated action is rarely the individual step, it is the scope. A rule that archives stale records is correct in principle and catastrophic if the filter is wrong, and the difference between the two is visible in a list of affected rows and invisible in the code that produced it. A useful dry run has three properties. It resolves real targets rather than restating intent, so the operator reads the actual seventeen thousand records instead of the sentence archive inactive users. It is reachable from the same code path as the real run, because a preview implemented separately drifts from the executor and eventually lies. And it reports counts as well as examples, since the most common error by far is an order-of-magnitude scope mistake that a five-row sample hides perfectly. The limits are worth stating. A dry run cannot predict the effects of anything it did not simulate: an interaction with a downstream system, a trigger that fires on write, or a state that changes between preview and execution. Long-lived plans are especially misleading for agents, whose environment moves under them; a plan approved an hour ago may target rows that no longer match. The stronger pattern is to keep the interval between preview and execution short, re-resolve the targets at execution time, and abort if the resolved set differs materially from the one that was approved.","A dry run resolves real targets and reports what it would change without changing it: the cheapest scope check for an automation, and where it stops helping.",null,[11,14,17,20,23],{"slug":12,"name":13},"agent-budget","Agent Budget",{"slug":15,"name":16},"approval-workflow","Approval Workflow",{"slug":18,"name":19},"guardrails","Guardrails",{"slug":21,"name":22},"human-in-the-loop","Human-in-the-Loop",{"slug":24,"name":25},"idempotency","Idempotency",[27,29,33,36,39,42,45,48,51,54,57,61],{"slug":12,"category":5,"name":13,"updated_at":28},"2026-08-24T02:46:37+00:00",{"slug":30,"category":5,"name":31,"updated_at":32},"agent-checkpointing","Agent Checkpointing","2026-08-24T02:46:38+00:00",{"slug":34,"category":5,"name":35,"updated_at":28},"agent-handoff","Agent Handoff",{"slug":37,"category":5,"name":38,"updated_at":28},"agent-loop","Agent Loop",{"slug":40,"category":5,"name":41,"updated_at":28},"agent-memory","Agent Memory",{"slug":43,"category":5,"name":44,"updated_at":32},"agent-sandbox","Agent Sandbox",{"slug":46,"category":5,"name":47,"updated_at":32},"agent-trajectory","Agent Trajectory",{"slug":49,"category":5,"name":50,"updated_at":28},"agentic-rag","Agentic RAG",{"slug":52,"category":5,"name":53,"updated_at":32},"computer-use","Computer Use",{"slug":55,"category":5,"name":56,"updated_at":28},"context-engineering","Context Engineering",{"slug":58,"category":5,"name":59,"updated_at":60},"escalation-path","Escalation Path","2026-08-24T03:30:02+00:00",{"slug":62,"category":5,"name":63,"updated_at":28},"human-on-the-loop","Human-on-the-Loop"]