The shared context trap
When building multi-agent systems, the natural instinct is to share context between agents. A drafting agent, a risk agent, and a compliance agent all working on the same contract — why wouldn't they share the same understanding?
The answer: because sharing context means sharing mistakes.
Measuring context bleed
We ran an experiment with three agents on a pipeline: Extractor → Analyzer → Drafter. In the shared-context condition, each agent appended its output to a growing context window. In the isolated condition, each agent received only its specific input and returned a structured result.
The results were stark:
| Metric | Shared Context | Isolated Context |
|---|---|---|
| Error rate | 7.8% | 1.2% |
| Cross-agent contamination | 12.3% | 0% |
| Average latency | 2.1s | 1.8s |
How we isolate
Each agent runs in a separate Claude API call with:
- A scoped system prompt defining its exact responsibility
- Only the data fields it needs (not the full document)
- Structured output schema via tools
- Independent rate limiting and error handling
The orchestration layer — a lightweight Node.js process — routes data between agents without sharing raw context windows. Each agent is a pure function: input → output, with no side effects.
Why this matters for high-stakes AI
High-stakes domains have a property we call "contamination sensitivity": a misinterpretation in one section can cascade into errors in every downstream analysis. By isolating each agent's context, we prevent that cascade.