Context Isolation in Multi-Agent Systems: Why Shared State Breaks Agents

The most common multi-agent failure mode is context contamination — one agent's state leaking into another's reasoning. Clean architecture requires explicit boundaries: which agents share context, which fork it, and how the orchestrator stays clean while workers see what they need.

The most common multi-agent failure mode does not look like a bug. It looks like inconsistent, hard-to-reproduce behaviour where agents make decisions that seem correct in isolation but are wrong in the context of the overall task. The root cause is almost always context contamination.

What context contamination is

In a multi-agent system, each agent has a context window. Context contamination occurs when content from one agent's working context — intermediate reasoning, tool outputs, partial results — leaks into another agent's context in ways that were not intended by the architecture. The contaminated agent then reasons from that content as if it were ground truth.

A concrete example: an orchestrator agent delegates a research subtask to a worker. The worker returns its full reasoning chain along with the result. The orchestrator includes this reasoning chain in the next worker's context as 'background'. The second worker now treats the first worker's unverified intermediate reasoning as established fact. This propagates errors across the system in ways that are extremely difficult to debug.

The three isolation boundaries

• Orchestrator isolation: the orchestrator's context should contain task state and routing logic, not worker reasoning. Workers return structured results, not raw thoughts. The orchestrator synthesises results; it does not inherit reasoning.
• Worker isolation: each worker spawned for a subtask gets a clean context containing only: the task description, necessary background from the shared knowledge store, and relevant tool schemas. Prior worker outputs are summarised, not passed verbatim.
• Shared state isolation: facts that need to persist across agents live in an explicit shared state object with defined read/write semantics — not in free-form context passage. Any agent can read from shared state; only designated agents can write to it.

Forked vs shared context

Two patterns for passing context between agents: forking (the receiving agent gets a copy of the sender's context at fork time, then works independently) and shared (multiple agents read from and write to a common context store). Forked context prevents contamination but loses the ability to share live updates. Shared context enables coordination but requires explicit conflict resolution when multiple agents write.

The default should be forked context with explicit shared state for coordination data. Most multi-agent systems do not need live context sharing between workers — they need workers to see the same initial state, work independently, and report structured results back to the orchestrator.

Preventing infinite loops

Context isolation also prevents the agent equivalent of a stack overflow: infinite delegation loops, where agent A delegates to agent B which delegates back to agent A. Prevention requires explicit loop detection in the orchestrator (track delegation depth and abort above a threshold) and clear scope boundaries in each agent's context file (what this agent can and cannot delegate).

Set a maximum delegation depth (typically 3-4 levels) enforced by the orchestrator. Log every delegation with the full agent path. When a loop is detected, return an explicit failure to the user rather than silently spinning — silent spinning is how agent systems consume 100x their token budget without producing output.

• Anthropic — Multi-Agent Systems