Multi-Agent AI Systems: Architecture & Failure Modes

Multi-agent AI systems work when tasks split into genuinely separate subtasks with different tools or models. The architecture introduces a failure mode that single-agent systems do not face in the same way: hallucination propagation between agents, where one bad output becomes trusted input for every downstream agent in the pipeline.

Why Specialization Drives Multi-Agent Adoption

The case for multi-agent systems shows up first as a tool-selection problem. Load a single agent with twelve tools (SQL execution, vector search, calculator, file I/O, HTTP, email, Slack, GitHub, Jira, calendar, code interpreter, browser) and it starts choosing the wrong tool as the menu grows. The model has to weigh more options against an ambiguous prompt, and selection accuracy degrades faster than capability scales. Split the same workload into a SQL agent, a synthesis agent, and a delivery agent and you shrink each agent's tool surface, removing the ambiguity.

The data backs this up. Among 86 production or pilot systems filtered from 306 survey responses, the MAP study found that 68% execute at most 10 steps before human intervention. Teams shipping these systems keep them small because each additional autonomous step compounds the chance of a silent failure you cannot trace.

The takeaway for architecture decisions: add agents to shrink each agent's responsibility. The five-agent autonomous pipelines that dominate conference demos rarely survive contact with production data because the design lacks meaningful specialization between roles.

Three Core Architectures: Pipeline, Hierarchical, Peer-to-Peer

Multi-agent architectures fall into three patterns, each with distinct coordination costs and failure characteristics.

Pipeline is the pattern most builders reach for first because linear workflows are easy to reason about. The risk concentrates at the boundaries: if Agent A produces a bad intermediate value, every downstream stage inherits it as trusted input. Pipelines work for creative or exploratory tasks where downstream stages can tolerate fuzzy inputs, and they break in financial extraction, legal summarization, or anything else where one wrong number contaminates the final output.

Hierarchical orchestration adds a coordinator that delegates to specialists, fitting tasks that need different tools or models per subtask. The cost shows up as latency: each delegation adds a round trip, and the orchestrator becomes the bottleneck. Framework choice alone creates latency differences for the same task. Use hierarchical orchestration when subtasks genuinely diverge in tool requirements; skip it when the "specialists" all use the same tools and model. Intent runs this pattern through a Coordinator that drafts a spec, fans out work to Implementor agents in parallel waves, and routes results to a Verifier agent for final checks.

