Español

Make the Stakes Concrete: Blast Radius, Reversibility, Time Cost

"Could cause issues" is not a risk assessment.

When your agent surfaces a decision and describes the stakes as "this might cause problems" or "be careful here," it has given you nothing to act on. Vague stakes are the model's way of gesturing at risk without doing the work of measuring it. You can't weigh a decision against a warning that fits every decision. The whole reason you asked the agent to flag the risk was so you could tell a big one from a small one — and a fuzzy stakes line erases exactly that distinction.

Why vague stakes are worthless

Risk only helps you choose when it's comparable. "Could cause issues" attaches to a typo fix and to dropping a production table equally, so it can't rank anything. To decide, you need to know how much is at risk and how recoverable the outcome is. A decision that's trivially undoable deserves a fast yes; one that touches irreversible production state deserves a pause, a review, maybe a human. Undifferentiated caution collapses both into the same shrug.

The fix: three concrete dimensions

Require every surfaced stake to name three things:

• Blast radius — what this actually touches. One function? One service? Every user record? The shared production database?
• Reversibility — can you undo it, and how hard? A revertible commit is a different animal from a schema migration that's run against live data.
• Time cost — how long to recover if it goes wrong. Minutes to roll back, or days to rebuild and reconcile?

Put it directly in the agent's instructions:

When you surface a decision, state the stakes concretely. For each option:
- BLAST RADIUS: exactly what it touches (files, services, data, users)
- REVERSIBLE?:  yes/no + how you'd undo it
- TIME COST:    realistic recovery time if it goes wrong
Never write "could cause issues." Name the specific consequence.

Vague versus concrete, side by side:

Now you can actually choose. One path is reversible and local; another touches a production migration you can't take back. Same decision surface, completely different call — and now the difference is visible.

Power moves

• Rank by irreversibility, not effort. The scariest quadrant is high blast radius plus low reversibility. Route those to a human review gate automatically.
• Ask for the recovery plan, not just the risk. "How would you undo this?" forces the model to prove reversibility instead of asserting it.
• Reuse the vocabulary across the org. Blast radius / reversibility / time cost is the same language good incident and change-management practice already uses, so agent output slots straight into your review process.
• Make it a gate, not a footnote. For an autonomous agent, "irreversible + wide blast radius" should stop and ask, the way one-way-door decisions get escalated rather than defaulted.

Resources

• Two-way and one-way door decisions — Amazon shareholder letter (2015)
• Google SRE Book — Postmortem culture and change management
• Anthropic — Prompt engineering overview
• OpenAI — Prompt engineering guide