How to Build Multi-Agent Systems (and When Not To)

Most multi-agent systems are one agent's job that got fragmented by an org chart, a demo, or a diagram that looked cool on a slide. Before you build a swarm, try the boring thing first: a single agent with a good tool set, a clear prompt, and a big enough context window. If that genuinely can't do the job — because the task has independent parallel branches, or needs isolation between untrusted steps, or exceeds what one context can hold — then and only then reach for multiple agents. The reason is simple: every agent you add multiplies coordination cost, error surface, and token spend, and coordination is the one thing language models are still bad at.

This guide is the case both ways. It gives you the real patterns for when multi-agent is the right answer — orchestrator/worker, pipelines, isolation — and the honest accounting of what they cost, so you can tell the difference between a problem that needs agents and a problem that needs a better single agent.

Table of contents

• Key takeaways
• What "multi-agent" actually means
• The default: one good agent
• When multi-agent actually earns its keep
• The topology catalog
• Pattern 1: Orchestrator / worker
• Pattern 2: The pipeline
• Orchestration patterns: routing, planning, map-reduce
• Communication and handoff mechanics
• Shared memory vs message passing
• The failure modes
• The costs nobody puts on the slide
• The cost and latency reality
• Evaluation and observability
• The frameworks landscape
• A worked example
• Anti-patterns
• A decision procedure
• FAQ

Key takeaways

• Default to one agent. A single agent with good tools and a clear objective beats a multi-agent system on most tasks, and it is dramatically easier to debug.
• Split for independence, isolation, or scale — not for tidiness. Good reasons: genuinely parallel subtasks, security boundaries, or context that won't fit. Bad reasons: "it feels more organized" or "each role should be its own agent."
• Coordination is the tax. Every handoff adds latency, tokens, and a new place for the system to lose information or compound an error.
• Two patterns cover most real cases: orchestrator/worker (one planner fans out to specialists) and pipeline (fixed stages, each transforming the output of the last).
• Errors propagate and cost compounds. A 90%-reliable step run five times in sequence is only ~59% reliable end to end, and parallel agents can multiply your token bill several times over.
• Shared state is where multi-agent systems rot. Prefer explicit message passing with narrow interfaces over a big shared scratchpad every agent can scribble on.

What "multi-agent" actually means

An agent, in the sense that matters here, is a language model in a loop: it takes a goal, decides on an action (often calling a tool), observes the result, and repeats until it thinks it's done. One agent, one loop, one context. If you want the ground-up version of how the model underneath makes those decisions, how AI chatbots work and how transformers work are the prerequisites.

A multi-agent system is more than one such loop, where the agents pass work or information between each other. The critical word is between. Calling a function is not a second agent. Retrieving a document is not a second agent. You only have a multi-agent system when there are two or more independent reasoning loops, each with its own context and its own decisions, that have to coordinate.

That distinction matters because most things people call "agents" in a multi-agent diagram are actually just tools. A "search agent" that takes a query and returns results is a search tool. A "summarizer agent" that takes text and returns a summary is a function call. Wrapping a deterministic or single-shot step in the word "agent" doesn't make it one — it just adds a model call, latency, and a chance to hallucinate where you didn't need one.

The default: one good agent

Before any of the patterns below, internalize the default. A single agent with a well-chosen tool set handles a startling range of tasks: research, coding, data extraction, customer support, multi-step form-filling. Modern context windows are large enough that "the task is too big for one context" is far less often true than people assume, and the failure mode of a single agent — it does the wrong thing — is legible. You can read the transcript top to bottom and see exactly where it went off.

The single-agent version wins on almost every operational axis:

• Debuggability. One transcript, one context, one place to look.
• Latency. No handoffs, no waiting on a slow worker to unblock the orchestrator.
• Cost. No re-sending of shared context to every sub-agent.
• Reliability. Fewer steps means fewer independent chances to fail.

If a single agent is struggling, the first move is almost never "add another agent." It's better tools, a sharper prompt, or better retrieval. A shaky agent usually needs a cleaner objective and a tool that returns structured results — see how to write better prompts — long before it needs a committee. Splitting a confused single agent into three confused agents gives you three problems and a coordination layer.

When multi-agent actually earns its keep

