Blast-Radius Agents
Some agent tasks are too large before they are wrong.
"Clean up the auth layer." "Fix the migration." "Modernize the deployment config." "Repair these records." These requests may be legitimate, but they combine discovery, design, writes, validation, and rollout into one planner loop. If the planner is unreliable, the first safety move is not a better prompt. It is reducing the amount of system that any one run can affect.
That is the role of a blast-radius agent.
The thesis
A blast-radius agent decomposes risky work into smaller, permission-scoped actions. It does not decide that the risk is acceptable.
This distinction keeps it useful. The agent can identify affected surfaces, split a broad task into stages, mark irreversible operations, and propose review gates. It cannot grant itself wider permissions. It cannot approve the plan it just produced. It cannot turn "probably safe" into authority.
The output is a map for review, not a license to proceed.
The production pattern
The pattern appears when a user gives an agent a broad operational request.
An implementation agent is asked to update authentication callbacks and rotate related secrets. A data repair harness is asked to clean up records across tenants. A deployment assistant is asked to standardize configuration in multiple environments. Each request contains different kinds of risk: code changes, control-plane changes, data-plane effects, credentials, customer-visible behavior, and rollback complexity.
A blast-radius agent reads the proposed task before execution. It inspects the plan, touched components, ownership records, environment boundaries, required tools, and expected state changes. Then it decomposes the task.
For the authentication example, a useful decomposition might be:
- read-only inventory of callback usage
- code-only patch in a non-production branch
- tests for callback parsing
- staging configuration change
- secret rotation plan requiring explicit approval
- production rollout with a stop condition
- post-change verification
The blast-radius agent has not made the work safe. It has made the risk visible and reviewable.
The model
I define blast-radius agents with the same operational fields as any other harness component.
Inputs: task intent, proposed plan, dependency graph, ownership metadata, environment map, capability catalog, recent incidents or bad runs relevant to the same surface, and policy boundaries. It does not need private credentials. It needs to know which actions would require them.
Permissions: read-only access to repository metadata, deployment topology, policy definitions, and historical traces. It may create a decomposition report or request a review gate. It may not execute the decomposed steps.
Outputs: a risk inventory, a staged plan, required capabilities per stage, state expected to change, validation required after each stage, and review checkpoints. The output should separate reversible from irreversible actions.
Failure modes: underestimating hidden coupling, splitting work into steps so tiny that nobody can operate the plan, treating old ownership data as current, missing data-plane effects behind a control-plane change, or becoming a rubber stamp for large tasks.
Review path: the owner of the affected surface accepts, edits, or rejects the decomposition. The runner then receives only the next approved stage, not the entire broad task with a paragraph of cautions.
Where this goes wrong
The first failure is turning blast-radius analysis into another planning prompt. A broad natural-language plan is not enough. The output must bind stages to capabilities, files, environments, approvals, and validation.
The second failure is using the agent as a risk authority. A model can notice that a task touches production configuration and customer data. It should not decide that this is acceptable because the change looks small. Risk tolerance belongs to the system owner.
The third failure is ignoring coupling. Splitting code, config, and data into separate steps can reduce risk, but only if the dependencies between those steps are visible. A migration that is harmless before a deploy may be dangerous after it. A config change that looks isolated may affect every worker in a queue.
The fourth failure is applying the pattern to everything. A typo fix does not need a decomposition report. Use blast-radius agents where a single mistaken action could cross an ownership, permission, environment, or reversibility boundary.
What I do now
I trigger blast-radius review for specific conditions:
- production writes
- data deletion or repair
- migrations
- credential or permission changes
- multi-service edits
- generated changes above a reviewable size
- tasks that mix discovery and execution
- work where rollback is unclear
Then I require the decomposition to answer practical questions.
What is the smallest read-only step that improves certainty? Which step first requires write permission? Which state changes are reversible? Which approval applies to which stage? What evidence proves the stage completed? What stop condition prevents the next stage?
I also keep execution staged. The worker gets the first approved unit, completes it, records evidence, and stops or requests the next unit. That pattern feels slower than handing the whole task to a planner, but it prevents one bad inference from becoming a broad write.
For generated code changes, the blast-radius agent is especially useful before the first write. It can identify protected directories, test gaps, migration files, release notes, and owners. It can say "start with a read-only inventory and a proposed diff outline." It cannot say "go ahead."
Closing takeaway
A blast-radius agent should make risky work smaller before any worker touches the system. If the same run can discover, decide, write, and roll out a broad change, the blast radius is still too large.