So far this semester your agents have mostly worked alone: one system prompt, one tool loop, one conversation. This week we scale up to teams of agents that divide labor, and we look hard at the plumbing that makes — or breaks — that division of labor.
The most common way to build a multi-agent system today is the supervisor pattern. A top-level "manager" agent receives the user's request, breaks it into subtasks, and routes each subtask to a specialized sub-agent — a research agent, a coding agent, a math agent, whatever the domain calls for. The manager then collects the results and assembles the final answer. This pattern has the most native framework support of any multi-agent architecture right now: LangGraph's langgraph-supervisor library, the OpenAI Agents SDK, and Microsoft's Agent Framework all ship first-class primitives for it. There are two flavors of "manager stays in charge":
on_handoff hooks let you observe and log every control transfer as it happens — which matters enormously for debugging and audit trails.The distinction matters operationally: tool-calls keep a single point of accountability (the manager), while handoffs distribute accountability across whichever agent currently holds the conversation. Neither is "better" — they're suited to different situations, which we'll return to below.
Anthropic's Claude Agent SDK takes a related but distinct approach: subagents. An orchestrator spawns a subagent with its own system prompt, its own restricted tool access (a subagent doing research doesn't need shell access; one doing file edits doesn't need web search), and its own isolated context window. Critically, the orchestrator receives back only the final result — not the subagent's intermediate reasoning or tool-call trace. This isolation is what enables genuinely parallel multi-agent work: three subagents can run simultaneously, each in its own context, without polluting each other's — or the orchestrator's — token budget.
Everything above assumes agents built in the same framework. But what happens when your supervisor is built with LangGraph and needs to hand work to a specialist agent built by another team, in another framework, maybe another company? That's the problem A2A (Agent2Agent) solves. Google introduced A2A in April 2025, built on open web standards: HTTP for transport, Server-Sent Events (SSE) for streaming updates, and JSON-RPC 2.0 for the request/response envelope. Two objects do the heavy lifting:
The key design goal is that agents can hand off work without exposing internal logic or memory — A2A is a capability-and-task contract at the boundary, not a shared-memory integration. A2A's governance has matured quickly: it's Apache 2.0 licensed, backed by more than 50 partners, and in August 2025 IBM and Cisco's competing ACP (Agent Communication Protocol) merged into A2A rather than remaining a rival standard. In December 2025, the Linux Foundation formalized stewardship of A2A by launching the Agentic AI Foundation (AAIF), which also now stewards AGENTS.md — a sign that cross-vendor agent interoperability is consolidating around a small number of shared, vendor-neutral specs rather than fragmenting.
Here's the number that should live in the back of your mind all week: reliability compounds across chained agents. If each agent in a chain is independently correct 90% of the time, a 3-agent chain that requires every step to succeed is correct roughly 0.9³ ≈ 73% of the time — before you've added any communication overhead between agents. Every additional hop is a new chance to drop context, misinterpret a briefing, or introduce a formatting error the next agent can't parse.
| Chain length | Per-agent success rate | Approx. end-to-end success |
|---|---|---|
| 1 agent | 90% | 90% |
| 2 agents | 90% | \~81% |
| 3 agents | 90% | \~73% |
| 5 agents | 90% | \~59% |
This table is the single strongest argument for disciplined delegation: add an agent only when a task genuinely decomposes into independent specialties, not because "more agents" sounds more sophisticated.
"More agents make the system smarter." Not by default. Adding agents without disciplined delegation increases communication overhead and — as the table above shows — multiplies individual error rates across the chain. Add an agent only when the task truly splits into independent sub-problems that benefit from specialization (different tools, different context, different expertise) — not as a default architecture choice. "Handing off between agents just works." Handoffs typically rely on implicit, language-based context — a natural-language briefing passed from one agent to the next — rather than a typed, validated contract. If that briefing is ambiguous, the downstream agent doesn't raise an error; it simply proceeds incorrectly, often confidently. This is why handoff loops (agent A hands to B, which hands back to A) need explicit guard conditions — a max-hop counter, a required-field check, or an escalation rule — or you risk silent infinite loops or silently wrong answers. "One orchestration pattern fits all multi-agent systems." Centralized patterns (supervisor) give you tighter control and a single, auditable point of decision-making — but that single point is also a single point of failure. Decentralized patterns (swarms, peer handoffs) give you resilience — no one node's failure halts the system — but are harder to observe and debug, since control can pass through many peers before you see the outcome. The right choice comes from the workload: does it need centralized auditability and control (choose supervisor), or does it need to keep functioning even if one agent misbehaves or goes offline (choose decentralized)? There is no universally correct default.