Multi-agent risk management: containing agent blast radius

The first time a multi-agent system fails in production, it rarely fails the way you expected. A single agent that returns a wrong answer is a contained problem. An orchestrator that spawns five subagents, one of which gets stuck in a tool-call loop while another quietly takes a destructive action with stale context — that's a different category of incident. The risk isn't that agents are wrong sometimes; every system is wrong sometimes. The risk is that in a multi-agent setup, a small mistake can amplify before anyone notices.

This post is a practical risk-management guide for teams running multi-agent systems on Claude. We'll walk through the failure scenarios that actually happen, define blast radius in a way you can measure, and lay out the containment controls that keep a bad run from becoming a bad day. The goal isn't zero failures — it's bounded, observable, recoverable failures.

The failure modes that are unique to multi-agent

Single-agent systems fail in familiar ways: hallucination, a bad tool call, a refusal. Multi-agent systems inherit all of those and add several of their own. Cascade failure is the headline one: an orchestrator delegates based on a subagent's flawed output, and the error propagates downstream as if it were ground truth. Because each agent trusts the layer above it, a single bad premise can corrupt an entire run.

Then there's runaway delegation, where agents spawn subagents that spawn more subagents, burning tokens and wall-clock time on a task that should have been a single call. Context drift happens when a long-running agent's working context diverges from current reality — it acts on data that was fresh three steps ago and is now stale. And uncoordinated side effects are the scariest: two parallel subagents both decide to write to the same system, or one takes an irreversible action the orchestrator didn't anticipate. None of these show up in a five-minute demo, which is exactly why they bite in production.

How to think about blast radius

Borrow the term from reliability engineering: blast radius is how much damage a single failure can do before something stops it. For multi-agent systems, you can decompose it into four dimensions you can actually instrument and bound.

flowchart TD
  A["Agent run starts"] --> B{"Action reversible?"}
  B -->|Yes| C["Low blast radius — log & continue"]
  B -->|No| D{"Within budget & depth limits?"}
  D -->|No| E["Halt run, alert operator"]
  D -->|Yes| F{"Passes pre-action check?"}
  F -->|No| G["Require human approval"]
  F -->|Yes| H["Execute in scoped sandbox"]
  H --> I["Record side effect for rollback"]

The four dimensions are reversibility (can the action be undone?), scope (how many systems or records can a single run touch?), spend (token and tool-call budget before a hard stop), and autonomy (how far the agent can go without a human in the loop). A run that can only read data, touch one record, costs at most a bounded number of tokens, and pauses before any write has a tiny blast radius. A run that can delete production data, fan out unboundedly, and never asks permission has an enormous one. Most containment work is about consciously moving runs from the second profile toward the first.

Containment control 1: scope tools, not just prompts

The strongest containment lever is the set of tools each agent can call, because that defines the literal space of actions it can take. Prompts are guidance; tool grants are hard boundaries. A research subagent should have read-only tools and no ability to write anywhere. An agent that drafts a change should produce a proposal that a separate, narrowly scoped agent or a human executes — separating the agent that decides from the agent that acts dramatically shrinks blast radius.

With MCP and the Claude Agent SDK, you control exactly which servers and tools each agent in your topology can reach. Use that. Give the orchestrator the ability to delegate but not to take destructive actions directly. Give each subagent the minimum tool set for its job. The principle is identical to least-privilege access in security, and it's just as load-bearing here.

Containment control 2: budgets, depth limits, and circuit breakers

Every multi-agent run should execute under hard limits it cannot exceed. Set a maximum delegation depth so subagents can't recurse forever. Set a token budget per run and a tool-call ceiling, and halt the run when either is hit. These aren't performance optimizations — they're safety mechanisms. Runaway delegation is contained the moment the system simply refuses to go deeper or spend more.

Add circuit breakers for repeated failure: if an agent calls the same tool with the same arguments three times and keeps failing, stop and escalate rather than letting it grind. The pattern mirrors what distributed-systems engineers already do for flaky downstreams. A multi-agent system without budgets and breakers is a system that will eventually surprise you with a bill or an incident.

Tune these limits empirically rather than guessing. Run your eval suite while logging the actual depth, token spend, and tool-call count of successful runs, then set ceilings comfortably above the legitimate maximum and well below the pathological cases. If real tasks finish in two levels of delegation and a few thousand tokens, a hard stop at four levels and a generous token cap will catch runaway behavior without strangling honest work. Revisit the numbers as your task distribution shifts, because limits that fit last quarter's workload can quietly start rejecting valid runs.

Containment control 3: human-in-the-loop where it counts

Not every action needs human review, but the irreversible and high-scope ones do. The right design routes low-risk, reversible actions to full autonomy and gates the dangerous ones behind an approval step. The trick is choosing the boundary deliberately rather than either rubber-stamping everything or, worse, letting agents act freely on production systems because review felt slow.

A clean implementation has agents emit a structured proposal — what they want to do and why — that a human or a stricter policy check approves before execution. This keeps agents fast on the 90% of work that's safe while putting a person in the loop for the 10% that could hurt. Over time, as your evals prove certain action types are reliably safe, you can graduate them to autonomy with confidence rather than hope.

Making failures observable and recoverable

Containment isn't only about prevention; it's about detection and recovery. Every agent run should produce a complete transcript — every delegation, tool call, and decision — so that when something goes wrong, you can reconstruct exactly what happened. Treat these transcripts as first-class telemetry, not debug spew. Pair them with metrics on run depth, spend, and failure rates so behavioral drift shows up on a dashboard before it shows up in a customer complaint.

For recovery, design side-effecting actions to be reversible or at least logged in a way that supports rollback. If an agent wrote something, you want a record of what it wrote and a path to undo it. The teams that sleep well aren't the ones whose agents never fail — they're the ones who can see every failure and unwind it quickly.

It helps to rehearse failure deliberately rather than waiting for it. Run game-day exercises where you deliberately feed the system a poisoned input or simulate a tool returning garbage, and watch whether your containment holds — does the budget trip, does the circuit breaker fire, can an operator halt a run mid-flight? Each rehearsal turns an abstract control into a tested one and surfaces the gap between the safety you designed and the safety you actually have. The cost of finding that gap in a drill is trivial; the cost of finding it during a real incident is not.

Frequently asked questions

What is blast radius in a multi-agent system?

Blast radius is the maximum damage a single agent run can cause before a control stops it, measured across reversibility, scope, spend, and autonomy. Containing it means bounding each dimension — read-only tools, depth and token limits, and human approval for irreversible actions — so that no individual failure can escalate without limit.

How do I stop agents from spawning subagents endlessly?

Enforce a hard maximum delegation depth and a token budget per run, and halt when either is exceeded. Runaway delegation is a resource-exhaustion problem, and the fix is the same as any resource limit: a ceiling the system cannot exceed, plus a circuit breaker that escalates after repeated failures rather than retrying forever.

Should every agent action require human approval?

No — that defeats the point of automation. Gate only the irreversible and high-scope actions, and let reversible, low-scope ones run autonomously. As your evals demonstrate that specific action types are reliably safe, graduate them from review to autonomy. The goal is fast on the safe majority, careful on the dangerous minority.

Bringing safe agents to your phone lines

CallSphere applies these same containment patterns to voice and chat — multi-agent assistants that act on tools mid-call within scoped, observable, recoverable limits. See the controls in action at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.