7 Patterns in Multi-Agent Systems
Seven distinct architectural patterns for orchestrating multiple specialized agents — Parallel, Sequential, Loop, Router, Aggregator, Network, and Hierarchical — each suited to a different workflow shape.
Formulate task objective
Task: Fetch active users and generate database summary report.
7 Patterns in Multi-Agent Systems
Structural blueprints for coordinating multiple agents — pick based on whether subtasks are independent, sequential, iterative, or need consensus.
| Structure | Best for | |
|---|---|---|
| Parallel | Task splits to multiple agents at once, results merge at the end | Independent subtasks that don't depend on each other |
| Sequential | A straight chain: Agent A → Agent B → Agent C | Pipelines where each stage depends on the previous output |
| Loop | An agent repeats until a 'good enough?' check passes | Iterative refinement tasks (drafting, self-correction) |
| Router | A router agent classifies and dispatches to one specialist agent | Tasks that fall into distinct, mutually-exclusive categories |
| Aggregator | Multiple agents produce independent opinions, merged into a consensus | Tasks that benefit from multiple perspectives |
| Network | Agents connect bidirectionally with no single center | Highly collaborative, decentralized problem-solving |
| Hierarchical | A planner agent delegates to workers, who report back up | Complex tasks needing decomposition + progress tracking |
▶📚 Prerequisites(1)
🎓 Learning objectives
- •Identify which of the 7 multi-agent patterns fits a given workflow shape
- •Explain the friction-minimization design principle for choosing a multi-agent pattern
- •Distinguish Router (single dispatcher) from Aggregator (fan-in consensus) and Hierarchical (manager-worker) patterns
- •Design a multi-agent system that avoids duplicate work and unclear turn-taking
What is it?
The 7 Patterns in Multi-Agent Systems are named architectural blueprints for how multiple specialized agents can be wired together to collaborate, replacing the earlier era of 'monolithic agents' — single LLMs stuffed with an ever-growing system prompt trying to do everything. The seven patterns are: Parallel (agents work independently on subtasks, outputs merge), Sequential (agents form a pipeline, each adding value step by step), Loop (an agent iteratively refines its own output), Router (a controller dispatches tasks to the right specialist), Aggregator (multiple agents each produce a partial opinion, one agent combines them), Network (agents talk freely with no fixed hierarchy), and Hierarchical (a top-level planner delegates to and supervises workers). Each pattern suits a different shape of workflow, and real systems often combine more than one.
Why it exists
Monolithic agents — a single LLM with one giant system prompt trying to handle search, analysis, writing, and review all at once — didn't scale. As tasks grew more complex, teams realized that multiple specialized agents, each with a narrower role and a tighter system prompt, collaborate more reliably and are easier to debug and improve independently than one agent trying to do everything. These 7 patterns exist to give engineers a fixed vocabulary of proven collaboration shapes, so that when it's time to move from a single agent to multiple, you're choosing from known, well-understood topologies instead of inventing an ad hoc structure from scratch.
Problem it solves
Multi-agent patterns solve the 'kitchen-sink agent' problem — a single agent whose system prompt has grown to thousands of words trying to cover every possible task, becoming unreliable, slow, and impossible to improve without breaking something else. They also solve concrete workflow-shape problems: Parallel reduces latency in high-throughput pipelines; Sequential enforces quality gates between pipeline stages; Loop enables iterative self-improvement; Router avoids overloading a single agent with domains it's not specialized in; Aggregator combines multiple independent opinions into a more reliable consensus; Network enables emergent, free-form collective behavior; Hierarchical provides clear accountability and progress tracking for complex multi-step projects.
Intuition
Think of each pattern as a different team structure at a company. Parallel is like assigning three people to research three different topics simultaneously, then combining their reports. Sequential is like an assembly line — one person writes a draft, the next edits it, the next publishes it. Loop is like a writer repeatedly revising their own draft against feedback until it's good enough. Router is like a receptionist directing visitors to the right department. Aggregator is like a panel of judges each scoring independently, then averaging their scores. Network is like an open-floor brainstorming session with no assigned leader. Hierarchical is like a project manager breaking a big project into tasks and assigning them to team members, then reviewing their work.
Analogy
It's like the difference between organizing a group project as 'everyone does their own slice and we staple it together at the end' (Parallel), 'each person builds on the previous person's work' (Sequential), 'one person keeps redrafting until the group is happy' (Loop), 'a team lead decides who handles what based on expertise' (Router), 'everyone submits their own answer and we go with the majority' (Aggregator), 'the whole group just chats freely and ideas emerge' (Network), or 'a manager breaks the project into tasks and checks in on each person's progress' (Hierarchical).
Technical explanation
Each pattern implies a different control-flow and data-flow structure.
Parallel: subtasks are dispatched concurrently (e.g., via asyncio.gather or a task queue), each agent operates on an independent slice of the input with no shared state during execution, and a merge step combines outputs — best for reducing wall-clock latency in high-throughput pipelines like document parsing or API orchestration.
Sequential: output of agent N becomes the input of agent N+1, forming a linear pipeline — used in workflow automation, ETL chains, and multi-step reasoning where each stage adds value (e.g., one agent generates code, another reviews it, a third deploys it).
Loop: a single agent's output feeds back into its own input along with an evaluation signal, repeating until a stopping criterion (quality threshold or max iterations) is met — used for proofreading, report generation, or creative iteration.
Router: a controller agent classifies the incoming task and dispatches it to exactly one of several specialist agents — the foundation of context-aware agent routing seen in MCP/A2A-style frameworks (e.g., finance queries route to a FinAgent, legal queries to a LawAgent).
Aggregator: multiple agents independently process the same input and produce partial results/opinions; a final aggregating step combines them into one output — common in RAG retrieval fusion and voting/ensemble systems.
Network: agents communicate freely with no fixed hierarchy or turn order, sharing context dynamically — used in simulations, multi-agent games, and collective reasoning systems where free-form emergent behavior is the goal.
Hierarchical: a top-level planner agent decomposes a task, delegates subtasks to worker agents, tracks their progress, and makes final calls — exactly mirroring a manager-and-team structure, and the most common pattern for complex, multi-step real-world projects.
Architecture
A multi-agent system built on these patterns typically has: a coordinator component (the Router, Aggregator, or Hierarchical Planner — absent in pure Parallel/Sequential/Network setups), a set of specialist agents each with a narrow, well-scoped system prompt, a communication/message-passing layer (direct function calls for simple setups, a message queue or shared state store for more complex ones), and — critically, per the design principle emphasized in the source — an explicit design for turn-taking and work-deduplication so that no two agents redundantly perform the same subtask and every agent knows exactly when to act and when to wait.
Workflow
- Determine whether the task actually needs multiple agents at all, or whether a single well-scoped agent (with tools) would suffice — always confirm this before reaching for a multi-agent pattern.
- Map the task's natural shape onto one of the 7 patterns: independent subtasks → Parallel; staged refinement → Sequential; iterative self-improvement → Loop; domain classification → Router; multiple independent opinions needing consensus → Aggregator; free-form emergent collaboration → Network; complex delegation with oversight → Hierarchical.
- Design each specialist agent's system prompt to be as narrow and focused as possible — resist the urge to let any single agent's scope creep.
- Design the communication/hand-off mechanism explicitly: what data passes between agents, in what format, and who owns the 'is this done?' decision.
- Build in explicit safeguards against duplicate work and unclear turn-taking — minimizing friction between agents is the central design principle, not picking the most sophisticated-looking pattern.
- Test the system's collective output against a single well-prompted agent baseline — multi-agent overhead (latency, cost, coordination bugs) is only worth it if the collective result is measurably better.
Example
import asyncio
Router pattern: dispatch to the right specialist agent
async def router_pattern(query: str) -> str: category = classify(query) # e.g., an LLM call returning 'finance' | 'legal' | 'support' specialists = { 'finance': fin_agent, 'legal': law_agent, 'support': support_agent, } return await specialistscategory
Aggregator pattern: fan out to N agents, combine their independent opinions
async def aggregator_pattern(query: str) -> str: opinions = await asyncio.gather( agent_a(query), agent_b(query), agent_c(query), ) return aggregate(opinions) # e.g., majority vote, or a synthesis LLM call
Loop pattern: iteratively refine until a quality bar is met
async def loop_pattern(task: str, max_iters: int = 3) -> str: draft = await writer_agent(task) for _ in range(max_iters): feedback = await critic_agent(draft) if feedback.is_good_enough: break draft = await writer_agent(task, feedback=feedback) return draft
Real-world usage
CrewAI's 'Crew' abstraction with multiple named agents and a Process (sequential or hierarchical) is a direct implementation of the Sequential and Hierarchical patterns. AutoGen's GroupChat pattern implements the Network pattern — agents converse freely with a manager only lightly moderating turn order. Perplexity and other AI search products use an Aggregator-style pattern internally, fusing results from multiple retrieval/ranking passes into one final answer. Customer support platforms with domain-specific bots (billing, technical, sales) commonly implement the Router pattern, classifying incoming tickets and dispatching to the right specialist agent. Document-processing pipelines (invoice parsing, contract review) commonly use Parallel patterns — one agent extracts entities, another classifies document type, another checks compliance — running concurrently before merging into a final structured output.
Trade-offs
Every pattern beyond a single agent adds coordination overhead: more LLM calls (higher cost and latency), more places for bugs to hide (which agent said what, in what order), and more difficulty debugging failures (was it Agent A's fault, or a hand-off problem?). Parallel and Aggregator patterns add cost linearly with the number of agents but can reduce wall-clock latency; Sequential and Hierarchical patterns add latency (each stage waits for the previous) but can dramatically improve quality through staged refinement; Network patterns are the most flexible but also the hardest to make predictable or debuggable, since there's no fixed control flow to reason about. The core guidance: pick the pattern that minimizes friction for your specific workflow shape, not the most impressive-looking one.
Visual explanation
Seven small diagrams, one per pattern. Parallel: [Task] splits into three parallel arrows → [Agent A] [Agent B] [Agent C] → arrows converge into [Merge] → [Result]. Sequential: [Task] → [Agent A] → [Agent B] → [Agent C] → [Result], a straight chain. Loop: [Agent] → [Output] → arrow curves back into [Agent] with a 'good enough?' decision diamond before exiting to [Final Result]. Router: [Task] → [Router Agent] → branches to [FinAgent] OR [LawAgent] OR [SupportAgent] based on classification. Aggregator: [Agent A][Agent B][Agent C] each independently produce an opinion → all arrows point into [Aggregator Agent] → [Consensus Result]. Network: a cluster of agent nodes with bidirectional arrows connecting all of them to each other, no single center. Hierarchical: [Planner Agent] at top, arrows down to [Worker 1][Worker 2][Worker 3], with arrows back up reporting progress to the Planner.
Advantages
- —
Gives engineers a fixed vocabulary of proven collaboration topologies instead of inventing ad hoc multi-agent structures
- —
Each pattern maps cleanly onto a specific workflow shape, making pattern selection a matter of matching, not guessing
- —
Specialist agents with narrow system prompts are more reliable and easier to improve independently than one monolithic agent
- —
Patterns like Parallel and Aggregator can reduce latency or improve output quality through concurrency and ensembling
Disadvantages
- —
Every additional agent adds LLM call overhead, increasing both cost and latency compared to a single well-scoped agent
- —
More agents means more places for coordination bugs — duplicate work, deadlocked turn-taking, lost context at hand-offs
- —
Network and Hierarchical patterns in particular can be difficult to debug since failures may originate from coordination logic rather than any single agent's reasoning
- —
It's easy to over-apply multi-agent patterns to tasks a single agent with tools could handle just as well, adding complexity without proportional benefit
Common mistakes
- —
Reaching for a multi-agent pattern (especially Hierarchical or Network) before confirming a single well-prompted agent with tools genuinely can't handle the task
- —
Choosing a pattern because it 'looks impressive' rather than because it matches the actual shape of the workflow
- —
Not designing explicit turn-taking and work-deduplication logic, leading to agents redundantly repeating each other's work or getting stuck waiting on each other
- —
Letting individual agent system prompts creep in scope until they're nearly monolithic again, defeating the purpose of specialization
- —
Skipping a single-agent baseline comparison, so nobody can tell whether the multi-agent system's added cost and complexity actually improved the result
📂 Subtopics
Sequential Pattern: Agents in a Pipeline
Each agent adds value step by step — one generates, the next reviews, a third deploys — the straightforward pipeline pattern used in workflow automation, ETL chains, and multi-step reasoning.
~10 min
Parallel Pattern: Agents Working Simultaneously
Each agent tackles a different subtask at the same time, and their outputs merge into one result — reduces latency in high-throughput pipelines where subtasks don't depend on each other.
~10 min
Hierarchical Pattern (the "Supervisor" Pattern): One Orchestrator, Many Workers
A top-level planner agent delegates subtasks to workers, tracks their progress, and makes the final calls — exactly like a manager and their team. The book calls this 'Hierarchical'; it's commonly also called the Supervisor pattern.
~12 min
Debate Pattern: Multiple Agents Arguing Different Positions to Reach a Better Answer
Not one of the book's 7 named patterns, but a real, well-documented complementary technique: multiple agents argue distinct positions on a question, and either a judge agent or consensus resolves them to the strongest final answer.
~12 min