Orchestration Patterns

Here is the simplest way to think about it: a multi-agent system is just a group of agents plus a rule for who goes next and how they share what they know. That rule — the topology — is the whole game. Get it right and specialization pays off; get it wrong and you get loops, dropped work, and a bill three times bigger than a single agent. The agents themselves are the easy part; the wiring between them is where systems succeed or fail.

As of 2026 the field has converged on five canonical topologies:

1. Supervisor / orchestrator-worker — one boss delegates to workers and synthesizes results.
2. Hierarchical teams — supervisors of supervisors; nested delegation for large systems.
3. Sequential pipeline — an assembly line; each stage feeds the next, no boss.
4. Network / swarm / handoff — peers pass control directly to one another.
5. Blackboard / shared-state — agents read and write a common workspace instead of talking directly.

The most important thing to internalize early: these are composable building blocks, not a forced choice. Real production systems are almost always hybrids — a supervisor at the top routing into pipeline sub-workflows, or hierarchical routing that bottoms out in a swarm. Learn each shape in isolation first, then mix.

Picture a team lead handing out assignments. A single orchestrator agent receives the task, breaks it into pieces, hands each piece to a specialized worker, collects what comes back, and writes the final answer. The defining rule: workers never talk to each other — every bit of coordination flows through the supervisor, like a hub with spokes. This is the pattern Anthropic used for its multi-agent research system and the one most frameworks ship first.

Why reach for it: routing decisions are made by a single agent with full context, and the centralized flow is auditable — you can see exactly who was asked to do what. It's the natural fit for compliance environments and tasks with clear, dynamic decomposition.

The costs are real. The supervisor is a single point of failure: if it hallucinates a bad plan, the error cascades to every worker. Every step also pays for a routing LLM call (the orchestrator bottleneck), and naive sequential delegation adds latency. The classic bug is a routing loop — the supervisor keeps re-selecting the same worker without making progress.

# LangGraph: the supervisor pattern is a first-class package
from langgraph_supervisor import create_supervisor
from langgraph.prebuilt import create_react_agent

researcher = create_react_agent(model, tools=[web_search], name="researcher")
coder = create_react_agent(model, tools=[run_python], name="coder")

app = create_supervisor(
    agents=[researcher, coder],
    model=model,
    prompt="Route research to 'researcher' and code to 'coder'. Synthesize their outputs.",
).compile()

Now scale that team lead up to a whole company. When one supervisor would drown — imagine 50 specialized workers all reporting to a single agent — you nest the structure. A root agent delegates to sub-supervisors, each of which manages its own pool of leaf workers. This is not simply running several supervisors side by side; the defining feature is the nested delegation chain: root → sub-supervisor → worker.

Hierarchy is the only topology that scales cleanly to large enterprise deployments (50+ agents). It also mirrors how real problems decompose: a research org has departments, departments have teams, teams have specialists. Each level keeps its own routing decision small and in-context.

Frameworks implement this by treating a whole sub-team as a single callable — the parent just "calls the team" the way it would call any tool. In Google ADK, a parent LlmAgent calls a sub-agent workflow through AgentTool, so the sub-team looks like an ordinary function call. CrewAI bakes hierarchy in at the framework level: a top-level planner decomposes a goal into sub-goals that crews execute. Microsoft's AutoGen lineage (now folding into the Microsoft Agent Framework) used a GroupChat with a hierarchical manager.

# Google ADK: a parent agent calls sub-teams as tools
from google.adk.agents import LlmAgent
from google.adk.tools.agent_tool import AgentTool

research_team = LlmAgent(name="research_lead", sub_agents=[scout, analyst])
writing_team = LlmAgent(name="writing_lead", sub_agents=[drafter, editor])

root = LlmAgent(
    name="director",
    tools=[AgentTool(research_team), AgentTool(writing_team)],
)

A pipeline is an assembly line. Each agent does one job, then passes its work to the next station down the line. Agents run in a strict, fixed order; each stage transforms its input and hands the output to the next. The most important and most-missed fact: there is no orchestrator. Stage N receives stage N−1's output and passes to stage N+1. No agent decides the routing — the wiring is the routing. That's the key differentiator from the supervisor, where a central agent chooses each next step.

