Blast Radius

The size of an action is not the size of its consequences.

September 30, 2026 4 min read

An action looks small when you describe it by the button the agent pressed. Its real size appears when you follow it outward: which customers see it, which workflows depend on it, which promises it alters, and which later decisions now assume it happened.

That outward chain is the action's blast radius.

Small actions travel farther than they appear

A status change can trigger a notification. The notification can change a customer's expectation. That expectation can change a support plan, a renewal conversation, or a launch commitment. None of those consequences is visible in the original status update, but they are still part of what the action did.

This is why a permission to edit one field is not automatically a permission to make one small decision. The field may be a junction in a much larger system of assumptions.

The first question before an automated action should be: what does this directly change? The second should be: what will other people reasonably do because it changed?

Trace commitments, not just dependencies

Dependency graphs are useful, but they tend to show technical relationships. A blast-radius review needs to include commitments that live outside the code:

1. People: who will read, trust, or act on the result?
2. Workflows: which processes will now follow a different path?
3. Decisions: which plans or assumptions will treat the result as evidence?
4. Promises: which customer, partner, or internal expectation will move with it?

An action with few technical dependencies can still have a large social or operational radius. A customer-facing label may touch no other service while changing how every support conversation is framed.

The radius is not the same as irreversibility

Reversible by Whom? makes the related point that a rollback can restore system state without restoring trust, time, or expectations. Blast radius adds a measurement question: how many commitments are exposed before anyone tries to roll it back?

An action may be easy to reverse and still deserve a preview because many people will act on it during the short window before reversal. Another action may be hard to reverse but affect only one isolated workflow. Reversibility and radius are different dimensions, and an agent needs both.

The One-Way Doors frame helps with the first dimension. Blast-radius thinking supplies the second: where does this action land, and who has to absorb it?

Preview the people downstream

A useful agent preview should show more than the proposed mutation. It should name the direct target, the likely downstream commitments, and the first safe point at which someone can inspect the effect.

That preview does not need to predict every consequence. It needs to make the important path visible enough for a human to catch a missing dependency before the action travels further.

Reserve deliberate review for actions whose radius crosses a customer boundary, changes a shared commitment, or creates evidence that other work will rely on.

Make the radius part of the permission

Permissions are usually written around operations: edit, send, delete, publish. A safer boundary also describes reach. An agent may be allowed to update an internal draft, but not publish it. It may prepare a customer message, but not send one. It may change a local setting, but not one that controls a shared workflow.

Before granting an agent a new action, run the four checks above. The answers describe the real permission surface better than the API method does.

An action is safe to automate when its effects are bounded, inspectable, and recoverable by the people who bear them. When the radius is wide, the preview and the approval boundary should widen with it.

Frequently asked questions

Is blast radius the same as impact? Impact describes what happened after the fact. Blast radius is the reachable set of people, workflows, decisions, and promises you should inspect before acting.

How can an agent estimate blast radius? Start with the direct target, then trace notifications, shared records, dependent workflows, and commitments linked to the target. Mark uncertainty instead of inventing a complete graph.

Does a large blast radius always require human approval? Not always. A reliable preview, a constrained permission, or a staged rollout can be enough when the effects are inspectable and recoverable.

What should happen when the radius is unclear? Treat uncertainty as part of the risk. Narrow the action, produce a preview, or ask the person who owns the downstream commitment before proceeding.