The Craft of Multi-Agent Collaboration Design

In the previous article, we explored why the structural limitations of a single LLM demand a shift toward multi-agent systems (MAS), how the Collaborative Scaling Law validates this direction, and how Test-time Compute Scaling and Agent Scaling intersect. In this article, we dive one step deeper. First, we will examine from the perspective of emergent intelligence why a multi-agent system is not simply "multiple agents," and then we will address in detail the key decisions faced during actual design—topology, collaboration strategies, communication protocols, and evaluation frameworks.

Limitations of Single Agent Systems (Recap.)

Let's briefly recap the reasons for designing multi-agent systems. The limitations of a single agent can be summarized in four dimensions.

1. Lack of Parallelism. A single agent fundamentally must finish one task before it can proceed to another. In complex work where research, coding, and review need to happen simultaneously, sequential processing becomes a severe bottleneck.

2. Mixing of State and Memory. Because a Single Agent changes roles within the same conversation/task context, memories and contexts easily get mixed up. Once an incorrectly generated token or assumption is introduced, all subsequent generation proceeds conditioned on that error [1]. This is an inherent problem arising from the autoregressive nature of LLMs.

3. Limitations of Independent Verification / Mutual Checks. Internal critic/verification within a single agent is fundamentally self-censorship by the same model. In a structure where the same model looks at the same context to review its own answer, self-rationalization occurs instead of independent checks. As the ICLR 2024 study by Huang et al. revealed, there are clear limits to the effectiveness of intrinsic self-correction [2].

4. Security / Single Point of Failure. If a single agent fails or is hacked, the entire system becomes inoperable. In a multi-agent system, even if one agent fails, other agents can take over or the system can degrade gracefully.

To overcome these four limitations, we must now design how agents will collaborate. But before that, I would first like to share a perspective on why a multi-agent system is more than just "creating multiple agents."

Emergent Intelligence of Multi-Agents

A multi-agent system goes beyond simply spinning up multiple agents. Once models reach a certain level of intelligence, one of the most effective ways to elevate system performance to the next level shifts to how you make multiple agents cooperate. Rather than merely summing up the capabilities of individual agents, a system-level capability emerges that individual agents could not achieve on their own, depending on how the agents are structured and interact.
While individual humans have not become dramatically smarter over the past 100,000 years, human society has become exponentially more powerful in the information age thanks to collective intelligence and coordination capabilities [3]. Through the division of labor, markets, institutions, and communication infrastructure, the capabilities of countless individuals have combined to produce civilization-level outputs. The same logic applies to AI agents. Even agents with general intelligence that hit a wall when working alone can produce results that far exceed the simple sum of individual agents when organized into a properly coordinated group of agents.
From this perspective, the core capabilities that a truly powerful AI system must possess can be summarized in four categories.

1. Adaptivity—dynamically responding to changing environments.

2. Context-Awareness—maintaining persistent states and memory.

3. Conflict Resolution—mediating between conflicting demands.

4. Long-term Planning—coordinating multiple actions and making long-term decisions.

Demanding a single model to deliver all four of these at the highest level simultaneously is inefficient, but in a multi-agent system, each capability can be distributed and implemented through the collaboration of specialized agents. In academia, this perspective has recently been formalized under the name "patchwork AGI hypothesis." It argues that general-intelligence-level capabilities can manifest first through the coordination of sub-AGI agents with complementary abilities [4].
How, then, should we design this collaboration in detail?

Three Paradigms of Collaboration Strategies

The ways in which agents cooperate can be broadly classified into three paradigms. Rule-based collaboration is the simplest form. Multiple agents each produce their own answers to the same problem, and the final result is determined via Majority Voting. Self-Consistency [5] is a representative example. It is simple to implement and yields predictable results, but since no actual information exchange occurs between agents, its limitations are clear in complex tasks.
Role-based collaboration is a method that mimics actual organizational structures. Product Managers, Solution Architects, Developers, and QAs perform their respective specialized roles, and frameworks like MetaGPT [6] or ChatDev [7] adopt this approach. When a request like "Write a product launch report + risk assessment" comes in, an Orchestrator deconstructs it and assigns the research phase to a Research role and the analysis to an Analysis role. It is essentially the same principle as dividing work in an organization.
Model-based collaboration is the most advanced paradigm. This is a Theory of Mind (ToM)-based approach where agents probabilistically infer the intentions or states of other agents. Predicting and adapting to the opponent's strategy in game environments is a prime example, and while it is powerful in environments with high uncertainty, its implementation complexity is considerably high.
The key insight here is that even within a single task, these strategies can be mixed and dynamically shifted. Often, the most effective pattern in actual production systems is a Coopetition pattern, where agents initially cooperate (Cooperation), switch to competition (Competition) as a Critic agent appears, and ultimately converge again toward the shared goal of a better outcome.

Collaboration Topology: Structure Determines Performance

Once the collaboration strategy is decided, the next decision is how to connect the agents structurally.

Figure 1. Agent Collaboration Topology.

