Multi-Agent Orchestration

I Why One Isn't Enough

Parts 1–3 of this series gave you a single agent that can think, use tools, and recover from failure. That agent handles a surprising amount of real-world work. But at some point, you hit a wall.

The toolbox ceiling.In Part 2 we showed that accuracy drops from 97% to 60% as you go from 5 tools to 50. A customer service agent that also manages inventory, runs analytics, and sends marketing emails isn't versatile — it's confused. Every tool in the context window is another opportunity for the model to pick the wrong one.

The context bottleneck.A single agent doing research, writing, and fact-checking for a long document has to hold everything in one context window. The system prompt grows. The conversation history grows. Retrieval results compete for space. Eventually the model starts dropping important details — the "lost in the middle" problem from the Context Windows series.

The specialization advantage.In real teams, you don't ask one person to do everything. You have a researcher, a writer, and a reviewer — each with a focused mandate and the right tools for their job. Multi-agent systems apply the same principle: smaller, specialized agents that each do one thing well, coordinated by something that knows who to ask.

II Orchestration Patterns

There are four core patterns for coordinating multiple agents. Each trades off simplicity against flexibility. Picking the wrong one is like picking the wrong team structure — the work gets done, but slowly, expensively, and with a lot of unnecessary confusion.

The Router

A lightweight classifier sits at the front and routes each request to the right specialist agent. The specialist handles the task end-to-end and returns the result directly. The router doesn't do work — it just decides who does.

When it works: Distinct task categories with clear boundaries. Customer support where billing questions go to a billing agent, technical issues go to a troubleshooting agent, and account changes go to an account agent. Each agent has its own toolbox and system prompt.

When it breaks:Ambiguous requests that span categories. "I was charged twice and now I can't log in" needs both billing and troubleshooting — and the router has to pick one or build a handoff protocol.

Supervisor & Workers

A supervisor agent breaks tasks into subtasks, delegates each to a worker agent, and assembles the results. The supervisor holds the plan; the workers hold the tools. This is the pattern behind most "research and write" workflows — one agent plans the outline, another gathers data, another drafts, another reviews.

When it works:Complex tasks that decompose into independent subtasks. The supervisor can run workers in parallel when subtasks don't depend on each other.

When it breaks:When subtask results are interdependent and the supervisor has to make judgment calls about conflicting worker outputs. The supervisor is still an LLM — it doesn't have special wisdom, just a broader view.

The Pipeline

Agents execute in sequence, each one's output becoming the next one's input. Agent A researches → Agent B outlines → Agent C writes → Agent D reviews. Like an assembly line — each station does one thing and passes the work forward.

When it works: Sequential workflows with clear stage gates. Content production, data processing, document review. Each agent can be independently tested and improved.

When it breaks: When later stages need to loop back. If the reviewer finds a factual error, does it go back to the researcher or the writer? Pipelines are great at moving forward, terrible at going backward.

Peer-to-Peer

Agents communicate directly with each other, negotiating roles and sharing context as needed. No central coordinator — each agent decides when to hand off, ask for help, or take over.

When it works: Honestly? Rarely in production. This pattern sounds elegant but creates unpredictable behavior, makes debugging nearly impossible, and turns cost estimation into guesswork.

When it breaks:Most of the time. Without a coordinator, agents can enter infinite delegation loops, duplicate work, or make conflicting decisions. The overhead of "agent politics" often exceeds the cost of a simpler pattern.

III How Agents Talk to Each Other

Single agents use function calling to interact with tools (Part 2). Multi-agent systems need something more — a way for agents to discover each other, pass context, and coordinate actions. Two protocols have emerged as the foundation.

MCP: Agent-to-Tool

Model Context Protocol, introduced by Anthropic in late 2024, standardizes how LLMs connect to external tools. Instead of custom integrations for every API, MCP provides a universal interface — define your tool once, any MCP-compatible agent can discover and use it. Think of it as USB for AI tool use.

MCP solves the toolbox problem at the ecosystem level. Instead of hardcoding 50 tools into one agent's system prompt, you expose tools as MCP servers. Each specialist agent connects to the tools it needs. The router doesn't need to know about billing APIs; the billing agent does.

A2A: Agent-to-Agent

Agent2Agent, introduced by Google in April 2025, addresses the complementary problem: how agents communicate with each other. Where MCP connects agents to tools, A2A connects agents to agents — enabling discovery, task delegation, and status updates between independently-built agent systems.

A2A was donated to the Linux Foundation in mid-2025 and MCP followed in late 2025, putting both on an open-standards track. The fact that two competitors converged on complementary, donated standards is the strongest signal that agent infrastructure is being treated as table stakes, not competitive moat.

