Cross-post of Insights #15 — canonical: https://sheikhwasim.com/insights/blast-radius-cap-what-one-run-can-touch/
The agent stayed inside budget. That was not enough.
It closed 412 tickets in forty minutes, spent almost nothing, and left every dashboard green. Tokens, tool calls, time, and dollars all stayed under the Run Budget you added last sprint. The damage was elsewhere. One bad classification rule touched every open ticket in the queue.
Most teams limit how much an agent can spend. Almost nobody limits how much it can change. A model with write tools and a wide queue is a blast radius with a prompt on top. The fix is a Blast Radius: every run starts with a hard cap on writes, entities, and systems it can touch, enforced in plain code. When the cap trips, the run stops and the fleet pauses until a person looks.
Quick use case
Situation. A B2B SaaS support team runs a triage agent overnight. It reads new tickets, tags them, suggests a priority, and for a short list of "spam / duplicate / out of scope" patterns it can close the ticket and post a short reply. On a normal night it closes about 20 tickets and tags a few hundred. Cost is pennies.
What broke. A new prompt version tightened the "out of scope" pattern. The model started matching anything that mentioned a competitor, a free-tier limit, or a feature request. The agent still called one tool per ticket, stayed well under its token and dollar caps, and finished early. By morning, 412 tickets that needed a human reply were closed with the same canned note. Reopening them took two days and a public apology in the community forum. The Run Budget report said the night was healthy.
Every write looked cheap. The total change was the bug.
The fix (Blast Radius).
- Cap change, not just spend. Each run may write to at most 25 tickets, touch one product area, and call at most two write tools.
- Count mutations in the orchestrator. Tag updates, closes, and replies all increment the same write meter. The model never raises its own cap.
- Stop at the cap with a named state. When writes hit 25, the run ends as
blast_radius_exhausted, with the ticket IDs it already changed attached. - Fleet pause on a spike. If any night closes more than 2x the 7-day median, the job pauses and pages on-call before the next batch starts.
- Undo path for the batch. Every close carries an Undo Ledger reverse, so a bad night reopens the exact set instead of a hand-built CSV.
Same model family, same queue. The next prompt regression stopped at 25 closes, paged a person, and reopened with one reverse.
Why a spend limit is not a safety limit
A Run Budget answers "how expensive can this get?" A Blast Radius answers "how much of the world can this rewrite before we notice?" Cheap damage is still damage. An agent that closes tickets, updates CRM fields, or pushes config can ruin a week of customer trust for less than the cost of a coffee.
Bulk tools and "process the whole queue" prompts make this worse. Each step looks reasonable. The aggregate crosses a line no single tool call can see. Spend alerts will not catch it, because the spend never spiked. You need a limit that counts effects: records written, entities touched, and systems mutated.
The Blast Radius (five layers)
1. Three meters on every run
Writes (creates, updates, deletes, sends), entities (distinct ticket / account / order IDs), and systems (which backends may be mutated this run). Set them from real traces: take a normal night's change volume and allow about 2–3x, not 100x. Dollars and tokens stay on the Run Budget; these meters sit beside it.
2. Enforced outside the model
The orchestrator checks the meters before every mutating tool call. Read-only tools do not count. The model can see remaining room, but it cannot widen the radius. Same rule as the Boundary Contract: boring code owns the hard rules.
3. A clean stop state
blast_radius_exhausted is a real outcome, like approved or budget_exhausted. It carries which meter tripped, the entity IDs already touched, and a pointer to the undo batch. A run that stops this way is a signal, not an incident you discover on social media.
4. Fleet pause, not just per-run stop
One run's cap stops one bad loop. A fleet rule stops a thousand small runs that each look fine. Track closes, updates, and sends per job per hour against a rolling baseline. Cross a multiple of that baseline and pause the job, page a person, and leave the queue alone. Stamp every run with the Release Pin so you can tell whether the spike came from a prompt, a model, or a data shift.
5. Reverse the batch, not the night
Pair the radius with an Undo Ledger. Every mutating step records its reverse. When the fleet pauses, on-call can roll back the exact entity set instead of reconstructing impact from logs. A radius without a reverse turns every trip into a scavenger hunt.
How this maps to what you already have
- 5-layer agent stack. Blast Radius lives in Guardrails and is enforced by Orchestration; every trip is recorded in Traces.
- Run Budget. Keep both. Spend caps stop loops that burn money; radius caps stop loops that burn trust.
- Receipt Gate. A write that would exceed the radius never gets a receipt, because it never runs.
- Permission Envelope. The envelope says what the agent may do; the radius says how much of it in one run.
- Ship Gate. Add one check: no agent with write tools ships without per-run write/entity/system caps and a fleet pause rule.
A test you can run this week
Pick one production agent that can mutate something (tickets, CRM, config, email). From last week's traces, count max writes, distinct entities, and systems touched in a single run, and the biggest hour for the whole job.
Then ask two questions: (1) Is there a hard cap below "the whole queue"? (2) If a new prompt closed or updated 10x the usual volume at almost no cost, would anything pause before morning?
If either answer is no, you need a Blast Radius before you need a better classifier.
Closing
A cheap agent can still make an expensive mess. Cap writes, entities, and systems per run in plain code, make blast_radius_exhausted a normal outcome with the touched IDs attached, pause the fleet when change volume spikes, and keep a reverse for the batch. The goal isn't a timid agent. It's an agent whose worst night has a known shape, a known stop, and a known undo.
I'm Wasim Sheikh, AI Architect. I build systems teams trust and organizations depend on: not demos, not proofs of concept, production.
Follow for practical AI architecture that ships.
Connect on LinkedIn: Wasim Sheikh · Site: sheikhwasim.com · Notes: Wasim Sheikh on Substack (practicalainotes.substack.com) · X: @anciwasim