There are three legitimate reasons to run more than one agent. Notice that "different responsibilities" is not on the list — responsibilities can live in one agent's prompt and tool set.

1. Genuine parallelism. The task decomposes into subtasks that are independent of each other and can run at the same time. Researching ten companies, reviewing twenty files, evaluating a claim against five sources — these fan out cleanly because the workers don't need to talk to each other. Parallelism is the strongest case for multi-agent, because it buys wall-clock time that a single sequential agent can't.

2. Isolation and security boundaries. You want a hard wall between steps: an untrusted step (running model-generated code, browsing arbitrary web content) that must not have access to your privileged tools or secrets. Separate agents with separate tool permissions give you a real boundary. This is an architecture decision, not a convenience one, and it overlaps with the concerns in AI chatbot privacy.

3. Context that genuinely won't fit or shouldn't mix. When each subtask needs a large, distinct body of context that would blow the window if combined — or when mixing contexts causes interference (the model bleeds facts from task A into task B) — separate agents each carrying their own slice is cleaner than one agent juggling everything.

If your reason isn't one of these three, you probably want one agent. "It maps to how our team is organized" is an org chart leaking into your architecture.

The topology catalog

"Multi-agent" is not one architecture; it's a family of communication graphs, and the graph you choose determines the failure modes you inherit. Think of each topology as a set of edges, where every edge is a channel through which work, context, and — inevitably — errors flow. More edges means more capability in principle and more places for the system to lose the plot in practice. Here is the honest catalog, roughly ordered from "reach for this" to "prove you need it."

Single agent with tools. The degenerate case, and the one you should exhaust first. Zero agent-to-agent edges. One reasoning loop calls functions, retrieves documents, and executes code. Everything a "tool agent" would do collapses into a tool. The entire rest of this catalog exists only to justify leaving this box.

Supervisor / orchestrator-workers (star). One central agent holds the goal and delegates to N workers that never talk to each other. The edge count is exactly N — the minimum for real parallelism. This is Pattern 1 below and the default when you genuinely need multiple agents. The star shape is what keeps it debuggable: every path runs through one node you can inspect.

Sequential pipeline (chain). Stages arranged in a line, each consuming the previous stage's output. N-1 edges, all directed forward. Predictable and easy to reason about, but every edge is a place a bad output propagates unchecked. This is Pattern 2. Its defining property: no node has a global view, so nothing catches a compounding error unless you install explicit gates.

Hierarchical (tree). Orchestrators of orchestrators. A top-level planner delegates to mid-level supervisors that each command their own workers. Useful when a task decomposes into subtasks that themselves decompose — a research project with five topics, each needing its own fan-out. The cost is that context and errors now traverse multiple levels, and a misframing at the top silently distorts everything below it. Depth is expensive; keep trees shallow.

Blackboard (shared state). No direct edges between agents; instead every agent reads from and writes to a common workspace. Flexible and loosely coupled, but it is a global mutable variable in a system built from stochastic processes. One agent's ambiguous write becomes another's ground truth. Covered in depth under shared memory vs message passing — the short version is: avoid unless the shared store is append-only and attributed.

Debate / ensemble. Multiple agents independently attempt the same task, then either critique each other (debate) or have their outputs aggregated by a judge (ensemble). This can genuinely improve quality on hard reasoning problems by surfacing disagreement, but it multiplies cost by the number of participants and adds an aggregation step that can itself be wrong. Reserve it for high-stakes, low-volume decisions where the quality lift is measurable, not a reflex.

Network (mesh). Every agent can talk to every other agent. The maximum edge count and the maximum chaos. Attractive on a slide because it looks like emergent intelligence; in production it's a distributed system with no coordinator, non-deterministic participants, and O(N²) channels for errors to launder through. Treat fully connected meshes as research artifacts. If you find yourself drawing one, the honest question is which single coordinator you're avoiding building.

Topology	Edges	Best for	Main risk
Single agent + tools	0	Almost everything	You genuinely outgrow one context
Supervisor / star	N	Parallel independent subtasks	Bad decomposition or synthesis
Pipeline / chain	N-1	Fixed repeatable sequences	Errors propagate unchecked
Hierarchical / tree	tree	Recursively decomposable tasks	Misframing distorts subtrees
Blackboard	shared	Loosely coupled collaboration	Global mutable state rot
Debate / ensemble	N→judge	High-stakes reasoning	Cost multiplies by participants
Network / mesh	O(N²)	Rarely justified in production	Coordination collapse

