Scope an agent by the cost of its single worst mistake, not the value of its average success. Define blast radius — the maximum harm one unsupervised action can cause — for every action the agent can take, cross it with how reversible that action is, and use the resulting matrix to set autonomy levels and approval gates. A high-blast-radius, low-reversibility action gets a human in the loop no matter how rarely it fails.
Quick answer: Blast radius is the worst-case damage from a single agent action. Pair it with reversibility to build a risk matrix, then set autonomy (full autonomy, approval-required, or blocked) per action — not per agent. Cap the size of any single action so its failure mode is survivable.
What Is Blast Radius, and Why Average Success Rate Is the Wrong Metric
Blast radius is the maximum damage one unsupervised agent action can cause before anyone notices. It is not the agent's error rate — it is the size of the worst single error. A 99% accurate agent with a $50,000 blast radius is riskier than a 90% accurate agent with a $50 blast radius.
Most teams evaluate agents the way they evaluate models: accuracy, F1, task-completion rate. Those are averages. They tell you how the agent behaves across a thousand runs. They tell you nothing about what happens on the one run that goes catastrophically wrong — and that one run is the one that ends up in an incident review.
This is the same asymmetry that shows up in reliability engineering and risk management generally. Nassim Taleb's writing on tail risk makes the point bluntly: optimizing for the average case while ignoring the tail is how systems blow up in ways nobody modeled. An agent's average performance is reassuring right up until the day it wires the wrong amount, deletes the wrong record, or emails the wrong customer list — and "it usually works" is not a defense anyone accepts after the fact.
Blast radius has three components you need to size independently:
- Financial exposure — the dollar value a single action can move, spend, or destroy.
- Reach — how many people, records, or systems one action touches (one customer vs. every customer).
- Visibility delay — how long before a human would notice the mistake without being told.
A support-ticket-tagging agent has small blast radius on all three axes: mislabeling one ticket costs little, touches one record, and is caught the next time someone looks at the queue. A payments agent has large blast radius on all three: one bad transaction can be large, irreversible, and invisible until a customer complains or a reconciliation report runs days later.
Before you can size blast radius for a given agent, you need to have actually decomposed what the agent does into discrete actions — which is exactly what a five-part agent spec structure forces you to do before you write a line of autonomy logic.
How to Actually Measure an Action's Blast Radius
Blast radius is measured per action, not per agent — a single agent usually mixes low-risk and high-risk actions, and treating them identically wastes either safety budget or velocity. Score each distinct action the agent can take on a simple scale, then let the worst-scoring action set the ceiling for how much autonomy the whole agent gets.
Walk every action the agent can take through three questions:
- What is the maximum plausible value at stake if this action is wrong? Not the typical case — the worst case you can construct that isn't absurd.
- How many entities does one execution touch? A single row, a customer segment, or the entire database.
- Is the action a write, a send, or a delete? Sends and deletes compound blast radius because they escape your own system.
| Action type | Typical blast radius | Example |
|---|---|---|
| Read / query | Near zero | Agent pulls a customer's order history to answer a question |
| Draft / suggest (human sends) | Low | Agent drafts a refund email a human reviews before sending |
| Internal write, single record | Low-medium | Agent updates a CRM field on one contact |
| Internal write, batch | Medium-high | Agent re-tags 10,000 records overnight |
| External send | High | Agent emails a customer segment directly |
| Financial transaction | High | Agent processes a payment or refund |
| Irreversible delete | Highest | Agent deletes records or cancels a subscription |
Notice the pattern: the blast radius jumps sharply the moment an action leaves your system's boundary (a send) or destroys information (a delete). Those two transition points are where most teams under-scope risk, because the agent's internal logic looked fine in testing — the danger was always in what the action touched on the way out.
This is also where scope creep quietly turns a safe agent into a dangerous one. An agent whose goal was written as "keep the CRM tidy" and drifted into "also message customers when data looks stale" has silently jumped from near-zero blast radius to high blast radius without anyone re-running the risk assessment. That drift is precisely what a disciplined process for how to write an agent goal without drift is meant to catch before it ships.
Combining Blast Radius With Reversibility to Build a Risk Matrix
Blast radius alone doesn't tell you what to do — you also need to know if the action can be undone. A large mistake that reverses cleanly in five minutes is a very different risk than a small mistake that's permanent. Crossing the two dimensions produces a matrix that maps directly to autonomy policy.
Reversibility isn't binary either. Score it in three bands:
- Fully reversible — a config change, a draft, a status flag you can flip back.
- Reversible with cost — a refund you can claw back, a sent email you can follow up on, a delete you can restore from backup within a window.
- Irreversible — money left a bank, a customer churned, a record is permanently gone, a public message went out.
Cross that against blast radius (low / medium / high) and you get a four-quadrant autonomy policy that is far more defensible in an incident review than "the agent seemed reliable in testing":
| Low blast radius | Medium blast radius | High blast radius | |
|---|---|---|---|
| Fully reversible | Full autonomy | Full autonomy, logged | Approval required |
| Reversible with cost | Full autonomy, logged | Approval required | Approval + limits |
| Irreversible | Approval required | Approval + limits | Blocked / human-only |
Read the matrix as a design constraint, not a description: if an action lands in the bottom-right, the fix usually isn't "add more testing" — it's "change the action" so it lands somewhere better. That reframe is the whole point of the exercise.
Three ways to move an action up-and-left on this matrix, in order of how often they actually get used:
- Cap the size so worst-case damage shrinks even if the failure still happens.
- Add a reversibility window (a hold period, a confirmation step, a delayed send) so an irreversible action becomes reversible-with-cost.
- Split the action into a low-risk draft step the agent owns and a high-risk commit step a human owns.
Worked Example: Capping a Payments Agent's Per-Transaction Amount
A payments agent that reconciles invoices and issues refunds has an obvious high blast radius: it moves money, and a bad call is often irreversible once funds leave. Rather than deciding "should this agent be autonomous or not" as a single yes/no, split the decision by transaction size — because the actual blast radius scales with the amount, not with the agent's existence.
Here's how that plays out as a concrete policy, following the matrix above:
- Under $50: Full autonomy, logged. Worst case is a rounding error a human can fix in a support ticket; the cost of requiring approval on every $12 refund exceeds the cost of the occasional mistake.
- $50–$1,000: Approval required, batched into a daily digest a human clears in minutes. Blast radius is now real money but still small enough that a delay of hours doesn't matter.
- $1,000–$10,000: Approval + limits — a named approver must sign off in real time, and the agent cannot issue two large refunds to the same account within 24 hours (capping compounding errors).
- Over $10,000: Blocked. The agent can draft the refund and the supporting evidence, but a human initiates the transfer. This isn't distrust of the agent's judgment on any single case — it's that the worst-case single error at this tier is large enough to be a board-level conversation.
The design move that matters here isn't the dollar thresholds — yours will differ by business. It's that the cap converts "the agent might be wrong" into "the agent, when wrong, cannot be wrong by more than $X." That's a survivable failure mode instead of an open-ended one, and it's a sentence you can put in a postmortem without flinching.
This is the same logic Google's Site Reliability Engineering discipline applies to blast radius in deployments — canary releases and staged rollouts exist specifically to cap how much of the fleet one bad change can reach before a human or automated check intervenes. Scoping an agent's transaction size is the PM-side equivalent of a canary percentage: it bounds exposure without requiring you to first prove the change is safe.
It's also worth remembering why the cap matters even for an agent that's right 99% of the time: one bad autonomous action, at the wrong size, is often enough to make a human stop trusting the agent's judgment entirely — the trust doesn't erode gradually, it falls off a cliff after a single bad incident. That dynamic is worth understanding on its own terms in the agent trust cliff of one bad action, because it's the reason under-scoping blast radius costs you more than the dollar amount of the mistake itself.
Setting Autonomy Levels That Match the Matrix, Not the Org Chart
Autonomy should be set per action based on its matrix position, not as a single global setting for "how much do we trust this agent." Teams that set autonomy at the agent level either over-restrict the safe 80% of actions or under-restrict the dangerous 20% — both are expensive, just in different currencies.
A practical way to operationalize this is a three-tier autonomy vocabulary that maps cleanly onto the matrix:
| Autonomy tier | Matrix position | What it means operationally |
|---|---|---|
| Autonomous | Low blast radius, any reversibility | Agent acts, logs the action, no gate |
| Supervised | Medium blast radius, or low blast radius + irreversible | Agent acts, human reviews async (digest, spot-check sample) |
| Gated | High blast radius, or irreversible + medium/high | Agent proposes, human approves before execution |
Two failure modes to watch for as you assign tiers:
- Autonomy inflation — an action starts Gated, works fine for a month, and someone quietly promotes it to Autonomous because the approval step "feels like friction." Blast radius didn't change; only patience did. Re-approve tier changes with the same rigor as the original decision.
- Tier-by-agent instead of tier-by-action — assigning one tier to "the payments agent" instead of to each action it can take. This is the single most common scoping mistake, and it's why the worked example above splits by transaction size rather than treating the agent as one monolithic risk.
Tie the tier decision back to the goal statement itself: if you can't state, in one sentence, why an action is Autonomous versus Gated, the goal is probably underspecified — which is again a signal to revisit how the agentic workflow was scoped from the start rather than patching the autonomy setting after an incident.
Where Blast Radius Fits Alongside Reversibility, Confidence, and Frequency
Blast radius is necessary but not sufficient — a full risk model also weighs how confident the agent is on a given case and how often the action fires, since a high-blast-radius action that runs once a year needs a different gate than one that runs a thousand times a day. Treat blast radius as the ceiling on autonomy and let confidence and frequency adjust within that ceiling.
- Confidence — even a Gated action can auto-approve when the agent's confidence score clears a high bar (e.g., an exact match against a known-good pattern), provided the confidence score itself has been validated against real outcomes, not just self-reported.
- Frequency — a rare high-blast-radius action (canceling an enterprise contract) can tolerate a slower, heavier approval process than a frequent one (processing routine refunds), where a slow gate just becomes a queue nobody clears.
- Blast radius — sets the outer bound neither of the above should be allowed to override. No confidence score should promote a $50,000 wire transfer to Autonomous.
This layering matters because teams that get seduced by a high confidence score into loosening the gate on a high-blast-radius action are making the same mistake as trusting average success rate: they're reading a number that describes the common case and applying it to a decision that's actually about the tail case. The two numbers answer different questions and neither substitutes for the other.
How Prodinja Applies This in Practice
Sizing blast radius by hand across a spec with a dozen actions is exactly the kind of bookkeeping that gets skipped under deadline pressure — which is why Prodinja's Agentic Workflows tool has you tie constraints and approval requirements to each action's blast radius as part of building the spec, rather than as a separate document someone writes after the agent ships. The intent is that high-cost mistakes get bounded by the design itself, not caught later by a human noticing something looks wrong.
That doesn't replace the judgment calls in this article — you still have to decide what "high" means for your payments flow, your data, your org's risk appetite. What it changes is where that decision lives: attached to the action in the spec you're already building, instead of in a spreadsheet that drifts out of date the first time someone adds a new action type.
Key Takeaways
- Blast radius is the worst-case damage from one action, not the agent's average accuracy — score it separately for every distinct action the agent can take.
- Cross blast radius with reversibility to get a four-quadrant matrix that maps directly to autonomy policy: full autonomy, supervised, or gated.
- Cap the size of high-blast-radius actions (like per-transaction limits) so the worst single failure is survivable rather than open-ended.
- Set autonomy per action, not per agent — a single agent usually mixes low-risk and high-risk actions that deserve different gates.
- Watch for autonomy inflation — a Gated action quietly promoted to Autonomous because the approval step felt like friction, without blast radius having actually changed.
- Confidence and frequency adjust within the blast-radius ceiling, but never override it — no confidence score should promote an irreversible, high-cost action to full autonomy.
Frequently Asked Questions
What is blast radius in the context of AI agents?
Blast radius is the maximum harm a single unsupervised agent action can cause — measured in financial exposure, how many records or people it touches, and how long before a human would notice. It's a worst-case metric, deliberately distinct from the agent's average success rate.
How is blast radius different from an agent's error rate?
Error rate describes how often the agent is wrong across many runs; blast radius describes how bad the single worst run can be. An agent can have a low error rate and a catastrophic blast radius at the same time — a 99%-accurate payments agent with no transaction cap is still one bad call away from a very expensive incident.
How do I decide which agent actions need human approval?
Score each action's blast radius (low/medium/high) and reversibility (fully reversible, reversible with cost, irreversible), then place it on the resulting matrix. Actions in the high-blast-radius, low-reversibility quadrant need approval or should be blocked from autonomous execution entirely; low-blast-radius, fully-reversible actions can run autonomously with logging.
Should the same agent have different autonomy levels for different actions?
Yes — this is one of the most common scoping mistakes, treating autonomy as a single setting for the whole agent instead of per action. A payments agent, for example, can run small refunds autonomously while requiring real-time approval for large transactions, because the blast radius scales with transaction size, not with the agent's identity.
Does capping blast radius slow the agent down too much to be useful?
Capping only restricts the worst-case tail, not the common case — a $50 autonomy threshold, for instance, lets the vast majority of routine transactions run untouched while gating the rare large ones. The goal is bounding the failure mode, not throttling normal throughput, and the caps can be set high enough to be nearly invisible in day-to-day operation while still preventing the catastrophic tail case.