Compare various topology structures at a glance, including Single Agent, Network, Supervisor, Supervisor (as tools), Hierarchical, and Custom. (source: langchain-ai)
In a Network (Peer-to-Peer) structure, all agents can communicate directly with each other. It is extremely flexible, but as the number of agents grows, the communication complexity increases to O(n²). It is suitable for situations like brainstorming or debates where diverse perspectives must cross paths freely.
A Supervisor structure features a central manager agent that distributes tasks to subordinate agents and collects the results. Control flow is clear, making debugging easy, but the Supervisor can become a bottleneck. The "Supervisor as tools" pattern, frequently used in LangGraph, is a variation where the Supervisor calls subordinate agents as if they were tools, offering the advantage of being able to reuse agents like functions.
A Hierarchical structure is a multi-layered structure with another Supervisor under a Supervisor. It closely resembles an actual corporate organizational chart and is suitable for large-scale, complex systems.

In practice, these structures are rarely used in their pure forms. Taking the proposal writing MAS we designed internally as an example, while it is a Supervised structure where a Proposal Manager oversees the whole process, a Network (Swarm) structure is formed between the Solution Architect and the Pricing Agent because the technical design and the quotation must influence each other. It is a hybrid topology where Supervised and Swarm coexist within a single system.

Figure 2. Proposal Writing MAS — A Practical Example of Hybrid Topology.

While the Proposal Manager (Supervisor) oversees the entire process, a Network (Swarm) structure between the Solution Architect ↔ Pricing Agent, a Competition structure between the Writer Agent ↔ Critic Agent, and Dynamic Spawn via the HR Coordinator coexist.
The important point is not that one topology is unconditionally superior, but that you must select the appropriate structure based on the characteristics of the task.

Cooperation, Competition, Coopetition: Designing Incentive Structures

If topology represents the structure, the nature of interactions between agents corresponds to the incentive structure.

Figure 3. Agent Collaboration Type. (a) Cooperation: Editor, Researcher, Translator, and Verifier cooperate in writing an academic paper. (b) Competition: Prosecutor and Defendant oppose each other in a courtroom simulation. (c) Coopetition: Agreeing and opposing agents compete in policy decision-making but converge toward a common goal [11].

In Cooperation, all agents divide labor toward a common goal. A representative example is an academic paper writing system where an Editor edits the document, a Researcher conducts research, a Translator translates, and a Verifier inspects the quality.
In Competition, agents have opposing goals. An example is a courtroom simulation where a Prosecutor tries to prove guilt and a Defendant argues innocence. This Adversarial Debate structure is effective in improving the quality of arguments and is also utilized to catch hallucinations in LLMs. A typical pattern involves a Writer drafting a piece, a Critic pointing out omissions and weaknesses, the Writer revising, and the Critic reviewing again in an iterative loop until quality converges.
Coopetition (Cooperation + Competition) is the most sophisticated form. In a policy-making system, supporting and opposing agents present their arguments while ultimately cooperating for the common goal of making a "better policy decision." The key here is Negotiation.
These three are not discrete categories but a spectrum, and they can shift dynamically even within the same system as the task progresses.

Static vs Dynamic Orchestration: The Cost of Flexibility

One of the most critical design decisions in orchestration is choosing between Static vs Dynamic.
In the Static approach, everything is predefined. "Agent A is always the Critic, and Agent B is always the Writer." Roles and agent identities are fixed. It is predictable and simple to implement, but lacks flexibility.
The Dynamic approach is divided into two forms.
First, in Dynamic Role Allocation, roles themselves are predefined, but who will perform them is decided at runtime. For example, suppose there are three candidates to perform the Critic role—a light Critic, a strict Critic, and a security-specialized Critic. If the draft quality is low, the strict Critic is called, and right before final submission, the security-specialized Critic is called.
Second, Dynamic Agent Spawning involves creating agents with entirely new roles on the fly. If a market research role suddenly becomes necessary at Step 3, the Orchestrator creates and deploys a new agent instance with a Surveying persona. Once the task is complete, the instance can be removed to save resources.
A particularly powerful case of this Dynamic approach in production is in the proposal writing system we designed. When the deadline is tight but the workload is heavy, the Proposal Manager requests additional resources from the HR Coordinator Agent. Based on a capability database, the HR Coordinator creates the optimal persona, decides which tools to attach and which databases to grant access to, and spawns a new Writer Agent to join the task. AutoGen's GroupChatManager is a representative implementation that handles such dynamic turn allocation and routing [8].
When building actual production-level Multi-Agent Systems, this Static vs Dynamic decision largely dictates the system's flexibility and complexity.

Communication Protocols: How Information Flows

The efficiency of communication among agents directly impacts overall system performance. Let's compare two contrasting approaches.
MetaGPT — Representative of Vertical Architecture

Figure 4. MetaGPT’s SOP-based Collaboration Structure.

