Deep Dive into Design Patterns and Common Pitfalls of Multi-Agent Systems

A Reality Check for Multi-Agent Systems

As large language model capabilities continue to advance, single Agents can no longer meet the processing demands of complex tasks. The industry is rapidly shifting toward Multi-Agent Systems (MAS)—leveraging multiple AI Agents working collaboratively to accomplish highly complex tasks such as research, coding, and analysis.

The concept of multi-agent systems originally emerged from distributed artificial intelligence, extensively studied in academia since the 1980s. Traditional multi-agent systems emphasize four key characteristics: autonomy, social ability, reactivity, and proactiveness. In the era of large language models, this concept has been redefined—each Agent is essentially an LLM instance equipped with a System Prompt, tool-calling capabilities, and memory mechanisms. Unlike traditional rule-based multi-agent systems, LLM-based multi-agent systems possess stronger general reasoning abilities and natural language interaction capabilities, but they also inherit the inherent hallucination and uncertainty issues of LLMs.

Anthropic's recent in-depth sharing on multi-agent system patterns and problems represents a systematic retrospective on this trend, summarizing both the successful experiences and candidly revealing the failure lessons from their Claude agent clusters.

This summary from frontline engineering practice holds immense reference value for developers and teams currently building or considering multi-agent architectures. It reminds us: multi-agent is not a silver bullet—its power and pitfalls are equally significant.

Why Multi-Agent Systems Deserve Attention

Evolution from Single Agent to Agent Clusters

Traditional single Agents often fall short when facing tasks that require parallel exploration, multi-perspective verification, or ultra-long context handling. The core idea of multi-agent architecture is divide and conquer: an Orchestrator Agent handles task decomposition and scheduling, multiple sub-Agents process their respective subtasks in parallel, and results are aggregated at the end.

The Orchestrator pattern is one of the most common architectural patterns in multi-agent systems, also known as the Hub-and-Spoke pattern. In this architecture, the orchestrator Agent assumes a role similar to a project manager—it receives the user's high-level objectives, decomposes them into executable subtasks, assigns them to specialized sub-Agents, then collects and synthesizes results. Alternative approaches include decentralized patterns (direct Agent-to-Agent communication) and hierarchical patterns (multi-layered Agent tree structures). Anthropic's practice shows that the Orchestrator pattern provides the best balance of controllability and debuggability in most scenarios.

The advantages of this multi-Agent collaborative model are straightforward:

• Parallel acceleration: Multiple Agents working simultaneously significantly reduce completion time for complex tasks.
• Context expansion: Each sub-Agent has its own independent context window, effectively expanding the entire system's memory capacity. The context window of a large language model refers to the maximum number of tokens the model can process in a single inference. Even though the most advanced models today have expanded context windows to 100K or even 200K tokens, they still struggle when analyzing large codebases or conducting comprehensive research across lengthy documents. Multi-agent architecture effectively multiplies the system's total information processing capacity by the number of Agents, as each sub-Agent independently maintains its own context window. However, this introduces a core challenge: information is not shared across Agents and requires explicit message passing or shared memory mechanisms to achieve cross-Agent knowledge synchronization.
• Specialized division of labor: Different Agents can be assigned different roles and tool permissions for specialized processing.

The Applicable Boundaries of Multi-Agent Systems

However, Anthropic's practice clearly demonstrates that multi-agent systems are not suitable for all tasks. They work best for scenarios that naturally decompose into parallel subtasks with low coupling between them—deep research being a typical example, requiring parallel collection and cross-validation of information from multiple sources. Conversely, for highly linear tasks with strong step-to-step dependencies, the coordination overhead of multiple Agents can actually drag down overall efficiency.

Successful Patterns in Multi-Agent Systems

Clear Task Decomposition and Role Definition

The success or failure of multi-agent systems largely depends on whether the orchestrator Agent can clearly decompose tasks and issue unambiguous instructions. Vague task descriptions lead to overlapping work between sub-Agents, directional drift, or even mutual conflicts. Successful practices typically provide each sub-Agent with:

• Clear goal boundaries
• Explicit output format requirements
• Defined tool access and permission scope

Quality Improvement Through Parallel Exploration

In research-oriented tasks, multiple sub-Agents gathering information in parallel from different angles can significantly improve the breadth and robustness of results. Compared to a single Agent's linear search, the Agent cluster approach is less likely to fall into information echo chambers and can cover more comprehensive perspectives. This is the key reason why research-oriented products were among the first to adopt multi-agent architectures.