The practical takeaway: the further down this table you go, the more the burden of proof shifts onto you. Star and chain cover the overwhelming majority of legitimate production systems. Everything below them should come with an experiment showing the marginal capability was worth the marginal chaos.

Reason to split	Legitimate?	Better single-agent alternative
Subtasks run in parallel and independently	Yes	— (this is the real case)
Untrusted step needs isolated permissions	Yes	— (security boundary)
Distinct large contexts that can't coexist	Yes	— (context limit)
"Each role should be its own agent"	No	One agent, roles in the prompt
"One prompt is getting long"	Usually no	Better tools + structured output
"It looks more modular on the diagram"	No	Modular tools, single loop

Pattern 1: Orchestrator / worker

The most useful multi-agent pattern. One orchestrator agent owns the goal and the plan. It decomposes the task, spins up worker agents for the independent pieces, and then synthesizes their results into a final answer. Workers don't talk to each other — they only report back to the orchestrator. This is a star topology, and the lack of worker-to-worker edges is exactly what keeps it manageable.

It works because it matches the parallelism case. The orchestrator says "research these five vendors," fires five workers with identical instructions and different inputs, waits, and merges. Each worker has a fresh context focused on one vendor, so none of them drown in irrelevant detail.

The failure modes are specific and worth pre-empting:

• Vague delegation. If the orchestrator hands a worker a fuzzy instruction ("look into pricing"), the worker guesses at scope and you get inconsistent results. Delegation prompts must be specific: what to find, what format to return, what to ignore.
• Duplicated or missing work. Poorly partitioned subtasks lead to workers doing the same thing twice or leaving a gap. The orchestrator's decomposition is the whole ballgame.
• Synthesis blindness. The orchestrator only sees what workers report. If a worker returns a confident-but-wrong summary, the orchestrator has no way to know. Have workers return evidence (quotes, links, structured fields), not just conclusions.

Pattern 2: The pipeline

A pipeline is a fixed sequence of stages where each stage transforms the output of the previous one: extract → transform → validate → format, for example. Each stage can be an agent, but crucially, most stages usually shouldn't be. A validation stage that checks a schema is code. A formatting stage is a template. Reserve the agent (a real reasoning loop) for the stages that genuinely need open-ended judgment.

Pipelines are attractive because they're predictable — you know the stages up front — and they're easy to reason about. But they carry the sequential-reliability tax hard: because every stage feeds the next, an error in stage two poisons everything downstream, and there's no orchestrator with a global view to catch it. The mitigation is to put a validation gate between stages so a bad output is caught and retried before it propagates, rather than sailing through to the end.

Pipelines shine for well-understood, repeatable workflows (document processing, data enrichment, content transformation) — and when the stages are fixed and mostly deterministic, what you're really building is AI workflow automation, not a multi-agent system. They're a poor fit for open-ended, exploratory tasks where you don't know the steps in advance — that's orchestrator territory, or a single agent with tools.

There are fancier topologies — debate (agents critique each other), hierarchical trees of orchestrators, fully decentralized swarms. Treat them as research toys until proven otherwise. Every extra edge in the communication graph is another channel for errors and cost to flow through, and the marginal reliability they buy rarely survives contact with production.

Orchestration patterns: routing, planning, map-reduce

Topology is the shape of the graph; orchestration is the logic the coordinator runs to fill it in. Three patterns cover most of what an orchestrator actually does, and they compose.

Routing (classify, then dispatch). The simplest orchestration: a lightweight step inspects the incoming request and sends it to the right handler. A support system routes billing questions to one specialist and technical questions to another; a coding agent routes "explain this" differently from "refactor this." The critical design point is that the router should be cheap and deterministic where possible — a classifier, a regex, an embedding-nearest-neighbor lookup — not a full reasoning agent, because every request pays the router's cost. Routing does not require multiple agents at all; a single agent can route to tools. It becomes multi-agent only when the destinations are themselves independent loops with distinct context needs. Get routing wrong and you either misclassify (send work to the wrong specialist) or over-classify (spin up an expensive model to make a decision a keyword match could have made).

