The multi-agent playbook. Blast radius multiplies non-linearly. One compromised agent’s output becomes every downstream agent’s input. Traceability is the discipline that makes the response possible.

This file is one self-contained piece of the AI IR Overlay™ framework. Cross-references to other pieces point to other packages in the same set, which you can obtain at jacobideji.com.

Playbook 08: Multi-Agent Systems Multiply Blast Radius

In a single-agent system, the blast radius is what one agent can touch. In a multi-agent system, the blast radius is what every agent can touch that consumes the originating agent’s output. Contain the originating agent, not just the failure.

Premise

Single-agent incident response is a problem the framework’s first nine playbooks have solved. One privileged identity, one tool list, one scope of write targets, one chain of evidence. The Six Triage Questions answer the scoping problem in 60 seconds per question. The Kill-Switch ladder contains in under 10 minutes. The Minimum Evidence Set exports in 60 minutes.

Multi-agent architectures break these assumptions. When one agent researches, a second drafts, and a third executes, the workflow becomes a chain of delegation, parallel actions, and shared tool access. The same delegation that creates efficiency creates opacity. Without a complete chain of custody across agents, you cannot scope the incident, brief leadership, or defend the response. The blast radius is no longer additive. It is multiplicative. One compromised agent’s output becomes every downstream agent’s input. One injected instruction becomes a sequence of legitimate-looking, harmful actions that each downstream agent executes through its own valid credentials and authorized tools.

This is the multi-agent playbook in the AI IR Overlay series. Where Playbook 07: Secrets and Tokens specifies credential discipline for one agent at a time and Playbook 11: Monitoring specifies the detection signals from one agent’s behavior, this playbook specifies what changes when the agents are wired into a topology that shares context, delegates work, and consumes each other’s outputs. The Mental Model still applies. The framework’s templates still apply. But the response sequence has new requirements that single-agent playbooks did not have to address.

The 2026 enterprise context is that multi-agent architectures are leaving research demos and entering production. Model Context Protocol (MCP) clients connect to MCP servers that themselves call other agents. Orchestration frameworks (AutoGen, CrewAI, LangGraph multi-agent, Anthropic’s Claude Agent SDK with sub-agents) ship multi-agent topologies as default patterns. The agent mesh is the new microservices mesh, and it carries the same containment problem that took the microservices community a decade to solve: how do you stop the cascade before it reaches every dependent service?

Mental Model clauses engaged: Acts (primary). Every agent in the topology is a privileged identity; the topology itself is a graph of privileged identities, not a single one. The privileged-identity lens scales by graph traversal, not by enumeration. Changes (secondary). The inter-agent communication contracts (MCP schemas, structured outputs, type-checked interfaces) are software contracts. They require versioning, rollback, and code-review discipline. An undocumented contract change between two agents is a deployment, not a configuration tweak.

Use this playbook when: designing a new multi-agent deployment for production, responding to an incident in an existing multi-agent topology, building the agent-dependency map in your AI-BOM, evaluating whether an orchestration framework is safe to adopt, after a single-agent incident exposed downstream-cascade risk that single-agent response did not address, or when Playbook 11 (Monitoring) detects an inter-agent traffic anomaly.

First-Hour Actions

The first hour of a multi-agent incident has one job that the first hour of a single-agent incident did not: stop propagation before scoping individual agents. In single-agent response, you can contain and investigate in the same sequence. In multi-agent response, the cascade propagates faster than you can investigate. Containment of one agent while the orchestrator continues delegating is the equivalent of closing a single browser tab while malware spreads through the rest of the session.

The 60-minute multi-agent triage

Minute Action Owner
0–10 Stop the orchestrator first, then the originating agent. If the orchestrator or router (the LangGraph node, the AutoGen group chat coordinator, the MCP server, whatever component issues delegations) is still running, every minute it runs is a minute of cascade. Disable it. Then Mode M4 Full Disable on the agent that produced the originating signal. Incident Commander
10–25 Build the dependency map for this incident. Pull the agent-dependency section from each affected agent’s AI-BOM. If the dependency map does not exist, write it from runtime telemetry now. The output is a directed graph: which agent delegated to which, in what order, carrying what payload. Without this graph, scoping the blast radius is guesswork. Platform engineer + agent owners
25–40 Move every agent in the topology to Mode M2 Approvals Required, fleet-wide. Not just the originating agent. The downstream agents may have already consumed the poisoned output and queued Tier-2 actions; M2 catches them before they execute. Tier-0 reads stay live to avoid a business standstill. Tier-1 SOC + agent business owners
40–55 Walk the Six Triage Questions per agent in dependency order, starting with the originating agent and following the directed graph downstream. Each agent gets its own 60-second answer to Q1 (what tools), Q2 (what write targets), Q3 (what identity). The chain-of-delegation is the chain-of-custody. Incident Commander
55–60 Capture trace IDs across the topology. Every cross-agent message, delegation, and tool call must be exportable with a trace ID that ties prompts, delegations, and tool calls together end-to-end. If the trace IDs are not present or not consistent across agents, this is the highest-priority Playbook 18 hardening item from this incident. Detection engineer