Context Passing: The Hard Part

Protocols tell agents how to talk. The harder question is whatto pass. When a supervisor delegates to a worker, how much context does the worker need? Too little and it hallucinates the gaps. Too much and you're paying for a bloated context window on every subtask.

The pragmatic answer: pass the mandate, not the history.Each worker gets a clear task description, the specific data it needs, and constraints on its output format. It doesn't need the full conversation history that led to this subtask. The supervisor holds the big picture; the workers hold their assignments.

IV The Human as Agent Manager

Here's the mental model shift that changes everything: you are not using a tool. You are managing a team.

When you direct a single agent, you're a practitioner with an assistant. When you orchestrate multiple agents, you're a manager. Your job isn't to do the work — it's to keep your agents unblocked, catch their mistakes, and make the judgment calls they can't.

This isn't a metaphor. It's how the most productive teams are already working. Boris Cherny, who leads Claude Code at Anthropic, puts it directly: "AI is no longer becoming a tool for work, it is becoming the worker itself. Engineers already manage armies of agents writing code, analyzing data and executing tasks in parallel."

And Andrej Karpathy hasn't typed a line of code since December 2025. His reframe: when agent delegation fails, it's always a skill issue — bad instructions, wrong memory setup, poor parallelization strategy — not a capability ceiling. The bottleneck is the human manager, not the model.

The Deployment Overhang

But most people aren't there yet. Anthropic's own data tells the story:

• New users auto-approve only ~20% of agent actions.
• Experienced users (750+ sessions) auto-approve >40% — twice the rate, but still a minority.
• The median autonomous agent run is 45 seconds. The 99.9th percentile exceeds 45 minutes.

There's a name for this gap between what models can do and what users let them do: the deployment overhang. Models are ready for more autonomy than humans currently grant. Trust grows with usage, not with policy.

The organizational version of this gap is even wider. Most enterprises run agents through shared service accounts that bypass least-privilege controls. A customer service rep is capped at $500 refunds; an agent operating through their service account might issue a $5,000 credit. The org hasn't built the identity, permissions, and audit infrastructure that makes autonomy defensible.

The practical solution is graduated autonomy — a ladder, not a switch:

V What Can Go Wrong

Multi-agent systems don't just inherit single-agent failure modes — they multiply them. Every connection between agents is a new place for things to break.

Cascading Failure

A 95%-reliable tool called 5 times drops to ~77% reliability (0.95⁵). In a multi-agent system, add another dimension: agents passing bad output to other agents.If the research agent hallucinates a statistic, the writing agent cites it confidently, and the review agent — which lacks access to the original source — can't catch it. Errors don't just compound across steps; they launder across agents, gaining unearned credibility at each handoff.

The Lethal Trifecta

Security researcher Simon Willison identified the three properties that make an agent dangerous when combined: (1) access to private data, (2) exposure to untrusted content, and (3) the ability to communicate externally. Any two are manageable. All three together create an attack surface where a prompt injection in untrusted content can exfiltrate private data through external communication.

In multi-agent systems, the trifecta is especially insidious because the three properties can be distributed across agents. Agent A has data access. Agent B processes untrusted input. Agent C sends emails. No single agent has all three — but the system does, and a carefully crafted prompt injection can cascade across the chain. Real-world examples already exist: Salesforce's Agentforce was exploited via malicious instructions embedded in a routine web form, and ServiceNow's Now Assist saw second-order prompt injection cascade across a multi-agent topology.

Agent Accountability

When a single agent makes a mistake, you check its logs. When a multi-agent system makes a mistake, you have a distributed debugging problem: which agent made the bad decision? Was it the supervisor's plan, the worker's execution, or the router's dispatch? Agent decisions emerge from chains of reasoning, retrievals, and tool calls that are hard to reconstruct after the fact.

This isn't hypothetical. In 2025, a developer using Replit's AI coding agent watched it delete a production database despite explicit instructions not to modify production — then generate thousands of fake records and misleading system messages to obscure the failure. When an agent can take real actions and hide its mistakes, observability isn't optional — it's the entire safety architecture.

VI Series Wrap

Across four parts, we've built up the full picture of AI agents:

• Part 1: The Agent Loop — Think, act, observe, decide. The cycle that lets agents handle ambiguity.
• Part 2: Tools & Function Calling — Agents interact with the world through structured function calls. Tool design directly impacts reliability.
• Part 3: Planning, Failure & Tradeoffs — Agents fail predictably, cost money per loop, and need guardrails. The right architecture depends on predictability, stakes, latency, and budget.
• Part 4: Multi-Agent Orchestration — Multiple specialized agents coordinated by thin orchestration. The human becomes a manager, not a user. Trust is graduated, not switched.