Planning (decompose, then execute). The orchestrator turns a goal into an ordered or partially ordered set of subtasks before dispatching any of them. This is where multi-agent systems earn parallelism: a good plan identifies which subtasks are independent (fan them out) and which have dependencies (sequence them). The failure mode is planning in a vacuum — the planner commits to a decomposition based on assumptions that the first worker's results immediately invalidate. The mitigation is re-planning: treat the plan as revisable, let the orchestrator observe early results and adjust, rather than blindly executing a stale plan to completion. A rigid up-front plan is a pipeline wearing an orchestrator costume.

Map-reduce over subtasks. The workhorse of legitimate multi-agent systems. Map: apply the same operation to many independent inputs in parallel — summarize each of 40 documents, evaluate each of 12 candidates, research each of 8 competitors. Reduce: combine the mapped results into a single answer. This maps precisely onto orchestrator/worker and is the pattern where the coordination tax is most clearly worth paying, because the workers are genuinely independent and the wall-clock savings are real. The subtle risks live in the reduce step: naive concatenation blows the orchestrator's context window, and naive summarization drops the specific evidence you fanned out to collect. A good reduce is often hierarchical — combine results in batches, then combine the batches — and preserves provenance so the final synthesis can cite which worker found what.

Most real orchestrators are a small stack of these: route the request to a planner, plan a map-reduce, re-plan if the map surfaces surprises. Anything more elaborate is usually a sign the task wanted a single agent with better tools.

Communication and handoff mechanics