Discipline: in single-agent response, the originating agent is the incident. In multi-agent response, the originating agent is the trigger. The incident is the directed graph of downstream agents that consumed its output before containment landed. The first hour exists to bound that graph.

Containment Options

The framework’s six Kill-Switch Modes apply, with multi-agent adaptations. The most important addition is the orchestrator dimension: the same six modes apply to the orchestrator separately from the agents themselves.

Mode mapping for multi-agent incidents

Mode Multi-agent application Containment scope
M0 Observe Normal multi-agent operation with full trace-ID telemetry Per-agent and per-orchestrator
M1 Read-Only Originating agent suspected; downstream agents may still execute on already-queued instructions Apply to originating agent first; consider fleet-wide if confidence is low
M2 Approvals Required (fleet-wide) The default first multi-agent move. Stops cascade without stopping the workflow Every Tier-2 action across every agent in the topology queued for human approval
M3 Tool Tiering (shared) The harm vector is a tool shared across multiple agents (typical case: a write tool used by both research and execution agents) Disable the shared Tier-2 tool globally. Every agent loses that specific capability.
M3-Delegation Cap (new) The cascade is fueled by deep delegation chains Set max delegation depth (start at 2). Reject deeper chains. Queue or terminate in-flight chains exceeding the cap.
M4 Full Disable (orchestrator) The orchestrator/router itself is suspected, OR cascade is propagating faster than per-agent containment can catch Stop the orchestrator first. This halts further delegation system-wide. Then proceed to per-agent M4 if necessary.
M4 Full Disable (originating agent) Same as single-agent M4, but ordered AFTER orchestrator stop Hard stop on the originating agent. Playbook 07 snapshot-before-revocation sequence applies.
M5 Controlled Re-Enable (topology) Containment validated; staged recovery in dependency order Re-enable from the leaves of the dependency graph inward; the orchestrator is the LAST component re-enabled

The cascade-isolation principle

In multi-agent topologies, the framework’s containment principle becomes: stop propagation, then scope individual agents. Containing one agent while the orchestrator continues delegating allows the cascade to continue through alternate paths. The order is non-negotiable:

  1. Orchestrator (or router) first
  2. Originating agent second
  3. Fleet-wide M2 third
  4. Per-agent scoping fourth

Reversing steps 1 and 2 is the multi-agent equivalent of Playbook 07’s “rotate tokens before snapshotting scopes” failure: the cascade outpaces the response.

Cascade-propagation timing

In production multi-agent topologies, cascade propagation from originating-agent output to downstream-agent execution typically takes 5 to 30 seconds, depending on orchestrator polling cadence and downstream agent execution latency. This is faster than typical human triage. The containment must be automated, not human-mediated, for the first response.

The automation requirement: every Playbook 11 monitoring detection rule that fires on a multi-agent topology must trigger the orchestrator-stop action within 60 seconds of the signal. Human triage starts at minute 1, not minute 0.

Evidence Priorities

For multi-agent incidents, the Minimum Evidence Set A–F extends in two dimensions: per-agent and across-agents.

The per-agent extension

Every agent in the affected topology produces its own A–F evidence set. Capture from each in dependency order. Trace IDs link them.

Code Evidence Type Multi-agent collection requirement
A Prompt and Response Record Per agent. Include system prompts active at incident time AND any agent-to-agent prompts (the output one agent passed to another as input).
B Tool-Call Ledger Per agent. Include attempted and successful calls. The cross-agent linkage lives in trace IDs.
C Retrieval Traces Per agent if RAG is involved. Capture corpus versions per agent if agents retrieve from different corpora.
D Memory Snapshot Per agent. Shared memory between agents is a separate evidence category (see across-agents below).
E Configuration Snapshot Per agent AND per orchestrator. The orchestrator’s delegation rules, routing logic, and inter-agent contracts are configuration.
F Identity Audit-Log Correlation Per agent. The downstream SaaS audit log must be attributable to the specific agent identity, not the orchestrator’s identity.

The across-agents extension

In addition to per-agent A–F, multi-agent incidents require:

Operational requirement: the full per-agent + across-agents evidence set must be exportable within 60 minutes of incident declaration for every agent in the directly affected topology, and within 90 minutes for the second-degree topology (agents that consumed outputs from the directly affected agents). If you cannot, the directed-graph scope of the blast radius is incomplete.

The trace-ID prerequisite

The single most important pre-incident control for multi-agent response is consistent trace IDs across the topology. Without them, multi-agent investigation reverts from data-driven to narrative. The framework’s recommendation:

This is the multi-agent equivalent of the credential-event log schema Playbook 07 specifies. PB07 + PB08 together require two contracts: credential-event logs at the identity layer, trace IDs at the workflow layer.

Recovery Sequence