Product Manager → Architect → Project Manager → Engineer → QA Engineer follow a vertical division of labor, sharing information through a publish-subscribe mechanism [6].
MetaGPT [6] is a representative case of Vertical Architecture. This system's key contributions are twofold: one is enforcing structured outputs to prevent meaningless conversational noise between agents, and the other is introducing a publish-subscribe mechanism for information sharing.
The way the publish-subscribe mechanism works is fascinating. While all information is shared in a single space, each agent is guided to read only the information relevant to its own goals and tasks. To achieve this, meta-information (classification tags) is included in the structured messages output by the model, and the agent side also holds its own role information, successfully subscribing to/connecting only relevant information by matching the two.
One might ask why we don't just deliver information separately from the beginning if agents are only going to look at what's relevant. The core reason is that if information is generated separately for each agent, problems like information asymmetry between agents, hallucinations creeping in, or excessive or insufficient information being delivered can occur. Keeping the same ground truth in a single space and having agents selectively pick up relevant information from there is superior in terms of information consistency.

DyLAN — Representative of Horizontal Architecture

Figure 5. DyLAN’s Dynamic Team Optimization Structure.

Left (Team Optimization): Agents perform tasks in a shared thread, and contribution-based Agent Selection takes place each round. Right (Task Solving): The optimized team performs the actual task [9].
On the other hand, DyLAN [9] is closer to a Horizontal Architecture. In this structure, agents perform tasks together in a shared thread, and after each round, the contribution of each agent is evaluated, allowing only the top-K agents to proceed to the next round. A round here refers to a single step in which all agents generate one message each. The contribution evaluation is carried out by a separate LLM Ranker or through peer rating among agents.
Because they collaborate horizontally without a leader and team reorganization occurs based on performance, the team composition naturally optimizes as rounds repeat. However, because a separate LLM Ranker exists to evaluate the agents, it is not a perfect Horizontal Architecture, and it is more accurate to describe it as having a "highly horizontal structure."
The contrast between these two approaches makes a clear point. Both the quality of information (MetaGPT's structured output + publish-subscribe) and the quality of participants (DyLAN's performance-based team reorganization) are important, and combining both ideas might be the most effective approach in actual systems.

What This Means for Agentria

Comparing MetaGPT and DyLAN side-by-side reveals that both studies ultimately approach the same problem from different directions: the communication cost between agents. MetaGPT compresses the information flow so that "each agent reads only the information it needs" through a publish-subscribe mechanism, while DyLAN compresses the "number of participants generating messages in the first place" by filtering out low-contribution agents each round. Whether they narrow the information channel or reduce the number of senders, both essentially aim to reduce the token consumption of the entire system.
The message this sends to B2B multi-agent builders like Agentria is clear. The question faced when servicing multi-agent systems to enterprise clients is "is this worth the cost?" Considering messages exchanged between agents, as the number of agents increases, API call costs increase even faster. No matter how elegant the topology or how sophisticated the collaboration patterns are, if the token bill is unaffordable, it cannot go into production.

Wrapping Up

Through these two articles, we started from the fundamental characteristics of LLMs and mapped out the entire picture of multi-agent architecture that systematically overcomes their limitations. As the Collaborative Scaling Law demonstrates, this direction stands on experimentally verified principles [10].
A multi-agent system is not simply about "creating multiple agents." Just as temperature emerges from a collection of molecules in statistical mechanics, and consciousness emerges from a network of neurons in neuroscience, outcomes at levels impossible for individual agents are produced based on the structure (Topology) through which specialized agents communicate, the incentives (Cooperation/Competition/Coopetition) under which they cooperate, and the communication protocols they use to exchange information. And a system becomes truly usable in practice only when it is equipped with a framework that can transparently evaluate and provide feedback on all of this.
This is why designing multi-agent systems is as much organizational design as it is engineering.

References

[1] Bengio et al., “Scheduled Sampling for Sequence Prediction with Recurrent Neural Networks,” NeurIPS 2015.

[2] Huang et al., “Large Language Models Cannot Self-Correct Reasoning Yet,” ICLR 2024.

[3] Anthropic, “How we built our multi-agent research system,” Anthropic Engineering Blog, 2025. https://www.anthropic.com/engineering/multi-agent-research-system

[4] Tomašev, Franklin, Jacobs, Krier, and Osindero, “Distributional AGI Safety,” Google DeepMind, arXiv:2512.16856, December 2025.

[5] Wang et al., “Self-Consistency Improves Chain of Thought Reasoning in Language Models,” ICLR 2023.

[6] Hong et al., “MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework,” ICLR 2024.

[7] Qian et al., “ChatDev: Communicative Agents for Software Development,” arXiv:2307.07924, 2023.

[8] Wu et al., “AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation,” ICML 2024.

[9] Liu et al., “A Dynamic LLM-Powered Agent Network for Task-Oriented Agent Collaboration,” COLM 2024.

[10] Qian et al., “Scaling Large Language Model-based Multi-Agent Collaboration,” ICLR 2025.

[11] Tran, Dao, Nguyen, Pham, O’Sullivan, and Nguyen, “Multi-Agent Collaboration Mechanisms: A Survey of LLMs,” arXiv:2501.06322, January 2025.