title: Size the Blast Radius, Not the Task
date: 2026-08-28
slug: 2026-08-28-size-the-blast-radius-not-the-task
summary: Autonomy should track worst-case harm, not task difficulty. Reversibility, external visibility, and detection speed decide the gate.
tags: guardrails, autonomy, agentic-ops, failure-modes

# Size the Blast Radius, Not the Task

When people decide how much autonomy to give an agent, they usually ask the wrong question: *how hard is the task?* Easy tasks get autonomy, hard tasks get supervision. It feels intuitive. It's backwards.

The right question is: *if this goes wrong, what's the worst thing that happens?*

Consider two tasks. Task one: summarize yesterday's error logs into a morning report. Task two: click one button that restarts a service. By difficulty, the summary is harder — it takes judgment, synthesis, tone. The restart is trivial; a shell one-liner. But if the summary goes wrong, someone reads a slightly off report and asks a follow-up question. If the restart goes wrong — wrong service, wrong environment, wrong moment — you've caused an outage with a single keystroke.

Difficulty and danger are different axes. Autonomy should track danger.

## A quick sorting exercise

Take any action an agent can perform and ask three questions:

**Is it reversible?** A draft can be deleted. A sent email cannot be unsent. A dropped table cannot be un-dropped without a backup and a bad afternoon.

**Is it externally visible?** Everything inside the workspace — notes, drafts, analysis — has a blast radius of roughly zero. The moment something leaves the building (a message to a customer, a config change on shared infrastructure, a payment), the radius jumps an order of magnitude.

**How fast would you notice?** A wrong file write gets caught the next time someone reads the file. A wrong DNS change might smolder for hours before anyone connects the symptoms to the cause. Slow-to-detect failures deserve tighter gates than loud ones, even when they seem smaller.

Score those three, and the autonomy policy almost writes itself. Reversible, internal, fast-to-notice: let the agent run. Irreversible, external, slow-to-notice: human approval, every time, no matter how "easy" the action is.

## The failure mode this prevents

I've watched an operation nearly go sideways because a routine-looking maintenance step — the kind an agent had done unattended dozens of times — was pointed at the wrong environment. The task was identical in difficulty to all the previous runs. The blast radius was not. Nothing about the *work* had changed; everything about the *stakes* had. A difficulty-based policy sees no difference between those two runs. A blast-radius policy stops cold, because "production" is a different answer to question two.

That's the whole trick. Difficulty is a property of the task. Blast radius is a property of the *context* — and context is what changes underneath you while the task stays familiar.

## Make it explicit

Write the ladder down. For each tool or action category the agent has, record: reversible or not, internal or external, detection speed, and the resulting gate (free, logged, confirmed, or forbidden). When a new capability arrives, it gets sorted before it gets used. When an incident happens, you revisit one row instead of relitigating the whole philosophy.

Agents are very good at doing what they did last time. The blast-radius question is how you catch the day when "last time" no longer applies.

Sizing actions by harm instead of effort is a thread that runs through the whole book: [Ops by Agent](https://opsbyagent.com) walks the full ladder from shadow mode to earned autonomy.