Multi-agent recovery follows MVO-4 Controlled Re-Enable with four multi-agent-specific gates added.

  1. Re-enable the workflow read-only first. Every agent in the topology comes back in Mode M1 Read-Only. Agents can prepare and propose. They cannot execute.
  2. Validate the dependency graph (multi-agent gate). Confirm the agent topology matches the documented version. Drift between the AI-BOM dependency section and runtime telemetry is itself a finding. Update the AI-BOM before proceeding.
  3. Validate inter-agent contracts (multi-agent gate). Confirm every cross-agent message conforms to the structured handoff contract (typed schema, citations, confidence score, intended-action summary). Reject any handoff containing freeform imperative instructions. This is the load-bearing hardening from this playbook.
  4. Validate bounded delegation (multi-agent gate). Confirm the delegation-depth cap is enforced at the orchestrator. The default cap is 2 hops. Until the framework’s metrics show traceability is at Level 3 (Maturity Roadmap) for this topology, the cap stays at 2.
  5. Replay the incident scenario in a sandboxed harness. Run the originating prompt through the recovered topology with the new contracts and depth cap. Confirm the cascade no longer propagates. If it does, the recovery is incomplete.
  6. Re-enable Tier-2 tools agent by agent, starting with the agent furthest from external systems (typically a research or summarization agent), ending with the agent closest to the system of record (typically an execution agent).
  7. Re-enable the orchestrator (multi-agent gate). The orchestrator is the LAST component re-enabled, with monitoring on trace-ID completeness. Any handoff missing a trace ID triggers an alert per Playbook 11.
  8. Return to M0 Observe only after the topology has carried production traffic for a documented observation window (typically 72 hours) without anomaly.

Approver: CISO or designated Incident Commander. The orchestrator owner is not sufficient. Implementation bias in multi-agent topologies is heightened by the fact that the orchestrator owner usually built the delegation logic and is the least likely to challenge it.

Post-Incident Hardening

Multi-agent hardening organizes around four boundaries. Each has an owner, an artifact, and a measurable acceptance criterion.

Boundary 1: Topology documentation

Boundary 2: Inter-agent contracts

Boundary 3: Bounded delegation

Boundary 4: Telemetry

Common Pitfalls

These are the highest-frequency multi-agent-specific failure modes. Each has been observed often enough to name as a pattern.

Pitfall Why it happens Consequence
Containing one agent while the orchestrator continues delegating Single-agent reflex applied to multi-agent topology Cascade continues through alternate paths. Containment is theatrical.
Treating each agent’s logs as separate incidents Investigation tools are per-agent Chain of custody breaks at every agent boundary. Investigation reverts to narrative.
Allowing freeform agent-to-agent handoffs “Agents are smart; they can figure it out” One prompt injection becomes a sequence of legitimate-looking authorized actions. The most dangerous multi-agent failure mode.
Sharing Tier-2 tool access across multiple agents Convenience during prototyping Blast radius is multiplied by the number of agents with access. The framework’s “concentrated Tier-2” rule (one agent owns one Tier-2 tool) is the counter.
No trace IDs in production Distributed tracing was “next sprint” Investigation reverts to opinion. The 60-minute evidence SLA cannot be met.
Circular dependencies between agents Emergent during prototyping; nobody catches it pre-production Cascades can loop. Detection latency becomes irrelevant when the loop generates its own propagation.
No agent-dependency map in the AI-BOM The topology was built incrementally; documentation was an afterthought Scoping the blast radius under pressure is guesswork. The directed graph that defines the incident’s scope does not exist on paper.
Orchestrator owns the Tier-2 tool, not the agent Vendor framework default The orchestrator’s identity executes the harmful action; downstream attribution to the originating agent is lost.
Shared memory across agents in scope: shared Convenience during prototyping Memory poisoning in one agent becomes context poisoning in every downstream agent. The multi-agent equivalent of cross-tenant memory bleed.
Cascade-propagation timing exceeds detection latency Detection rules tuned for single-agent traffic The detection fires, but downstream agents have already executed. Detection without sub-60-second containment is alerting, not response.

The Question to Carry Forward

If one of your AI agents started producing poisoned output 30 seconds ago, would the downstream agents already be acting on it, or would your cascade-isolation gates have stopped the propagation at the first hop? Answer it for the one multi-agent topology that has Tier-2 write access. The answer reveals whether your multi-agent containment is operational or aspirational.

If the answer is “the downstream agents would already be acting,” PB08 is the work plan. Map the dependency graph this week. Wire one structured handoff contract between two agents that currently exchange freeform text. Set the delegation-depth cap at 2. Run the cascade drill within 30 days. Then move to the next pair of agents in the topology.

That is how multi-agent containment moves from documented to demonstrated. One agent pair, one structured contract, one validated cascade-isolation gate at a time, on a cadence that holds.

Source: AI IR Overlay newsletter, Issue #8, “Multi-Agent Systems Multiply Blast Radius,” by Jacob Ideji. https://www.linkedin.com/in/jacobideji/