--- schema: formation.guide/v0.1 kind: guide visibility: public also_known_as: - 'multi-agent architecture' - 'agent orchestration patterns' - 'agent swarm' - 'multi-agent design patterns' - 'LLM agent topologies' canonical_url: https://topologyindex.com/guides/agentic-design-patterns.md description: 'The design patterns LLM agents are organized into (single agent, orchestrator-worker, planner-executor, evaluator-optimizer, map-reduce, fan-out, routing, debate, swarms and handoffs) by family, with a decision guide by task shape and attributed findings. Never a ranking.' domain_index: /domains/index.md domains: - coding - research - documents - reasoning - evaluation - operations - security families: - family: baseline patterns: - single_agent - family: parallelism patterns: - fan_out - map_reduce - independent_workers - lane_swarm - family: hierarchy patterns: - supervisor - planner_worker - role_pipeline - hierarchical_delegation - family: shared_state patterns: - blackboard - shared_ledger - mailbox_network - family: verification patterns: - implement_review - critic_loop - council - debate - family: adaptive patterns: - dynamic_spawning - coordinator_election - adaptive_routing - tree_search - architecture_search - family: continuity patterns: - successor_handoff - signed_coordination guide: agentic-design-patterns path: /guides/agentic-design-patterns.md pattern_index: /patterns/index.md product_api_version: v1 research_index: /research/index.md schema_version: v0.1 starter_index: /starters/index.md title: 'Agentic design patterns: multi-agent architecture and orchestration patterns' --- # Agentic design patterns Agentic design patterns are the recurring ways LLM agents are organized to do work: how the work is divided, who checks it, what state the agents share and who decides what happens next. The same subject is called multi-agent architecture, agent orchestration patterns or, for many agents working at once, an agent swarm. This guide walks through every pattern in the [pattern catalogue](/patterns/index.md) by family, then says how to choose between them. Nothing here ranks patterns or names a best one. A pattern says how work is organized, never how well that works; which arrangement suits a task is something to test on that task. - Pattern: one named building block of multi-agent orchestration, such as a supervisor or a critic loop. - Topology: the whole arrangement of roles, control flow and shared state for a task, built from one or more patterns. - Formation: a versioned `FORMATION.md` policy file that declares a topology so it can be run and compared. ## Start with one agent The simplest arrangement is [single_agent](/patterns/single_agent.md): one agent, its tools and a stop condition. It is also the comparison every other pattern needs, because a claim about a multi-agent arrangement only means something next to a strong single-agent configuration. The general findings at the end of this guide include studies in which adding agents made no clear difference. ## The patterns, by family Every pattern in the vocabulary, grouped by family in vocabulary order. Each page gives the structure, when the pattern is hypothesised to fit, failure modes, other names, primary sources, the published findings it cites (or that there are none) and whether this deployment can execute it. ### baseline One agent and no coordination: the arrangement every other one is compared against. - [single_agent](/patterns/single_agent.md): One agent works the task alone, with no second role and no shared state. Also called: single-agent baseline, augmented LLM, ReAct agent, tool-using agent loop. ### parallelism Several agents work at the same time, on the same task or on parts of it, and the results are selected or combined. - [fan_out](/patterns/fan_out.md): Several workers attempt the same task at once and one result is selected. Also called: best-of-N sampling, parallel attempts, self-consistency, parallelization by voting (Anthropic). - [map_reduce](/patterns/map_reduce.md): The task is split into parts, worked in parallel, and the parts are combined. Also called: scatter-gather, parallelization by sectioning (Anthropic), divide and conquer, split-and-merge. - [independent_workers](/patterns/independent_workers.md): Separate agents work separate tasks at the same time and never communicate. Also called: embarrassingly parallel agents, isolated parallel agents, batch of independent agents. - [lane_swarm](/patterns/lane_swarm.md): Many workers take assigned lanes of one larger effort on a common channel. Also called: agent swarm, multi-agent swarm, lane-based parallel agents. ### hierarchy One role directs, plans or delegates, and other roles carry the work out. - [supervisor](/patterns/supervisor.md): One controlling role directs subordinate workers and decides what happens next. Also called: orchestrator-worker (Anthropic), orchestrator-workers, supervisor agent (LangGraph), manager agent, hierarchical process (CrewAI), lead agent with subagents. - [planner_worker](/patterns/planner_worker.md): A planning role produces a plan, then a separate working role carries it out. Also called: planner-executor, plan-and-execute, plan-then-act, architect-editor. - [role_pipeline](/patterns/role_pipeline.md): A fixed sequence of roles, each working from what the role before it produced. Also called: prompt chaining (Anthropic), assembly line (MetaGPT), chat chain (ChatDev), sequential process (CrewAI), sequential agents, waterfall of role agents. - [hierarchical_delegation](/patterns/hierarchical_delegation.md): Work is delegated down several levels: assignees become assigners. Also called: hierarchical agents, hierarchical multi-agent system, recursive delegation, hierarchical teams (LangGraph). ### shared_state Agents coordinate through something they all read and write: a board, a log or mailboxes. - [blackboard](/patterns/blackboard.md): Every agent reads and writes one shared space, and that space is the coordination. Also called: shared scratchpad, shared memory architecture, group chat (AutoGen), blackboard architecture. - [shared_ledger](/patterns/shared_ledger.md): Agents append to a common ordered log and read it to learn what already happened. Also called: append-only log coordination, shared task log, event log coordination, progress ledger. - [mailbox_network](/patterns/mailbox_network.md): Agents address each other through per-agent mailboxes instead of one open board. Also called: peer-to-peer agents, agent network, direct agent messaging, network of agents (LangGraph). ### verification One role checks, criticizes or judges what another role produced. - [implement_review](/patterns/implement_review.md): An implementing role hands work to a review-only role within a bounded cycle. Also called: maker-checker, coder-reviewer, generate-and-review, LLM-as-reviewer, author-reviewer. - [critic_loop](/patterns/critic_loop.md): Implementation and criticism alternate for a bounded number of rounds. Also called: evaluator-optimizer (Anthropic), reflection, self-refine, generator-critic loop, actor-critic prompting. - [council](/patterns/council.md): Several reviewers judge the same work and their verdicts are combined into one. Also called: LLM-as-a-judge panel, jury of models, ensemble review, mixture-of-agents, majority vote review. - [debate](/patterns/debate.md): Agents argue opposing positions and a separate judge decides the outcome. Also called: multi-agent debate, adversarial debate, debate with a judge. ### adaptive The arrangement itself is decided during the run: workers spawned, a coordinator elected, a route or a design chosen. - [dynamic_spawning](/patterns/dynamic_spawning.md): New workers are created during the run in response to what the run finds. Also called: dynamic subagents, spawn-on-demand workers, runtime agent creation, subagent spawning. - [coordinator_election](/patterns/coordinator_election.md): The participants decide among themselves which of them coordinates. Also called: leader election, elected coordinator, emergent leadership. - [adaptive_routing](/patterns/adaptive_routing.md): Which role runs next is chosen during the run from conditions seen in the run. Also called: router, routing (Anthropic), conditional routing, conditional edges (LangGraph), handoffs (OpenAI Agents SDK), triage agent. - [tree_search](/patterns/tree_search.md): Partial attempts branch into a tree, an evaluator scores the branches, and the most promising one is extended next. Also called: Language Agent Tree Search, LATS, Monte Carlo tree search agent, best-first tree search, Tree of Thoughts, beam search over reasoning steps. - [architecture_search](/patterns/architecture_search.md): The arrangement itself is changed while the work runs, searching for a better one. Also called: agent architecture search, automated agent design, self-improving agent topology, topology optimization. ### continuity Work carries across context windows, sessions or agents, with a handover or with signed messages. - [successor_handoff](/patterns/successor_handoff.md): An agent hands its accumulated context to a later agent that continues the work. Also called: context handoff, session handover, relay agents, long-running agent continuation. - [signed_coordination](/patterns/signed_coordination.md): Coordinating agents sign their messages so a reader can tell who wrote one. Also called: authenticated agent messages, signed agent messages, agent identity attestation. ## Choosing a pattern Where to start by the shape of the task. Every row is a hypothesis to test against a strong single-agent configuration, not a ranking: nothing in this table has been measured here. | If the task… | Start with | Consider next | Avoid when | | --- | --- | --- | --- | | is small, or has one clear owner | [single_agent](/patterns/single_agent.md) | [implement_review](/patterns/implement_review.md) | the task clearly exceeds one context window | | is easier to check than to do | [implement_review](/patterns/implement_review.md) | [critic_loop](/patterns/critic_loop.md) | nothing outside the roles can validate the result | | needs several rounds of criticism | [critic_loop](/patterns/critic_loop.md) | [council](/patterns/council.md) | rounds stop converging | | splits into independent parts | [map_reduce](/patterns/map_reduce.md) | [independent_workers](/patterns/independent_workers.md) | the parts depend on each other | | often fails, but attempts vary | [fan_out](/patterns/fan_out.md) | [council](/patterns/council.md) | nothing can cheaply pick the winning attempt | | needs a plan before editing | [planner_worker](/patterns/planner_worker.md) | [supervisor](/patterns/supervisor.md) | the plan cannot be written without touching the work | | has subtasks unknown until it starts | [supervisor](/patterns/supervisor.md) | [dynamic_spawning](/patterns/dynamic_spawning.md) | a fixed plan would do | | needs a different specialist per input | [adaptive_routing](/patterns/adaptive_routing.md) | [supervisor](/patterns/supervisor.md) | the routing condition is not observable | | outlasts one context window or session | [successor_handoff](/patterns/successor_handoff.md) | [shared_ledger](/patterns/shared_ledger.md) | rediscovery is cheaper than a handover | ## Agent swarms "Agent swarm" is used for several different arrangements of many agents working at once. In this vocabulary it can mean any of these: - [fan_out](/patterns/fan_out.md): Several workers attempt the same task at once and one result is selected. - [map_reduce](/patterns/map_reduce.md): The task is split into parts, worked in parallel, and the parts are combined. - [independent_workers](/patterns/independent_workers.md): Separate agents work separate tasks at the same time and never communicate. - [lane_swarm](/patterns/lane_swarm.md): Many workers take assigned lanes of one larger effort on a common channel. - [dynamic_spawning](/patterns/dynamic_spawning.md): New workers are created during the run in response to what the run finds. They differ in whether the agents share a task, split one, or take lanes of a larger effort, and in whether anything coordinates them. Each page lists what to watch for. ## By kind of work The [task domains](/domains/index.md) are a way into the decision guide by the kind of work, each with the task shapes common in it and the published findings tagged with it: - [coding](/domains/coding.md): Software engineering by agents: code generation, bug fixing in a repository, code review, refactoring and long-running development. - [research](/domains/research.md): Finding and synthesizing information across sources: web and deep research, literature review and data discovery. - [documents](/domains/documents.md): Reading, summarizing and answering questions over long documents and collections of them. - [reasoning](/domains/reasoning.md): Math, logic, knowledge and question answering, where the answer comes from thinking rather than from acting on an environment. - [evaluation](/domains/evaluation.md): Judging the output of models and agents: LLM-as-judge, graders and review panels. - [operations](/domains/operations.md): Acting on an environment through tools: web navigation, desktop and terminal work, workplace tools and function calling. - [security](/domains/security.md): Agents doing security work: code audit, vulnerability detection, penetration testing, capture-the-flag challenges, exploitation and patching; attacks on agents are a separate risk. ## What research says about multi-agent systems in general Attributed to each source and stated without figures; unfavourable results are included on purpose. None of this is evidence produced here. Reviewed 2026-09-23. Each label says how multi-agent systems in general fared against what it was compared with, as the source reports it; the labels are defined at [/docs/schemas/pattern/v0.1.md](/docs/schemas/pattern/v0.1.md). - **No clear gain** — Cemri and colleagues note that multi-agent performance gains on popular benchmarks are often minimal and build a failure taxonomy spanning system design, inter-agent misalignment and task verification. Compared against: Single-agent and simpler baselines on popular benchmarks. Domain: Multi-agent frameworks across coding, math and general tasks. Benchmarks: MAST-Data. Caveat: The taxonomy characterizes failures rather than measuring a single head-to-head gain. Source: [Why Do Multi-Agent LLM Systems Fail?](https://arxiv.org/abs/2503.13657), Cemri et al., 2025-03-17. - **No clear gain** — Wang and colleagues report that a single agent with strong prompts achieves almost the same performance as the best multi-agent discussion, which wins only when no demonstrations are given. Compared against: A single agent with strong prompts and demonstrations. Domain: Reasoning tasks. Caveat: Covers discussion-style multi-agent setups, not tool-using or parallel agent systems. Source: [Rethinking the Bounds of LLM Reasoning: Are Multi-Agent Discussions the Key?](https://arxiv.org/abs/2402.18272), Wang et al., 2024-02-28. - **No clear gain** — Smit and colleagues report that multi-agent debate does not reliably outperform self-consistency and ensembling and is more sensitive to hyperparameters. Compared against: Self-consistency and ensembling prompting strategies. Domain: Question answering including medical. Caveat: Tuning agent agreement levels let some debate systems surpass other protocols, so results depend on configuration. Source: [Should we be going MAD? A Look at Multi-Agent Debate Strategies for LLMs](https://arxiv.org/abs/2311.17371), Smit et al., 2023-11-29. - **Mixed** — Kim and colleagues report that multi-agent coordination ranges from large gains on decomposable tasks to large losses on sequential planning, with diminishing or negative returns once the single agent is already strong and higher overhead on tool-heavy tasks. Compared against: A single agent under matched tools, prompts and compute. Domain: Agentic benchmarks including finance, planning and tool use. Caveat: Controlled study across a fixed set of architectures and model families; the predictive model explains only part of the variance. Source: [Towards a Science of Scaling Agent Systems](https://arxiv.org/abs/2512.08296), Kim et al., 2025-12-09. - **Mixed** — Wang and colleagues report that among the deep research products they evaluated, multi-agent systems led on presentation and on linking claims to their citations, while single-agent web search systems were the most factually and logically consistent and single-agent deep research systems linked citations worst. Compared against: Single-agent web search and single-agent deep research systems. Domain: Deep research: citation-grounded reports from live web sources. Benchmarks: LiveResearchBench. Caveat: The systems are products built on different models and tools, so the comparison is between complete systems and not controlled for the arrangement. Source: [LiveResearchBench: A Live Benchmark for User-Centric Deep Research in the Wild](https://arxiv.org/abs/2510.14240), Wang et al., 2025-10-16. - **Mixed** — Anthropic advises finding the simplest solution possible and adding multi-step agentic systems only when simpler solutions fall short. Compared against: Simple prompts and workflows. Domain: General LLM application design. Caveat: Vendor guidance, not an experimental result. Source: [Anthropic: Building Effective AI Agents](https://www.anthropic.com/engineering/building-effective-agents), Erik S., Barry Zhang (Anthropic), 2024-12-19. ## Try one Unvalidated [starter formations](/starters/index.md) declare some of these arrangements as `FORMATION.md` files to copy; nobody has run them here. The [research records](/research/index.md) describe arrangements observed in practice, and the [integration guide](/docs/api/integration.md) shows how an agent reads all of this over HTTP or MCP. ## How evidence works here A pattern names how work is organized, never how well that works. Evidence in this service attaches to a complete execution configuration — a topology formation together with an execution lock pinning models, tools and runtime — and never to a pattern on its own, so no page here carries a success rate, a cost or a run count for an arrangement. [Reporting outcomes (limited rollout)](/docs/api/contributing.md): only for a pattern, starter or formation fetch that carried a `Use-Ticket` (or a "Report back" note at the end of the page), which invited credentials and some selected visiting agents receive; without one there is nothing to report and nothing else changes.