This makes pipelines the easiest pattern to reason about. Each stage is independently debuggable and profileable, and you can put a cheap, fast model on the easy stages and a strong model only where it's needed. The trade-offs are equally clear: no parallelism, total latency is the sum of every stage, and a failure in any stage stalls everything downstream. Pipelines shine for linear, deterministic work: ETL, document processing (extract → summarize → format), and CI/CD-style flows.

# Google ADK ships SequentialAgent as a native primitive
from google.adk.agents import SequentialAgent

pipeline = SequentialAgent(
    name="doc_pipeline",
    sub_agents=[extractor, summarizer, formatter],  # run in this exact order
)

In LangGraph the same shape is a directed graph with sequential edges (extract -> summarize -> format -> END). Either way, you are choosing determinism and debuggability over flexibility and speed.

Now throw away the boss entirely. Instead of routing through a center, agents hand control to each other directly — like a phone call being transferred between departments. A billing agent that realizes a question is really about refunds simply hands off to the refunds agent, which takes over the conversation. Coordination is peer-to-peer; there is no hub.

OpenAI's experimental Swarm library pioneered the handoff primitive — but note: Swarm is now archived/educational-only. The production successor is the OpenAI Agents SDK (March 2025), whose built-in primitives are Handoffs, Guardrails, and Tracing. On a handoff the system prompt switches to the new agent's, but conversation history is preserved — the receiving agent picks up the live thread rather than starting cold. LangGraph implements the same idea with Command objects (Command(goto=..., graph=Command.PARENT)) and ships a langgraph-swarm package.

The appeal is latency and context continuity: handoffs are fast — no intermediary routing call — and the receiving agent inherits the live conversation. LangChain's benchmarks found the swarm can match or slightly exceed the supervisor on task accuracy for customer-service-style workloads because sub-agents respond to users directly without a translation step. The trade-offs are harder auditing and the signature failure mode: ping-pong loops, where two agents bounce control back and forth. The standard mitigation is a hard hop limit (e.g., max 3 handoffs tracked in state).

# OpenAI Agents SDK: declare which agents A can hand off to
from agents import Agent

refunds = Agent(name="Refunds", instructions="Handle refund requests.")
billing = Agent(
    name="Billing",
    instructions="Handle billing. Hand off refund questions.",
    handoffs=[refunds],
)

Imagine specialists gathered around a shared whiteboard. Nobody speaks to anyone directly; instead each person reads what's on the board and adds their own contribution when they have something useful. That's the blackboard pattern: agents don't talk to each other at all — they read from and write to a shared workspace (the blackboard), and a control component decides which agent acts next. Coordination is emergent: each specialist watches the shared state, contributes when it can, and the solution accretes. This is ideal when agents are loosely coupled and you don't know the completion order up front.

Don't confuse this with broadcasting full conversation history to everyone (the GroupChat/AutoGen approach, where a 4-agent, 5-round debate costs 20+ LLM calls). A proper blackboard is a structured store of named outputs, not a transcript. Google ADK uses session.state as the whiteboard, and the critical discipline is that each agent writes to a unique output_key — that's what prevents the classic blackboard bug: race conditions, where two agents clobber the same slot. Anthropic's research system used a shared task queue plus a completion registry in exactly this spirit, which also makes the workflow fault-tolerant: an agent can crash and another can pick up unfinished items.

# Google ADK: agents share session.state; unique output keys avoid races
from google.adk.agents import LlmAgent

researcher = LlmAgent(name="researcher", output_key="research_notes")
critic     = LlmAgent(name="critic",     output_key="critique")
writer     = LlmAgent(name="writer",     output_key="final_draft")
# Each reads prior keys from state; none overwrites another's slot.

The first rule is counterintuitive: don't pick a pattern yet. Start with the cheapest thing that could work. Anthropic's explicit guidance is to optimize a single agent first, and move to multi-agent only when evaluation shows that single agent plateauing. Multi-agent workflow adoption accelerated sharply through 2025 — and many deployments added coordination cost with no measurable benefit. Don't be that deployment.

When you do go multi-agent, match the pattern to the shape of the problem:

And compose freely: a supervisor on top with pipeline sub-workflows, or hierarchical routing that bottoms out in a swarm. Whatever you pick, give each subagent a clear objective, an output format, tool guidance, and explicit task boundaries — without that, agents duplicate work or leave gaps.