Multi-Agent Systems › Topologies and Coordination Patterns

Multi-agent systems organize in several broad topologies, each with different tradeoffs in flexibility, fault tolerance, and complexity. Choosing the right topology is not a one-time architectural decision made at system design time. As systems scale and task requirements evolve, topologies often need to be adjusted. Starting with the simplest topology that fits the task and adding complexity only when the task demands it is usually the right approach.

The most common pattern is a two-level hierarchy: an orchestrator agent at the top decomposes the user's goal into subtasks and delegates each to a subagent. Subagents execute their assigned tasks and return results. The orchestrator synthesizes these results into a final response.

The orchestrator behaves like a project manager who writes work orders. It does not execute subtasks directly but rather decides what needs to be done, which agent should do it, and how outputs should be combined. The subagents behave like individual contributors: they receive a specific instruction, use their available tools to complete it, and report back.

This pattern scales naturally. An orchestrator can spawn additional subagents dynamically based on what it discovers during the task. If a research task reveals an unexpected subtopic requiring deep investigation, the orchestrator can create a specialized agent on the fly. Hierarchical orchestration also makes the system's behavior interpretable: every action traces back to an orchestrator decision, making debugging significantly easier than in peer-to-peer topologies.

The main vulnerability of hierarchical orchestration is that the orchestrator becomes a bottleneck. If it makes poor decomposition decisions (e.g., assigns too many tasks to one agent, fails to recognize a dependency between two subtasks), those mistakes propagate through all downstream work. The orchestrator's decomposition quality is therefore the single biggest factor in system performance. Much recent research on multi-agent systems focuses specifically on improving orchestrator prompts and planning strategies, which connects directly to the planning techniques discussed in the previous chapter.

A second vulnerability is that the orchestrator itself has limited context. When a task produces a large result, the orchestrator needs to read and process that result before deciding what to do next. With many agents producing large outputs simultaneously, the orchestrator's context window can fill up quickly. This is why good orchestrator design involves having subagents produce structured, concise summaries rather than raw outputs, with full results stored in a shared workspace that the orchestrator can selectively reference.

In a peer-to-peer topology, agents communicate directly without a central coordinator. Each agent has visibility into the shared state, can post messages, and can respond to messages from other agents. Agents propose actions, vote on approaches, or critique each other's outputs before a decision is finalized.

This topology is more resilient to single points of failure. If the orchestrator in a hierarchical system fails, the whole system stalls. In a peer-to-peer system, agents can continue operating and elect a new coordinator if needed. The resilience comes at a price: the system must have explicit protocols for conflict resolution, since there is no central authority to arbitrate disputes.

Peer-to-peer coordination also tends to produce richer deliberation. When agents can argue with each other and revise their positions based on incoming arguments, the quality of the final answer often exceeds what any single agent would produce. The CAMEL framework (Li et al., 2023) and the multi-agent debate work by Du et al. (2023) both demonstrate this empirically: agents that critique and counter-critique each other converge to more accurate answers than agents that work in isolation.

The downside is complexity. Without a central authority, agents may deadlock (each waiting for another to proceed), diverge (each pursuing conflicting strategies), or generate inconsistent outputs that no one reconciles. Implementing reliable peer-to-peer systems requires careful design of termination conditions and explicit protocols for handling disagreements that do not resolve through deliberation alone.

Some tasks naturally decompose into sequential stages where each stage's output is the next stage's input. A document analysis pipeline might have a reader agent extract key claims, a researcher agent verify those claims, and a writer agent compose a final report. Each agent passes its output to the next as structured data.

Pipeline systems are easier to reason about than peer-to-peer systems because information flows in one direction and dependencies are explicit. They sacrifice the parallelism benefits of hierarchical orchestration for this simplicity. The tradeoff is often worthwhile when the task truly is sequential and the emphasis is on correctness of each transformation step rather than on speed.

A subtle failure mode in pipelines is silent degradation. When each agent passes its output downstream without validation, early-stage errors propagate silently. The writer agent may faithfully produce a well-structured report based on researcher findings that are factually wrong, and nothing in the pipeline will detect this. Adding validation steps between pipeline stages, even lightweight ones, significantly improves reliability.

Pipelines are particularly effective when each stage has a well-defined transformation with clear inputs and outputs. The challenge arises when the boundaries between stages are fuzzy: if a researcher agent discovers that properly answering the research question requires significant analysis, and the analysis agent discovers that the initial research was too narrow, the pipeline becomes brittle because neither stage has a mechanism for requesting the other to revise its work. Pipelines therefore work best when the task structure is stable and well-understood in advance, rather than exploratory.

Real systems often combine these topologies. An orchestrator might use both hierarchical delegation for independent subtasks and a pipeline for dependent ones, while allowing peer communication for agents working on overlapping concerns. The choice of topology should follow the natural dependency structure of the task.

The concept of adaptive topology takes this further: the system selects its own coordination structure based on task characteristics. Some implementations (e.g., AutoGen from Microsoft Research, 2023) support this by letting agents decide at runtime whether to request help, spawn a subagent, or handle a task themselves. This flexibility improves performance on diverse task distributions but makes the system's behavior harder to predict and audit.