{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/en/autor/alexander-bock/"},"categories":["AI Development"],"content":{"markdown":"One agent with good tools can do a lot. But some tasks are too broad for one context window, or they need different skills and permissions. Then teams split the work: one agent plans, several research in parallel, another one checks the result. Done well, this raises quality. Done badly, it multiplies cost, errors and confusion.\n\nThis is part 3 of Level 4 (Expert) in our AI Development path. You will learn four proven patterns, when several agents help and when they hurt, how errors and costs compound, how to trace a multi-agent run and where people must check the work. It builds on [AI agents with tools, loops and memory](/en/ai-development/learn/build-ai-agents-tools-loops-memory/) from Level 3.\n\n## What makes a system multi-agent\n\nA **multi-agent system** consists of several agents, each with its own instructions, context, tools and permissions, that hand work to each other. Either your code coordinates them along fixed paths, or an agent decides at run time who does what. Anthropic calls the first kind a **workflow** and the second an **agent** in the narrow sense (Source: Anthropic, \"Building effective agents\", 2024). Many systems sold as multi-agent are really workflows — often good news, because fixed paths are easier to test.\n\nSeveral agents can bring real benefits:\n\n- **Clean contexts.** Each agent sees only what its subtask needs, instead of one overflowing context.\n- **Parallel work.** Independent subtasks run at the same time, which shortens the waiting time.\n- **Specialization.** Each role gets its own prompt, tools and, if useful, its own model.\n- **Least privilege.** A research agent can read but not send; only one agent may write.\n- **Independent review.** A second agent with its own instructions checks the work of the first.\n\nTwo open protocols connect the parts. The **Model Context Protocol** (MCP), published by Anthropic in November 2024, standardizes how agents access tools and data. The **Agent2Agent** protocol (A2A), announced by Google in April 2025, describes how agents from different systems exchange tasks.\n\n## Four proven patterns\n\nMost real systems are built from a few basic patterns:\n\n![Four panels with small diagrams: an orchestrator agent that hands tasks to three workers, a pipeline of three agents in a row, a generator and a reviewer in a loop, and three agents around a shared memory, each with what it is good for and its main risk](/images/learn/en/multi-agent-systems-patterns.webp \"Four basic patterns. Many real systems combine two of them.\")\n\nThe table lists the four patterns and adds debate, a research variant of the reviewer pattern:\n\n| Pattern | Good for | Main risk | Control |\n|---|---|---|---|\n| Orchestrator and workers | Broad research, parallel subtasks | Duplicate work, vague briefs | A precise brief per worker: goal, output format, limits, tools |\n| Pipeline | Fixed stages such as extract, check, write | Errors flow downstream | Schema validation between stages |\n| Generator and reviewer | Drafts with clear quality criteria | Endless loops, shared blind spots | A round limit; a rubric or another model for the reviewer |\n| Debate or voting | Hard questions with checkable answers | Cost grows with every agent; agreement on a wrong answer | Use only where your evals show a gain |\n| Shared memory | Long tasks that build on findings | Conflicting entries; one wrong note misleads all | One writer, versioned entries with sources |\n\nThe orchestrator-worker pattern is the best documented. In Anthropic's research system, a lead agent plans the research, starts subagents that search in parallel and combines their findings. With Claude Opus 4 as the lead and Claude Sonnet 4 as subagents, it outperformed a single Claude Opus 4 agent by 90.2 percent on Anthropic's internal research eval. The analysis also explains much of the gain: on a browsing benchmark, token usage alone explained 80 percent of the differences in results. Several agents work partly because they can spend more tokens in parallel (Source: Anthropic, \"How we built our multi-agent research system\", 2025).\n\nIn a debate, several instances of a model answer, read each other's answers and revise them over several rounds. In experiments by researchers at MIT and Google Brain, this improved factual accuracy and reasoning (Source: Du et al., \"Improving Factuality and Reasoning in Language Models through Multiagent Debate\", 2023, arxiv.org).\n\n## When several agents help — and when they hurt\n\nTwo questions decide: how many parts of the task can run in parallel, and how independent are those parts?\n\n![Two-by-two matrix with the number of parallel subtasks on the horizontal axis and their independence on the vertical axis: a workflow or pipeline for few independent subtasks, orchestrator and workers for many independent ones, one agent for few coupled ones, and many readers with one writer for many coupled ones](/images/learn/en/multi-agent-systems-decide.webp \"Parallel, independent subtasks favor several agents. Coupled work favors one agent, or many readers with one writer.\")\n\nTightly coupled work is the classic trap. Anthropic notes that most coding tasks contain fewer truly parallel parts than research. Cognition, the maker of the coding agent Devin, argues that every action carries hidden decisions about style, names or edge cases. Parallel agents that cannot see each other's decisions then produce parts that do not fit together (Source: Cognition, \"Don't Build Multi-Agents\", 2025). In 2026, the same company reported that multi-agent setups work best today when \"writes stay single-threaded\": several agents may analyze or review, but only one changes the code (Source: Cognition, \"Multi-Agents: What's Actually Working\", 2026).\n\nResearch confirms that coordination itself is a source of failure. A study of popular multi-agent frameworks grouped 14 failure modes into three categories: weak system design and task specification, misalignment between agents, and poor verification and termination (Source: Cemri et al., \"Why Do Multi-Agent LLM Systems Fail?\", 2025, arxiv.org). Hence the rule: start with one agent, measure a baseline on your eval set, and add agents only when the measured gain justifies the extra cost.\n\n## Errors and costs compound\n\nEvery step and every handoff can fail. If each step succeeds independently 95 percent of the time, a chain of ten steps succeeds only about 60 percent of the time:\n\n![Line chart: the chance that all steps succeed falls with the number of steps; at ten steps it is about 90 percent with 99 percent reliability per step, about 60 percent with 95 percent and about 35 percent with 90 percent](/images/learn/en/multi-agent-systems-compounding.webp \"Error compounding in a chain of independent steps. A calculation, not a measurement.\")\n\nReal errors are not fully independent, but the direction holds: long chains need checks between the steps. Validate each handoff against a schema, let a step retry on its own before the whole task restarts, and save intermediate results so that a run can resume.\n\nCosts compound as well. Every agent reads its own context, and many re-read what others wrote. In Anthropic's data, agents used about four times as many tokens as chat interactions, and multi-agent systems about 15 times as many (Source: Anthropic, 2025, see above). Set a token budget per task and per agent, and consider lighter models for workers with simple jobs.\n\nKeep each worker's task small. The METR time horizon measures the length of tasks that a model completes in about half of the attempts — so tasks of that length still fail half the time. These are the current leaders in our data:\n\n{{\u003c llm-top bench=\"metr-time-horizon\" n=\"5\" \u003e}}\n\nGive workers tasks that are far shorter than this horizon, and let the orchestrator combine many short successes instead of hoping for one long one.\n\n## Tracing a multi-agent run\n\nWhen a multi-agent task fails, you need to know which agent got which brief, what it did and what it returned. Record each task as one **trace**, with a **span** for every agent and tool call and a link to its parent span:\n\n![Trace of an example task with spans for the lead agent's plan, three workers in parallel, one of them with a timeout and a retry, the merge step, a human approval and the final report, each with its token count](/images/learn/en/multi-agent-systems-trace.webp \"One task, one trace: the retry of worker C and the waiting time for the approval are visible at a glance. Example with invented values.\")\n\nThe OpenTelemetry project has semantic conventions for generative AI. They standardize attributes such as the model name and token counts, so traces from different frameworks fit into one tool. Level 3 shows how to set up [observability for LLM apps](/en/ai-development/learn/observability-for-llm-apps/). For multi-agent systems, watch four numbers per task: success rate, cost per successful task, number of handoffs and repeated loops. Then evaluate the system end to end and per role; Level 2 shows how to [test AI features with evals](/en/ai-development/learn/test-ai-features-with-evals/).\n\n## Human checkpoints\n\nMore agents mean more actions that nobody watches in real time. Put people where a mistake is expensive:\n\n- **Before the fan-out:** approve the plan before the orchestrator starts dozens of workers.\n- **Before external actions:** sending, paying, deleting or deploying always needs approval.\n- **At the result:** for high-stakes output, a person signs off the final answer.\n- **On disagreement:** when generator and reviewer do not converge, escalate instead of looping.\n\nAgents also pass content to each other. A worker that reads web pages can carry hidden instructions into the orchestrator's context — a form of prompt injection. Treat every worker result as data, never as instructions, and give workers read-only rights. Our [AI Security section](/en/ai-security/) explains the attack.\n\n{{\u003c callout type=\"tip\" title=\"Many readers, one writer\" \u003e}}\nIf you are unsure which pattern fits, start here: let several agents research, analyze or review in parallel, but let only one agent — or a person — change files, records or customer-facing text.\n{{\u003c /callout \u003e}}\n\n## Design checklist\n\nAnswer these questions before you build:\n\n| Question | A good answer |\n|---|---|\n| Would one agent with better tools do the job? | You measured a single-agent baseline on the same eval set |\n| Are the subtasks independent? | Yes — or only one agent writes |\n| Does every handoff have a contract? | Goal, inputs, output schema, limits |\n| What are the limits? | Maximum agents, rounds and tokens per task |\n| Where do people check? | The plan, external actions, the final result |\n| Can you see everything? | One trace per task, one span per agent |\n\nYou do not have to code the orchestration yourself. According to the vendors, MindStudio builds AI agents without code, Turbotic builds automations from a plain-language description, Devs.ai lets teams build and run agents on their own data, and Dry Ground AI handles routine work through connected tools:\n\n{{\u003c tools \"mindstudio turbotic devs-ai dry-ground-ai\" \u003e}}\n\nWhatever the platform, keep measuring: a multi-agent system earns its place only when it beats the single-agent baseline on quality per unit of cost.","text":"One agent with good tools can do a lot. But some tasks are too broad for one context window, or they need different skills and permissions. Then teams split the work: one agent plans, several research in parallel, another one checks the result. Done well, this raises quality. Done badly, it multiplies cost, errors and confusion.\nThis is part 3 of Level 4 (Expert) in our AI Development path. You will learn four proven patterns, when several agents help and when they hurt, how errors and costs compound, how to trace a multi-agent run and where people must check the work. It builds on AI agents with tools, loops and memory from Level 3.\nWhat makes a system multi-agent A multi-agent system consists of several agents, each with its own instructions, context, tools and permissions, that hand work to each other. Either your code coordinates them along fixed paths, or an agent decides at run time who does what. Anthropic calls the first kind a workflow and the second an agent in the narrow sense (Source: Anthropic, \u0026ldquo;Building effective agents\u0026rdquo;, 2024). Many systems sold as multi-agent are really workflows — often good news, because fixed paths are easier to test.\nSeveral agents can bring real benefits:\nClean contexts. Each agent sees only what its subtask needs, instead of one overflowing context. Parallel work. Independent subtasks run at the same time, which shortens the waiting time. Specialization. Each role gets its own prompt, tools and, if useful, its own model. Least privilege. A research agent can read but not send; only one agent may write. Independent review. A second agent with its own instructions checks the work of the first. Two open protocols connect the parts. The Model Context Protocol (MCP), published by Anthropic in November 2024, standardizes how agents access tools and data. The Agent2Agent protocol (A2A), announced by Google in April 2025, describes how agents from different systems exchange tasks.\nFour proven patterns Most real systems are built from a few basic patterns:\nFour basic patterns. Many real systems combine two of them. The table lists the four patterns and adds debate, a research variant of the reviewer pattern:\nMulti-Agent Systems: Patterns and Pitfalls Pattern Good for Main risk Control Orchestrator and workers Broad research, parallel subtasks Duplicate work, vague briefs A precise brief per worker: goal, output format, limits, tools Pipeline Fixed stages such as extract, check, write Errors flow downstream Schema validation between stages Generator and reviewer Drafts with clear quality criteria Endless loops, shared blind spots A round limit; a rubric or another model for the reviewer Debate or voting Hard questions with checkable answers Cost grows with every agent; agreement on a wrong answer Use only where your evals show a gain Shared memory Long tasks that build on findings Conflicting entries; one wrong note misleads all One writer, versioned entries with sources The orchestrator-worker pattern is the best documented. In Anthropic\u0026rsquo;s research system, a lead agent plans the research, starts subagents that search in parallel and combines their findings. With Claude Opus 4 as the lead and Claude Sonnet 4 as subagents, it outperformed a single Claude Opus 4 agent by 90.2 percent on Anthropic\u0026rsquo;s internal research eval. The analysis also explains much of the gain: on a browsing benchmark, token usage alone explained 80 percent of the differences in results. Several agents work partly because they can spend more tokens in parallel (Source: Anthropic, \u0026ldquo;How we built our multi-agent research system\u0026rdquo;, 2025).\nIn a debate, several instances of a model answer, read each other\u0026rsquo;s answers and revise them over several rounds. In experiments by researchers at MIT and Google Brain, this improved factual accuracy and reasoning (Source: Du et al., \u0026ldquo;Improving Factuality and Reasoning in Language Models through Multiagent Debate\u0026rdquo;, 2023, arxiv.org).\nWhen several agents help — and when they hurt Two questions decide: how many parts of the task can run in parallel, and how independent are those parts?\nParallel, independent subtasks favor several agents. Coupled work favors one agent, or many readers with one writer. Tightly coupled work is the classic trap. Anthropic notes that most coding tasks contain fewer truly parallel parts than research. Cognition, the maker of the coding agent Devin, argues that every action carries hidden decisions about style, names or edge cases. Parallel agents that cannot see each other\u0026rsquo;s decisions then produce parts that do not fit together (Source: Cognition, \u0026ldquo;Don\u0026rsquo;t Build Multi-Agents\u0026rdquo;, 2025). In 2026, the same company reported that multi-agent setups work best today when \u0026ldquo;writes stay single-threaded\u0026rdquo;: several agents may analyze or review, but only one changes the code (Source: Cognition, \u0026ldquo;Multi-Agents: What\u0026rsquo;s Actually Working\u0026rdquo;, 2026).\nResearch confirms that coordination itself is a source of failure. A study of popular multi-agent frameworks grouped 14 failure modes into three categories: weak system design and task specification, misalignment between agents, and poor verification and termination (Source: Cemri et al., \u0026ldquo;Why Do Multi-Agent LLM Systems Fail?\u0026rdquo;, 2025, arxiv.org). Hence the rule: start with one agent, measure a baseline on your eval set, and add agents only when the measured gain justifies the extra cost.\nErrors and costs compound Every step and every handoff can fail. If each step succeeds independently 95 percent of the time, a chain of ten steps succeeds only about 60 percent of the time:\nError compounding in a chain of independent steps. A calculation, not a measurement. Real errors are not fully independent, but the direction holds: long chains need checks between the steps. Validate each handoff against a schema, let a step retry on its own before the whole task restarts, and save intermediate results so that a run can resume.\nCosts compound as well. Every agent reads its own context, and many re-read what others wrote. In Anthropic\u0026rsquo;s data, agents used about four times as many tokens as chat interactions, and multi-agent systems about 15 times as many (Source: Anthropic, 2025, see above). Set a token budget per task and per agent, and consider lighter models for workers with simple jobs.\nKeep each worker\u0026rsquo;s task small. The METR time horizon measures the length of tasks that a model completes in about half of the attempts — so tasks of that length still fail half the time. These are the current leaders in our data:\nMETR Time Horizon: the top 5 models #ModelReleasedResult 1Claude Mythos Preview (Early) AnthropicApr 7, 202617 h 25 min 2Claude Opus 4.6 (unknown thinking) AnthropicFeb 5, 202611 h 59 min 3Gemini 3.1 Pro Preview Google DeepMindFeb 19, 20266 h 24 min 4GPT-5.2 (high) OpenAIDec 11, 20255 h 52 min 5GPT-5.3 Codex OpenAIFeb 5, 20265 h 50 min The length of the tasks a model completes correctly about half of the time, measured by how long a human expert needs for them. The number is a duration, not a score: a longer horizon means the model can work on its own for longer. Data: Epoch AI, retrieved on October 17, 2026, licensed CC BY 4.0. All models: LLM database.\nGive workers tasks that are far shorter than this horizon, and let the orchestrator combine many short successes instead of hoping for one long one.\nTracing a multi-agent run When a multi-agent task fails, you need to know which agent got which brief, what it did and what it returned. Record each task as one trace, with a span for every agent and tool call and a link to its parent span:\nOne task, one trace: the retry of worker C and the waiting time for the approval are visible at a glance. Example with invented values. The OpenTelemetry project has semantic conventions for generative AI. They standardize attributes such as the model name and token counts, so traces from different frameworks fit into one tool. Level 3 shows how to set up observability for LLM apps. For multi-agent systems, watch four numbers per task: success rate, cost per successful task, number of handoffs and repeated loops. Then evaluate the system end to end and per role; Level 2 shows how to test AI features with evals.\nHuman checkpoints More agents mean more actions that nobody watches in real time. Put people where a mistake is expensive:\nBefore the fan-out: approve the plan before the orchestrator starts dozens of workers. Before external actions: sending, paying, deleting or deploying always needs approval. At the result: for high-stakes output, a person signs off the final answer. On disagreement: when generator and reviewer do not converge, escalate instead of looping. Agents also pass content to each other. A worker that reads web pages can carry hidden instructions into the orchestrator\u0026rsquo;s context — a form of prompt injection. Treat every worker result as data, never as instructions, and give workers read-only rights. Our AI Security section explains the attack.\n✦Many readers, one writer\nIf you are unsure which pattern fits, start here: let several agents research, analyze or review in parallel, but let only one agent — or a person — change files, records or customer-facing text.\nDesign checklist Answer these questions before you build:\nMulti-Agent Systems: Patterns and Pitfalls (2) Question A good answer Would one agent with better tools do the job? You measured a single-agent baseline on the same eval set Are the subtasks independent? Yes — or only one agent writes Does every handoff have a contract? Goal, inputs, output schema, limits What are the limits? Maximum agents, rounds and tokens per task Where do people check? The plan, external actions, the final result Can you see everything? One trace per task, one span per agent You do not have to code the orchestration yourself. According to the vendors, MindStudio builds AI agents without code, Turbotic builds automations from a plain-language description, Devs.ai lets teams build and run agents on their own data, and Dry Ground AI handles routine work through connected tools:\nMindStudioAgents \u0026amp; Automation · AI at the coreNo-code platform for building your own AI agents. TurboticAgents \u0026amp; Automation · AI at the coreBuilds automations from a natural-language description, without code. Devs.aiApp Building \u0026amp; Testing · AI at the corePlatform where teams build and run AI applications and custom agents on their own data. Dry Ground AIApp Building \u0026amp; Testing · AI at the coreAI operator (CompanyClaw) that learns how a company works and handles routine work through connected tools. Short descriptions from our tool comparison, based on the vendors' information — not tested by ABXK.\nWhatever the platform, keep measuring: a multi-agent system earns its place only when it beats the single-agent baseline on quality per unit of cost.\n","words":1752},"date":"2026-10-14","description":"When several AI agents beat one: orchestrator-worker, pipeline, review and shared-memory patterns, error compounding, cost, tracing and human checkpoints.","image":"https://abxk.ai/images/cover/multi-agent-systems.webp","json":"https://abxk.ai/en/ai-development/learn/multi-agent-systems/index.json","kind":"page","language":"en","learning_path":{"category":"ai-development","level":4,"level_name":"Expert"},"modified":"2026-10-14","related_tools":["MindStudio","Turbotic","Devs.ai","Dry Ground AI"],"section":"ai-development","tags":["multi-agent-systems","ai-agents","orchestration","observability","expert"],"title":"Multi-Agent Systems: Patterns and Pitfalls","translations":[{"json":"https://abxk.ai/de/ai-development/learn/multi-agent-systems/index.json","language":"de","url":"https://abxk.ai/de/ai-development/learn/multi-agent-systems/"}],"url":"https://abxk.ai/en/ai-development/learn/multi-agent-systems/"}