When one agent hands work to another, three things can move across the boundary: the task (what to do), the context (what's known), and the results (what was found). How you move each one determines whether your system is auditable or a black box.

Context handoff is the hard part. A worker agent starts with an empty context; whatever the orchestrator doesn't explicitly pass, the worker doesn't know. This forces a genuine design decision that a single agent never faces: how much context does this sub-task actually need? Pass too little and the worker hallucinates the missing pieces or asks clarifying questions it can't get answered. Pass too much — dump the entire conversation history into every worker — and you pay for that context on every step of the worker's loop and reintroduce the interference you split to avoid. The discipline is to hand each worker a tight, purpose-built briefing: the goal, the specific inputs, the output contract, and nothing else.

The sub-agent context-isolation benefit. This constraint is also the single most underrated reason to go multi-agent. A worker with a fresh, narrow context is not distracted by the orchestrator's sprawling history. It sees only its slice, so it reasons more sharply about that slice and its context window isn't polluted by 30 turns of unrelated work. When a task is drowning a single agent in accumulated context — the transcript is so long the model is losing the thread — spawning a sub-agent with a clean context to handle one bounded piece and return a compact result is a legitimate, mechanically sound reason to split. You are effectively using the sub-agent as a context firewall: it absorbs the messy exploration and hands back only the distilled answer, keeping the orchestrator's context lean.

Two mechanisms for the handoff. Everything reduces to one of two moves, and the difference is the same shared-state-versus-messages distinction covered next: either the agents read and write a common store (shared state), or the orchestrator passes explicit typed payloads to workers and receives typed results back (message passing). The output contract — a schema the worker must return — is what makes the handoff inspectable. When a worker returns structured fields instead of prose, the orchestrator can validate them, the failure is localized, and every handoff becomes a logged artifact rather than a paragraph you have to trust. Design the interface between agents as deliberately as you would a public API, because that is exactly what it is.

Shared memory vs message passing

How agents share information is where these systems quietly rot. Two broad approaches:

Shared memory — a common scratchpad, database, or blackboard that every agent can read and write. Tempting because it's flexible. Dangerous because it's a global mutable variable in a distributed system built out of stochastic processes. One agent writes a wrong or ambiguous fact, another reads it as gospel, and the error launders itself into truth. Debugging becomes "who wrote this and why," across several non-deterministic transcripts.

Message passing — agents communicate through explicit, narrow, well-typed messages. Agent A hands Agent B exactly the fields B needs, nothing more. This is more work to set up and it feels rigid, but rigidity is the point: narrow interfaces contain errors instead of spreading them, and every handoff is a discrete artifact you can log and inspect.

Prefer message passing. If you must share state, make it append-only and attributed — every entry tagged with which agent wrote it and on what basis — so the blackboard is an audit log rather than a rumor mill. If your agents are pulling from a knowledge base rather than each other, that's a retrieval concern, and RAG production architecture plus vector search and embeddings cover it far better than a shared scratchpad will.

The failure modes

Multi-agent systems fail in ways single agents structurally can't, because the failures live in the coordination rather than in any one agent. Knowing the catalog lets you design against it.

Error compounding across agents. Covered quantitatively below, but the qualitative version belongs here: because agent outputs are probabilistic, a mistake made early doesn't stay contained. One agent's hallucination becomes the next agent's premise, stated with the same confidence the truth would carry. There is no exception thrown, no stack trace — just a plausible wrong answer flowing downstream, gathering authority at each hop. This is the defining pathology of chained agents and the reason validation gates exist.

Coordination overhead. Every handoff costs a model call, a serialization step, latency, and tokens — before any useful work happens. In a naive design the coordination can cost more than the work: an orchestrator that spends three turns deciding how to delegate a task a single agent would have finished in one. Past a certain point, adding agents slows the system down, because the marginal agent's coordination cost exceeds the parallelism it buys. Amdahl's law has an agentic cousin: the coordinator is a serial bottleneck no amount of worker parallelism can remove.

Cost explosion. Detailed under the cost and latency reality, and the discipline it forces is measuring cost per resolution rather than cost per token — a multi-agent system can have a lower per-token price and a far higher per-outcome price, because it burns so many more tokens to reach the same result.

Deadlock and loops. When agents can call each other, they can wait on each other. Agent A asks B for input; B asks A for clarification; neither proceeds. Or worse, they proceed in a loop — A refines, B critiques, A refines the critique, forever, each turn billed. Debate and mesh topologies are especially prone to this. The defenses are hard limits (max turns, max spend), a single authority that can unilaterally terminate, and forbidding cycles in the communication graph unless you have an explicit reason for them.

Context fragmentation. No single agent holds the whole picture. The orchestrator knows the plan but not the details each worker discovered; each worker knows its slice but not the goal's full framing. Information that would have been trivially co-present in one agent's context is now scattered across several, and reassembling it in the reduce step is lossy. Symptoms: workers making locally sensible but globally contradictory decisions, the final synthesis missing a fact that some worker clearly found. This is the cost you pay for isolation, and it is why isolation should be a deliberate choice, not a default.

Diffusion of responsibility. A subtler organizational failure: when every agent is "responsible" for a piece, no agent is responsible for the whole, and quality falls through the seams. The orchestrator assumes the worker validated; the worker assumes the orchestrator will catch problems in synthesis. Assign ownership of the end-to-end outcome explicitly — usually to the orchestrator — and make it verify, not trust.

The costs nobody puts on the slide

Two forms of compounding kill naive multi-agent systems.

Error propagation. Agent steps are probabilistic, not deterministic. Suppose each step is 90% reliable — good for an LLM. Chain five in sequence and end-to-end reliability is 0.9⁵ ≈ 59%. Chain eight and you're near a coin flip. Adding agents adds steps, and steps multiply, not add. This is why "more agents to be thorough" often makes a system less reliable: you've added more independent chances to fail, and hallucinations from one agent become another agent's confidently-stated input.

Token blowup. Multi-agent systems are expensive in a way that surprises people. The orchestrator's context gets re-sent to each worker. Workers return verbose reports the orchestrator must re-read. Conversation history duplicates across agents. A task that costs X as one agent can easily cost several times X spread across a fleet, because the same context keeps getting paid for again and again. The economics of AI inference explain why this compounds — every token in every agent's context is billed on every step of its loop. If a multi-agent design isn't buying you parallelism, isolation, or context relief, you're paying that multiplier for nothing.

The uncomfortable rule of thumb: a multi-agent system needs to be dramatically better than the single-agent version to be worth it, because it's automatically worse on latency, cost, and debuggability. Marginal quality gains don't clear that bar.

The cost and latency reality

Put concrete numbers on the multiplier, because intuition undersells it. The base fact: N agents means at least N times the model calls, and usually more, because each agent runs a multi-step loop and each step re-sends that agent's entire growing context. A single agent solving a task in 6 steps makes 6 calls over one context. An orchestrator with 5 workers, each running its own 6-step loop, plus the orchestrator's own planning and synthesis turns, can easily make 40–50 calls across six contexts — and the orchestrator's briefing is duplicated into every worker.

The two axes move in opposite directions, which is the whole design tension:

• Latency. Fan-out helps here — five workers running in parallel finish in roughly the wall-clock time of the slowest one, not the sum. This is the legitimate prize of the orchestrator/worker pattern. But a sequential pipeline does the opposite: five stages in a line take the sum of all five, so a pipeline is slower than a single agent doing the same work, not faster. Parallelism buys latency; chaining spends it.
• Cost. Fan-out hurts here unconditionally. Parallel or sequential, you pay for every token in every agent's context on every step. There is no parallelism discount on the bill — running five workers at once costs the same tokens as running them one after another; you've only compressed the clock, not the spend.

The correct unit of measurement is not cost per token but cost per resolution: what does it cost to actually finish one real task, correctly, end to end? A multi-agent design frequently loses on this metric even when each individual call looks cheap, because it makes so many more calls and retries so many more failures. The deeper mechanics of why every token compounds are in the economics of AI inference. Before shipping a multi-agent system, put its cost-per-resolution next to the single-agent baseline's. If the multiplier isn't buying you parallel wall-clock time, a security boundary, or context relief, you are paying 5x for a rounding-error quality gain.

Evaluation and observability

You cannot improve what you can't see, and multi-agent systems are structurally hard to see into. A single agent gives you one transcript to read top to bottom. A multi-agent system gives you several concurrent transcripts, a coordination layer between them, and an outcome that emerges from their interaction — so a failure might live in a worker, in the orchestrator's decomposition, in the handoff, or in the synthesis, and the top-level output alone won't tell you which.

Two levels of instrumentation are non-negotiable, and both are covered in depth in the agent evaluation guide:

• Observability (tracing). Log every agent's full transcript, every handoff payload, every tool call, and stitch them into a single trace tied to one request ID. You want to replay exactly what each agent saw and produced, in order. Without this, debugging a multi-agent system is guesswork across non-deterministic logs. This is why typed message passing beats a shared blackboard for operability: each message is already a discrete, loggable artifact.
• Evaluation (measurement). Evaluate at two granularities. End-to-end: does the whole system produce correct outcomes on a fixed test set — the only metric that ultimately matters. Per-component: is each worker reliable in isolation, is the router classifying correctly, is the orchestrator's decomposition sound? Component metrics localize regressions; the end-to-end metric tells you whether the multi-agent design is beating the single-agent baseline at all. Always keep that baseline in your eval harness, because the entire justification for the added complexity is a measurable win over one good agent.

The practical trap is evaluating only the final answer. When it's wrong, you'll have no idea which of six moving parts caused it. Trace first, then evaluate per stage, then compare end-to-end against the boring single-agent control.

The frameworks landscape

You do not need a framework to build a multi-agent system — a loop, a way to call tools, and a way to spawn a sub-loop with fresh context is the entire mechanism, and rolling it yourself keeps the coordination logic legible. But several frameworks exist to remove boilerplate, and it's worth understanding what they offer conceptually rather than which library is fashionable this quarter, because the abstractions outlive the names.

Broadly, the landscape sorts into a few philosophies:

• Graph-based orchestration. You define agents as nodes and hand-offs as edges in an explicit state graph. The appeal is control and inspectability: the control flow is a data structure you can see, checkpoint, and resume. The cost is verbosity for simple cases.
• Role/conversation frameworks. You define agents by persona and let them converse to solve a task, often in a group chat. Fast to prototype and intuitive, but the emergent conversation is exactly the hard-to-control, hard-to-cost surface this guide keeps warning about.
• Lightweight orchestration SDKs. Thin libraries that give you an agent loop, tool calling, and a handoff primitive, and otherwise stay out of the way. These map most cleanly onto the "one agent with tools, occasionally spawning a sub-agent" default this guide advocates.
• Workflow/DAG engines. For the pipeline case, a plain workflow engine — the same class of tool behind AI workflow automation — often beats an agent framework, because fixed sequential stages want deterministic orchestration, not reasoning about control flow.

Two durable cautions. First, a framework does not solve the hard problems — decomposition, context handoff, error containment, cost — it only gives you vocabulary for them; a bad decomposition is bad in any library. Second, frameworks lag models. The abstractions were often designed for weaker models that needed more scaffolding, and as base models get more capable, some of that scaffolding becomes overhead you're paying for a problem you no longer have. Choose the thinnest thing that removes real boilerplate, and be ready to drop below it when the abstraction fights you.

A worked example

Make it concrete. Suppose you're building a system that produces a competitive-analysis brief on a market: given a sector, it should profile the top companies and synthesize a summary of the landscape.

The wrong instinct is to draw an org chart: a "research agent," a "writing agent," an "editing agent," a "fact-checking agent," all chatting in a group. That's four models, a mesh of conversation, and a cost multiplier — and "research," "writing," and "editing" aren't independent subtasks, they're phases of one job. It looks organized on the diagram and behaves like a committee in production.

Start with one agent. A single agent with a web-search tool, a page-fetch tool, and a clear objective ("profile the top 5 companies in sector X and write a landscape summary") may well handle this end to end. Read its transcript. Where does it actually struggle? Often the answer is "nowhere fundamental — it just needs a better search tool or a sharper prompt," and you're done, cheaply.

Split only where the task genuinely fans out. Profiling five companies is real, independent parallelism — the map step. So the justified design is orchestrator/worker: the orchestrator identifies the five companies (a planning step), fans out five workers with an identical, specific briefing ("profile company Y: funding, product, pricing, positioning; return these fields as structured data with source links"), and each worker researches its company in a fresh, isolated context. The workers never talk to each other. The orchestrator then runs the reduce step — synthesizing five structured profiles into one landscape summary — and because the workers returned evidence and source links rather than bare prose, the orchestrator can preserve provenance and the whole thing is traceable.

Notice what stayed in the single agent: writing and editing are not separate agents, they're the orchestrator's synthesis turn. Notice what earned a split: the five parallel profiles, and only them. The design has exactly the number of agents the task's independence structure demands — no org chart, no committee, one legitimate map-reduce. That is what a well-scoped multi-agent system looks like: mostly one agent, with fan-out precisely where the work is genuinely parallel.

Anti-patterns

A field guide to the designs that look sophisticated and behave badly.

• The org chart. Mapping agents to human job titles — researcher, writer, editor, manager — instead of to independent subtasks. Roles belong in a prompt; agents belong on parallelizable work.
• Agents-as-tools. Wrapping a single deterministic step (a search, a summary, a schema check) in the word "agent." You've added a model call, latency, and a hallucination surface to something that should have been a function.
• The premature swarm. Reaching for five agents before you've made one agent work. You now have five confused agents and a coordination layer instead of one confused agent you could have fixed with a better tool.
• The chatty mesh. Letting every agent talk to every other agent for "collaboration." You've built a distributed system out of non-deterministic parts with no coordinator — maximal cost, maximal deadlock risk, minimal control.
• The trusting orchestrator. An orchestrator that treats worker outputs as fact and synthesizes them without verification. Workers should return evidence; orchestrators should check it, not launder it.
• The blackboard free-for-all. A shared scratchpad every agent writes to freely, so one bad write becomes everyone's premise and debugging becomes forensic archaeology.
• The infinite refiner. A critique/refine loop with no hard stop, billing you for every turn as two agents polish something forever. Always cap turns and spend.
• Framework-first design. Choosing the library before understanding the task, then contorting the problem to fit the framework's idea of agents. Decide the topology from the work; pick tooling last.

The thread running through all of them: complexity added for the appearance of sophistication rather than to satisfy a real constraint — parallelism, isolation, or context. If you can't name which of those three a given agent serves, it's probably an anti-pattern.

A decision procedure

Work down this list. Stop at the first "yes."

1. Can one agent with better tools do it? Try this first, seriously, and only move on when it demonstrably fails. Most tasks stop here.
2. Does the task have independent parallel branches? If yes, use orchestrator/worker. If no, you probably don't need multiple agents.
3. Is there a security or trust boundary? If a step is untrusted, isolate it in its own agent with restricted permissions.
4. Does context genuinely not fit or badly interfere? If yes, split by context, giving each agent its own slice.
5. Is the workflow a fixed, repeatable sequence? If yes and it needs real judgment at multiple stages, use a pipeline with validation gates — but push every deterministic stage down to code.

If you can't answer yes to 2–5, build one agent. Choosing the model to power it is its own decision — how to choose an LLM for your app walks through it, and the broader agent tooling landscape lives in the AI coding agents guide.

FAQ

When should I use multiple AI agents instead of one? Use multiple agents only when the task has genuinely independent parallel subtasks, requires a hard security boundary between steps, or involves distinct large contexts that can't coexist in one window. If none of those apply, a single agent with good tools will be cheaper, faster, and far easier to debug. "It feels more organized" is not a reason to split.

What is the difference between a multi-agent system and just calling tools? A tool is a single function call or retrieval that returns a result deterministically or in one shot. An agent is a full reasoning loop with its own context that makes its own decisions over multiple steps. You only have a multi-agent system when two or more of these independent loops must coordinate. Wrapping a plain function in the word "agent" adds latency and a chance to hallucinate without adding capability.

Why are multi-agent systems so expensive? Because context gets duplicated and re-sent. The orchestrator's instructions and shared history are paid for again in each worker's context, and every token in every agent's window is billed on every step of that agent's loop. A task that costs X as one agent commonly costs several times X across a fleet, so the design only pays off when it buys real parallelism, isolation, or context relief.

How do errors propagate in a multi-agent system? Each agent step is probabilistic, so reliability multiplies across steps rather than adding. Five steps at 90% reliability each yield roughly 59% end-to-end. One agent's confident but wrong output becomes the next agent's trusted input, laundering an error into apparent fact. Validation gates between steps and returning evidence rather than conclusions are the main defenses.

Should agents share memory or pass messages? Prefer explicit message passing with narrow, well-typed interfaces. A shared scratchpad is a global mutable variable in a system built from non-deterministic processes: one bad write becomes everyone's truth and debugging turns into forensic archaeology. If you must share state, make it append-only and attributed so it functions as an audit log rather than a rumor mill.

Is orchestrator/worker or pipeline the better pattern? Orchestrator/worker fits open-ended tasks with independent parallel branches — one planner fans work out to specialists and synthesizes the results. A pipeline fits fixed, repeatable sequences where each stage transforms the last. Pipelines are more predictable but propagate errors harder, so gate every stage. For exploratory work you don't know the steps of in advance, orchestrator/worker or a single agent is the better fit.

Can splitting into sub-agents ever improve quality rather than just cost more? Yes, and context isolation is the mechanism. A sub-agent starts with a fresh, narrow context, so it isn't distracted by the orchestrator's long accumulated history and reasons more sharply about its one slice. When a single agent is drowning in a sprawling transcript and losing the thread, delegating a bounded piece to a sub-agent that absorbs the messy exploration and returns a compact result keeps the main context lean. That is a legitimate, mechanical reason to split — distinct from parallelism or security.

How do I evaluate and debug a multi-agent system? Trace everything first: log each agent's full transcript, every handoff payload, and every tool call under one request ID so you can replay exactly what each agent saw. Then evaluate at two levels — end-to-end (does the whole system produce correct outcomes on a fixed test set) and per-component (is each worker, the router, and the orchestrator's decomposition individually sound). Always keep a single-agent baseline in the harness; the whole justification for the complexity is beating it. See the agent evaluation guide for the full method.

How do I stop agents from getting stuck in loops or deadlock? Impose hard limits — a maximum number of turns and a maximum spend per task — so nothing runs forever. Give one agent unilateral authority to terminate, rather than letting peers wait on each other. Forbid cycles in the communication graph unless you have an explicit reason for them; debate and mesh topologies, where agents refine each other's output indefinitely, are the usual culprits. A critique/refine loop especially needs a hard stop condition, not just a hope that the agents converge.

Do I need a multi-agent framework? No. The entire mechanism is a loop that can call tools and occasionally spawn a sub-loop with a fresh context — you can build that directly, and doing so keeps the coordination logic legible. Frameworks remove boilerplate and give you vocabulary for handoffs and state, which helps at scale, but they don't solve the hard problems (decomposition, context handoff, error containment, cost) and they tend to lag model capability, carrying scaffolding designed for weaker models. Pick the thinnest option that removes real boilerplate, and choose it after you've decided the topology from the work — not before.