Multi-Agent Coordination Patterns: Five Approaches and When to Use Them

In multi-agent systems, the key is choosing the pattern that fits the problem, not the pattern that's most commonly used. You should always try the simplest pattern first, then evolve to the next stage after seeing where it breaks down.

The most basic generator-verifier pattern has one agent produce a draft while another agent checks whether it meets the criteria. It works well for problems with explicit evaluation criteria, such as code generation, fact-checking, rubric-based evaluation, and compliance checks, but when the verification criteria are ambiguous, it easily turns into a formal loop that simply keeps passing. Fallbacks such as iteration limits and human escalation are also needed.

Orchestrator-subagent is a hierarchical structure where one lead agent plans the work and distributes detailed tasks to subagents. It's good for running mutually independent checks in parallel, such as security, tests, style, and architecture in a pull request review. However, information tends to get compressed as it passes through the orchestrator, creating bottlenecks as dependencies grow.

For tasks that are long-running, where each worker needs to maintain its own context for an extended period, agent teams are more suitable. In this pattern, once a worker is assigned, it autonomously handles multiple stages, and reusable context and domain expertise accumulate over time. Conversely, when tasks are highly interdependent, sharing each other's results becomes difficult, making conflicts likely, and managing completion timing also becomes hard.

As the number of agents grows and interactions become more complex, a message bus becomes advantageous. Agents communicate only via publish/subscribe, and a router delivers events to the appropriate subscribers. This fits well in environments like security operations automation, where events flow in chains and new agents need to be continuously added, but tracing and debugging become harder, and routing errors can fail silently.

Shared-state is a method where, instead of a central coordinator, all agents read and write to a common store. It's powerful for tasks like research synthesis, where each other's findings need to immediately inform the next exploration, and it also reduces central points of failure. On the other hand, duplicate investigation, conflicting approaches, and reactive loops can easily arise, so termination conditions such as time limits, convergence criteria, or a final arbiter need to be designed from the start.

Ultimately, the criteria for choosing a pattern come down to context boundaries and information flow. Short, clearly defined subtasks suit orchestrator-subagent; long-running independent tasks suit agent teams; event-driven pipelines suit message bus; and collaborative exploration suits shared-state. What matters is not going complex all at once, but naturally evolving toward simpler or more loosely coupled coordination methods each time the problem structure changes.