{"course":{"slug":"building-with-ai","title":"Building with AI","url":"https://addaly.com/learn/building-with-ai","level":"intermediate","track":"build"},"lesson":{"slug":"multi-agent-when-worth-it","title":"Multiple agents, and the honest cost","url":"https://addaly.com/learn/building-with-ai/multi-agent-when-worth-it","position":30,"of":80,"minutes":9,"answer":"The real benefit of multiple agents is context isolation and parallelism on genuinely independent subtasks, paid for with roughly an order of magnitude more tokens, lossy summaries at each boundary and ordinary concurrency bugs.","keyIdea":"The real benefit of multiple agents is context isolation and parallelism on genuinely independent subtasks, paid for with roughly an order of magnitude more tokens, lossy summaries at each boundary and ordinary concurrency bugs."},"body":{"format":"markdown","text":"## What people mean by it\n\nThe usual architecture is an **orchestrator** that decomposes a task and hands pieces to **workers**, each with its own prompt, its own tools and its own context, whose results the orchestrator combines.\n\nSometimes this is better. Often it is a single agent redrawn as a diagram, at three times the cost, and the honest question is which one you have.\n\n## The one thing it buys: context isolation\n\nThe strongest argument for splitting is not specialisation. It is that **each worker starts with a clean, short context**.\n\nA single agent researching six suppliers accumulates everything it has read. By supplier four it is carrying 60,000 tokens, every step is expensive, and the material about supplier one is competing for attention with the current question. Six workers each read about one supplier in an 8,000-token context and return a 300-token summary. The orchestrator sees 1,800 tokens instead of 60,000.\n\nThat is a real mechanism with real consequences: better attention on each subtask, lower per-step cost, and, because the subtasks are independent, the ability to run them in parallel and turn six sequential minutes into one.\n\nThe other genuine wins are narrower. **Different tool permissions** per worker, so the summariser cannot touch the tool that sends email. **A separate critic** that reviews the output without having produced it, which catches a real class of self-consistency errors. **Parallelism** on independent work.\n\n## What it costs\n\n**Tokens multiply.** Each worker pays its own system prompt and tool definitions. Anthropic's own published account of a multi-agent research system put the token consumption at roughly 15 times a single chat interaction. If your task is worth that, fine: for high-value research it may be. For a support reply it certainly is not.\n\n**Errors compound across the seam.** The orchestrator's decomposition can be wrong in ways no worker can detect. Give a worker a badly framed subtask and it will answer it well, which is worse than failing, because the wrong answer arrives with confidence and the orchestrator has no way to tell.\n\n**Information is lost at every boundary.** A worker's 300-token summary is a lossy compression of what it learned. The nuance the orchestrator needed may be exactly what was compressed away, and nobody can see that it happened.\n\n**Debugging gets much harder.** A bad final answer now requires tracing which worker got which subtask, what each returned, and how they were merged. Without per-worker traces this is close to impossible.\n\n**Cost and latency become unpredictable.** Six workers, each with its own step budget, is a cost ceiling that is the product of your budgets rather than the sum of your expectations.\n\n## The test before you build it\n\nBefore splitting, answer three questions honestly:\n\n1. **Are the subtasks independent?** If worker three needs what worker two found, you do not have parallel workers. You have a chain with extra overhead.\n2. **Can the orchestrator decompose the task reliably?** If you cannot write the decomposition rules yourself, the model probably cannot either.\n3. **Is the context actually large?** If a single agent runs comfortably in 15,000 tokens, the main benefit does not apply and you are paying for architecture.\n\nIf any answer is no, build one agent with good tools. It will be cheaper, faster and debuggable, and you can revisit this when you have a concrete measurement showing the single agent failing.\n\n## The shapes that work\n\nWhere multi-agent does earn its place, three patterns dominate.\n\n**Fan-out, fan-in.** Independent subtasks in parallel, results merged by the orchestrator. Research across sources, checking a document against ten policies, comparing suppliers. The cleanest case, because independence is real.\n\n**Generate then critique.** One agent produces, a second reviews against explicit criteria with the first agent's reasoning hidden. Effective for code and for writing. The critic must have its own criteria and must not see the generator's justification, or it agrees with it.\n\n**Router plus specialists.** A cheap classifier picks one specialist, which does all the work. Barely multi-agent (it is the routing chain from module two), and it delivers most of the benefit for a fraction of the cost. When someone proposes a multi-agent system, this is usually the version that should ship.\n\n## The state nobody designs\n\nOne practical warning. Multi-agent systems fail on shared state more often than on reasoning. Two workers writing to the same file, an orchestrator reading a result before the worker finished, a retry that re-runs a subtask whose side effect already happened.\n\nThis is ordinary concurrency, and it does not become easier because the participants are models. Give each worker its own workspace, make results immutable once returned, and keep every side effect in the orchestrator where there is exactly one of them."},"check":{"question":"A team splits a research assistant into an orchestrator and five workers. Latency improves, but answers now miss details the single agent used to include. What is the most likely cause?","options":[{"text":"The workers use a smaller model than the original agent did.","correct":false,"tempting":"Would degrade quality within each subtask, whereas the symptom is material disappearing between the subtasks and the final answer."},{"text":"Each worker returns a compressed summary, and detail the orchestrator needed was discarded at that boundary with no signal that it existed.","correct":true},{"text":"The orchestrator's context window is too small to hold five results.","correct":false,"tempting":"Five short summaries are precisely the case that fits easily; the loss happens before the orchestrator, not inside it."},{"text":"Parallel execution means the workers cannot see each other's findings.","correct":false,"tempting":"True of the design and sometimes a real cost, but it explains missed connections between subtasks rather than missing detail within one."}]},"prev":{"slug":"running-code-safely","title":"Letting a model run code without letting it run your machine","url":"https://addaly.com/learn/building-with-ai/running-code-safely"},"next":{"slug":"human-in-the-loop-handoff","title":"Approval gates, undo, and handing over to a person","url":"https://addaly.com/learn/building-with-ai/human-in-the-loop-handoff"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Multiple agents, and the honest cost', in Building with AI. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/building-with-ai/multi-agent-when-worth-it (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Multiple agents, and the honest cost","courseTitle":"Building with AI","module":{"index":3,"slug":"structure-tools-and-the-loop","title":"Structure, tools and the loop"},"answer":null,"keyIdea":"The real benefit of multiple agents is context isolation and parallelism on genuinely independent subtasks, paid for with roughly an order of magnitude more tokens, lossy summaries at each boundary and ordinary concurrency bugs.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"what-people-mean-by-it","runs":[{"text":"What people mean by it"}]},{"t":"p","runs":[{"text":"The usual architecture is an "},{"text":"orchestrator","b":true},{"text":" that decomposes a task and hands pieces to "},{"text":"workers","b":true},{"text":", each with its own prompt, its own tools and its own context, whose results the orchestrator combines."}]},{"t":"p","runs":[{"text":"Sometimes this is better. Often it is a single agent redrawn as a diagram, at three times the cost, and the honest question is which one you have."}]},{"t":"h2","id":"the-one-thing-it-buys-context-isolation","runs":[{"text":"The one thing it buys: context isolation"}]},{"t":"p","runs":[{"text":"The strongest argument for splitting is not specialisation. It is that "},{"text":"each worker starts with a clean, short context","b":true},{"text":"."}]},{"t":"p","runs":[{"text":"A single agent researching six suppliers accumulates everything it has read. By supplier four it is carrying 60,000 tokens, every step is expensive, and the material about supplier one is competing for attention with the current question. Six workers each read about one supplier in an 8,000-token context and return a 300-token summary. The orchestrator sees 1,800 tokens instead of 60,000."}]},{"t":"p","runs":[{"text":"That is a real mechanism with real consequences: better attention on each subtask, lower per-step cost, and, because the subtasks are independent, the ability to run them in parallel and turn six sequential minutes into one."}]},{"t":"p","runs":[{"text":"The other genuine wins are narrower. "},{"text":"Different tool permissions","b":true},{"text":" per worker, so the summariser cannot touch the tool that sends email. "},{"text":"A separate critic","b":true},{"text":" that reviews the output without having produced it, which catches a real class of self-consistency errors. "},{"text":"Parallelism","b":true},{"text":" on independent work."}]},{"t":"h2","id":"what-it-costs","runs":[{"text":"What it costs"}]},{"t":"p","runs":[{"text":"Tokens multiply.","b":true},{"text":" Each worker pays its own system prompt and tool definitions. Anthropic’s own published account of a multi-agent research system put the token consumption at roughly 15 times a single chat interaction. If your task is worth that, fine: for high-value research it may be. For a support reply it certainly is not."}]},{"t":"p","runs":[{"text":"Errors compound across the seam.","b":true},{"text":" The orchestrator’s decomposition can be wrong in ways no worker can detect. Give a worker a badly framed subtask and it will answer it well, which is worse than failing, because the wrong answer arrives with confidence and the orchestrator has no way to tell."}]},{"t":"p","runs":[{"text":"Information is lost at every boundary.","b":true},{"text":" A worker’s 300-token summary is a lossy compression of what it learned. The nuance the orchestrator needed may be exactly what was compressed away, and nobody can see that it happened."}]},{"t":"p","runs":[{"text":"Debugging gets much harder.","b":true},{"text":" A bad final answer now requires tracing which worker got which subtask, what each returned, and how they were merged. Without per-worker traces this is close to impossible."}]},{"t":"p","runs":[{"text":"Cost and latency become unpredictable.","b":true},{"text":" Six workers, each with its own step budget, is a cost ceiling that is the product of your budgets rather than the sum of your expectations."}]},{"t":"h2","id":"the-test-before-you-build-it","runs":[{"text":"The test before you build it"}]},{"t":"p","runs":[{"text":"Before splitting, answer three questions honestly:"}]},{"t":"ol","start":1,"items":[[{"text":"Are the subtasks independent?","b":true},{"text":" If worker three needs what worker two found, you do not have parallel workers. You have a chain with extra overhead."}],[{"text":"Can the orchestrator decompose the task reliably?","b":true},{"text":" If you cannot write the decomposition rules yourself, the model probably cannot either."}],[{"text":"Is the context actually large?","b":true},{"text":" If a single agent runs comfortably in 15,000 tokens, the main benefit does not apply and you are paying for architecture."}]]},{"t":"p","runs":[{"text":"If any answer is no, build one agent with good tools. It will be cheaper, faster and debuggable, and you can revisit this when you have a concrete measurement showing the single agent failing."}]},{"t":"h2","id":"the-shapes-that-work","runs":[{"text":"The shapes that work"}]},{"t":"p","runs":[{"text":"Where multi-agent does earn its place, three patterns dominate."}]},{"t":"p","runs":[{"text":"Fan-out, fan-in.","b":true},{"text":" Independent subtasks in parallel, results merged by the orchestrator. Research across sources, checking a document against ten policies, comparing suppliers. The cleanest case, because independence is real."}]},{"t":"p","runs":[{"text":"Generate then critique.","b":true},{"text":" One agent produces, a second reviews against explicit criteria with the first agent’s reasoning hidden. Effective for code and for writing. The critic must have its own criteria and must not see the generator’s justification, or it agrees with it."}]},{"t":"p","runs":[{"text":"Router plus specialists.","b":true},{"text":" A cheap classifier picks one specialist, which does all the work. Barely multi-agent (it is the routing chain from module two), and it delivers most of the benefit for a fraction of the cost. When someone proposes a multi-agent system, this is usually the version that should ship."}]},{"t":"h2","id":"the-state-nobody-designs","runs":[{"text":"The state nobody designs"}]},{"t":"p","runs":[{"text":"One practical warning. Multi-agent systems fail on shared state more often than on reasoning. Two workers writing to the same file, an orchestrator reading a result before the worker finished, a retry that re-runs a subtask whose side effect already happened."}]},{"t":"p","runs":[{"text":"This is ordinary concurrency, and it does not become easier because the participants are models. Give each worker its own workspace, make results immutable once returned, and keep every side effect in the orchestrator where there is exactly one of them."}]}],"check":{"question":[{"text":"A team splits a research assistant into an orchestrator and five workers. Latency improves, but answers now miss details the single agent used to include. What is the most likely cause?"}],"options":[{"text":[{"text":"The workers use a smaller model than the original agent did."}],"correct":false,"tempting":[{"text":"Would degrade quality within each subtask, whereas the symptom is material disappearing between the subtasks and the final answer."}]},{"text":[{"text":"Each worker returns a compressed summary, and detail the orchestrator needed was discarded at that boundary with no signal that it existed."}],"correct":true,"tempting":null},{"text":[{"text":"The orchestrator’s context window is too small to hold five results."}],"correct":false,"tempting":[{"text":"Five short summaries are precisely the case that fits easily; the loss happens before the orchestrator, not inside it."}]},{"text":[{"text":"Parallel execution means the workers cannot see each other’s findings."}],"correct":false,"tempting":[{"text":"True of the design and sometimes a real cost, but it explains missed connections between subtasks rather than missing detail within one."}]}],"order":[3,2,1,0],"why":null},"prev":{"slug":"running-code-safely","title":"Letting a model run code without letting it run your machine","minutes":9},"next":{"slug":"human-in-the-loop-handoff","title":"Approval gates, undo, and handing over to a person","minutes":8}}}