Peer-to-peer is the least predictable pattern. Without a central coordinator, common failure modes include agents converging on a hallucinated consensus (each reinforces the other's wrong assumption), infinite negotiation loops, and emergent behavior that only appears at the system level. I dug into a simulation study that ran 55 multi-agent scenarios and the results were counterintuitive: agent populations composed of only 10% honest agents achieved 74% higher collective welfare than populations of 100% honest agents. Full honesty created systemic fragility because every agent trusted every other agent's output without skepticism, and a single bad signal cascaded unchecked. That finding changed how I think about peer-to-peer design: adversarial robustness matters more than cooperative accuracy alone.

Use peer-to-peer for adversarial testing, simulation, or red-teaming, where unpredictability is the point. Avoid it for production workloads with a defined output contract.

When NOT to Use Multi-Agent

Multi-agent is overkill more often than necessary. Skip the architecture entirely when:

• The task is single-step or tightly coupled. Drafting an email, classifying a ticket, or summarizing a document does not benefit from orchestration. A single LLM call is faster, cheaper, and easier to debug.
• Subtasks share most of their context. If agents pass the same context back and forth with minor transformations, the orchestration layer adds latency without adding specialization.
• You lack observability tooling. Multi-agent systems without inter-agent logging are unmaintainable in production. If logging, validation, and tracing are absent, ship a single agent first.
• Cost or latency is the binding constraint. Each agent adds a model call. For real-time UX or high-throughput workloads, a single well-prompted call usually wins.
• The pipeline is a prototype. Optimize for iteration speed first. Move to multi-agent only after you understand the workload's seams.

For a deeper breakdown of single-agent vs. multi-agent tradeoffs, the parallelizability test walks through the decision criteria.

Hallucination Propagation: How Errors Compound Across Handoffs

Hallucination propagation is the structural failure mode specific to multi-agent systems. When a single agent hallucinates, a human sees the output and can catch it. In a multi-agent pipeline, the error passes downstream as trusted input, invisible by default, and the error surface grows with every agent added to the chain.

I watched this happen while testing an AI-to-AI monitoring setup on a finance pipeline: one agent hallucinated a 5x cost difference, and the error propagated through three downstream agents before reaching output. The mistake reached production because no one was monitoring the AI-to-AI channel.

A Concrete Propagation Example

The pattern from that finance pipeline generalizes. The same dynamic plays out in a document extraction workflow:

1. Extraction agent reads a quarterly report and outputs revenue: $4.2M (correct value was $4.2B; the agent dropped the unit).
2. Calculation agent receives $4.2M as authoritative input and computes year-over-year growth as -98% against last year's $3.9B.
3. Synthesis agent receives the -98% figure and writes a narrative explaining the catastrophic decline.
4. Review agent validates the narrative against the calculation, finds them internally consistent, and approves.

Every downstream agent did its job correctly given the input. The error survived four handoffs because no agent checked the upstream output against an external source of truth. Catching the mistake required comparing the narrative to the original quarterly report, which the review agent never did.

Detection Signals to Build Into the Pipeline

Pipelines instrumented with these checks catch propagation before output reaches a human:

• Schema and range validation at each handoff. A revenue field expected in billions that arrives in millions should fail before the next agent reads it.
• Cross-agent consistency checks. If two downstream agents reference the same upstream value with different magnitudes, flag the discrepancy.
• Confidence scoring on extracted values. Downstream agents should refuse low-confidence inputs without human review.
• Source-grounded re-verification at terminal stages. The last agent should re-check key claims against the original input rather than against intermediate agent outputs.

Production Use Cases Where Multi-Agent Pays Off

The production deployments with the strongest economics share a pattern: genuine task decomposition, a high manual cost baseline, different tool requirements per subtask, and clear stage boundaries.

Security Testing

Penetration testing decomposes cleanly. Reconnaissance, vulnerability scanning, exploit verification, and reporting are genuinely independent subtasks with different tool requirements. The cost baseline is what makes the architecture worth the complexity: I have seen teams paying $8,000-$15,000 per engagement for manual pen-testing, or $32,000-$60,000 per year at quarterly SOC 2 cadence. Multi-agent pipelines reduce that cost while maintaining the stage boundaries that make results auditable. Intent's customizable specialist personas suit this kind of role split, with custom Implementor agents handling each phase while a Verifier checks findings against the spec.

Document Extraction and Synthesis

Long-form document workflows (financial filings, legal contracts, medical records) split into extraction, normalization, calculation, and synthesis stages. Each stage uses a different toolchain, from PDF parsers and schema validators to computation libraries and narrative generators. The handoff points are where I have seen propagation risk concentrate most, which is why this workload only succeeds with handoff validation built in.

Video Production

Creative content pipelines follow the same decomposition logic when they mirror a real production workflow. I evaluated a multi-agent video creation system that modeled its pipeline on actual film production roles: a director agent breaks a story concept into a shot list, separate agents handle visual generation, audio, and assembly. The cost baseline that justifies the orchestration overhead is $500+ per 60-second video with freelancers and 3-5 hours of turnaround.

Cost-Optimized Model Routing

A common pattern routes pipeline stages to different models based on complexity: a small, fast model for structured tool calls at the data layer, a frontier reasoning model for synthesis. The savings come from avoiding frontier-model token rates for routine extraction. The tradeoff is operational complexity: model routing only saves money if you measure per-agent token consumption and can attribute cost back to each stage.

Intent supports model routing through BYOA, working natively with Augment agents and also supporting Claude Code, Codex, and OpenCode. Teams can mix models per task type so each role in a Coordinator/Implementor/Verifier setup runs on the model that fits its subtask.

Framework Comparison: What Each Actually Does (and Doesn't)

Mainstream multi-agent frameworks handle orchestration, tool use, and agent communication. None of them ship with inter-agent message correctness validation by default; that work falls to you. I tested every major framework looking for an answer to one question: did this agent send the right message, to the right recipient, at the right point in the protocol? None of them answer it. Even teams attempting formal verification of multi-agent protocols have found the gap is architectural rather than incidental: these frameworks define message format but leave message correctness undefined, so no amount of configuration closes it. The comparison below covers orchestration pattern, fit, and the validation gap each framework leaves open.

Beyond the validation gap, the meaningful tradeoffs are maturity, debugging tooling, and lock-in. LangGraph has the strongest production controls but the steepest learning curve. CrewAI ships fast but hides what happens between agents. OpenAI Agents SDK is the lightest option and the heaviest source of lock-in. Google ADK standardizes interop but is the youngest and least battle-tested.

For production systems, the validation gap means building an inter-agent monitoring layer or accepting that hallucination propagation goes undetected until output reaches a human. Intent closes the gap by placing a Verifier agent at handoff points and using the living spec as the correctness standard that frameworks leave undefined. If you are pairing one of these frameworks with spec-driven coordination, this guide on running a multi-agent coding workspace covers the patterns.

Context Drift: The Difference Between Factual and Alignment Drift

The most underestimated problem in long-running multi-agent sessions is that two different things drift, and most fixes only address one. Factual drift happens when an agent forgets what was decided or built. Alignment drift happens when an agent forgets why.

I hit factual drift while working with persistent memory for MCP-based coding agents. In long sessions, earlier context gets compressed or dropped, and the agent "forgets" decisions made hours ago because the context window silently pushed them out, even with the session still active. In a multi-agent system, this compounds: Agent C at hour three operates on assumptions that Agent A established at hour one, while neither agent retains those assumptions in active context. Persistent storage (SQLite or an equivalent memory layer) fixes factual drift by storing decisions outside the context window.

Alignment drift is harder. Agents may remember every decision and still drift away from the original goal because each local choice reasonably extends the previous one, while the cumulative path diverges from the spec. A fact store cannot detect this; the facts stay correct while the trajectory goes wrong.

Spec-driven development addresses alignment drift specifically. When an orchestrator and its sub-agents share a living specification, the spec acts as the goal state every agent re-reads. Intent treats the living spec as the single source of truth: the spec updates when agents complete work, changes propagate to all active agents, and a Verifier checks completed work against the spec before tasks close.

What to Monitor Before Going to Production

Deploying a multi-agent system without inter-agent monitoring is the equivalent of deploying a microservices architecture without distributed tracing. The monitoring checklist I work from covers five layers:

1. Inter-agent message logging. Capture every message between agents, including content, timestamp, sender, and recipient. This is the channel where hallucination propagation occurs, and frameworks do not log it by default.
2. Output validation at each handoff. Run schema checks, range checks, and consistency checks on each agent's output before the next agent consumes it. This is where cascading errors get caught.
3. Context window utilization tracking. Monitor how much of each agent's context window is consumed and when earlier context drops out. Context dilution is silent by default.
4. End-to-end latency per agent. Tool execution dominates agent latency, with tool calls accounting for 30-85% of First Token Rendered latency in agentic pipelines. Track per-agent latency to find where time goes.
5. Cost per agent per run. Model routing only saves money if you measure it. Track token consumption per agent to validate the routing strategy.

Of these five, only per-agent latency is partially implemented in mainstream frameworks. The other four fall to you. Intent provides the workspace counterpart to this checklist: a Verifier agent that validates each handoff against the living spec, resumable sessions that preserve workspace state across context window resets, and per-agent visibility into work in progress.

Build Inter-Agent Monitoring Before Your First Production Deploy

Start with the architecture question that matters most: does the task decompose into genuinely independent subtasks with different requirements? If yes, use specialized agents and instrument the AI-to-AI channel before launch. If no, prefer a single LLM call with strong context and fewer moving parts.

FAQ

Related

1. 9 Best AI Coding Agent Desktop Apps in 2026 (Ranked by Real-World Performance)
2. 7 Best AI Agent Observability Tools for Coding Teams in 2026
3. 5 Best Agentic Development Environments for Enterprise Teams in 2026
4. 6 Best Spec-Driven Development Tools for AI Coding in 2026
5. 8 Best AI Coding Assistants and Their Best Use Cases