Core Pitfalls of Multi-Agent Systems

Surging Token and Compute Costs

The most direct cost of multi-agent systems is cost explosion. Multiple Agents running in parallel, combined with repeated communication between the orchestrator and sub-Agents, can result in token consumption that is several times or even ten-plus times that of a single Agent.

Tokens are the basic billing unit for large language models, with output tokens typically priced at 3-5x the cost of input tokens. In multi-agent systems, token consumption comes from multiple layers: each sub-Agent's independent reasoning, task descriptions and result transfers between the orchestrator and sub-Agents, and potentially multiple rounds of iterative interaction. For a typical deep research task, a single Agent might consume 50,000 tokens, while five parallel sub-Agents plus orchestration overhead could reach 300,000-500,000 tokens. At current pricing for models like Claude, this means per-task costs could jump from a few cents to several dollars—for high-frequency production systems, the cost difference is orders of magnitude.

The economics of this architecture only hold when the task value is high enough to amortize the costs. For most everyday tasks, a single Agent or simple workflow is actually more cost-effective.

Coordination and State Synchronization Complexity

As Agent count increases, the system's coordination complexity grows non-linearly. How sub-Agents share information, avoid duplicated work, and handle contradictory intermediate results are all highly challenging engineering problems. Once a sub-Agent produces erroneous intermediate output, that error can propagate and amplify throughout the system.

Error Accumulation and Debugging Difficulty

Another major pain point of multi-agent systems is poor observability and difficult debugging. When the final result is problematic, it's extremely hard to pinpoint which Agent and which step went wrong. The system's non-determinism means the same input may produce different execution paths, creating enormous challenges for testing and iteration.

Observability is a concept borrowed from distributed systems engineering, traditionally comprising three pillars: Logs, Metrics, and Traces. In multi-agent systems, observability faces additional challenges: Agent behavior is non-deterministic with potentially different reasoning paths each execution; message passing between Agents forms complex Call Graphs; and each Agent's internal "thinking process" (such as Chain-of-Thought) also needs to be captured and analyzed. Currently, tools like LangSmith, Braintrust, and Arize are building observability platforms for LLM applications, but end-to-end tracing and attribution analysis in multi-agent scenarios remains an active technical frontier.

Engineering Best Practices for Multi-Agent Systems

Start Simple and Scale Up as Needed

The pragmatic engineering principle is: don't adopt multi-agent for the sake of multi-agent. Teams should start with the simplest single Agent or Prompt Chaining approach, and only consider introducing multi-agent architecture when tasks genuinely require parallel processing and single Agent performance has hit a bottleneck. Premature complexity only brings cost and maintenance burden.

Prompt Chaining is a lighter-weight task orchestration approach compared to multi-agent systems. It decomposes complex tasks into multiple sequentially executed steps, where each step's output serves as the next step's input, but uses only a single LLM instance throughout. This approach avoids the coordination complexity and communication overhead of parallel multi-Agent execution while maintaining the benefits of task decomposition. In Anthropic's proposed Agent system maturity ladder, Prompt Chaining sits between single calls and full Agents, serving as the intermediate solution most teams should try before moving toward multi-agent. Only when a task's parallelism requirements and independent context needs clearly exceed Prompt Chaining capabilities should multi-agent architecture be introduced.

Invest in Evaluation Systems and Observability

Given the debugging difficulty of multi-agent systems, establishing comprehensive evaluation systems and end-to-end tracing capabilities is crucial. Developers need to observe each Agent's inputs and outputs, decision processes, and resource consumption to effectively optimize and troubleshoot.

Rigorously Weigh Cost Against Value

Any multi-agent solution deployment must come back to cost-benefit analysis. Multi-agent systems are truly worthwhile only when the task's inherent value far exceeds the additional compute overhead, and the quality improvements from parallelization are sufficiently significant.

Conclusion

Anthropic's sharing on multi-agent system patterns and problems presents a remarkably candid and complete picture of this cutting-edge architecture. It affirms the enormous potential of multi-agent systems in specific scenarios while unflinchingly addressing the serious challenges in cost, complexity, and maintainability.

For the AI engineering community, summaries grounded in real production experience are far more valuable than theoretical advocacy. Building reliable AI systems always requires careful trade-offs between capability, cost, and complexity. Multi-agent systems are powerful tools, but using them well requires clear-headed judgment rather than blind following.