Coordination Patterns for Multi-Agent Systems

Multi-agent LLM systems are prominent in demonstrations but comparatively rare in production. The limiting factor is generally not the capability of individual agents but the difficulty of coordinating them reliably. This article gives a structured account of four coordination patterns, their applicability, and their failure modes, drawing on established treatments of agent orchestration [1, 2].

The coordination problem

Introducing multiple agents raises questions that single-agent systems do not: allocation (which agent performs which task), communication (shared state, message passing, or direct invocation), conflict resolution (behaviour when agents disagree), and responsibility for failure (which component retries when a sub-task fails). In the absence of explicit answers, undesirable emergent behaviour—including deadlock—can arise:

graph LR
    A[Agent A] --> |requires X| B[Agent B]
    B --> |requires Y| C[Agent C]
    C --> |blocked on A| A

Four patterns

1. Hierarchical delegation

A coordinator agent decomposes a task, assigns sub-tasks, and aggregates results.

graph TB
    COORD[Coordinator] --> A1[Agent 1]
    COORD --> A2[Agent 2]
    A1 --> COORD
    A2 --> COORD
    COORD --> OUT[Result]

Applicable when task decomposition is well defined and agent specialisations are clear. Failure mode: the coordinator is a bottleneck and a single point of failure.

async def hierarchical_analysis(document):
    coordinator = Coordinator()
    tasks = await coordinator.plan(document)
    results = await gather(*[execute(t) for t in tasks])
    return await coordinator.synthesize(results)

2. Sequential pipeline

Agents process in a fixed sequence, each transforming the output of the previous stage.

graph LR
    IN[Input] --> E[Extract] --> T[Transform] --> A[Analyze] --> OUT[Output]

Applicable when each stage depends on its predecessor. Failure mode: latency accumulates, and an error early in the pipeline propagates downstream.

3. Debate / consensus

Multiple agents independently propose solutions; an arbiter critiques and selects or synthesises. This corresponds to multi-agent debate methods studied as a means of improving factuality and reasoning [3].

graph TB
    T[Task] --> A1[Agent A]
    T --> A2[Agent B]
    A1 --> ARB[Arbiter]
    A2 --> ARB
    ARB --> OUT[Decision]

Applicable when decision quality justifies additional cost. Failure mode: high token cost from repeated calls; risk of non-termination without a round limit.

4. Reactive coordination via shared state

Agents act independently, coordinating through observation of and writes to a shared state store rather than through direct messaging—a formulation related to blackboard architectures in classical AI [4].

graph TB
    STATE[(Shared event log)]
    A1[Agent 1] --> STATE
    A2[Agent 2] --> STATE
    STATE --> A1
    STATE --> A2

Applicable when the environment is dynamic and agent capabilities overlap. Failure mode: race conditions and difficult debugging; requires careful concurrency control.

The durability requirement

Descriptions of coordination patterns frequently omit failure behaviour. Consider the hierarchical pattern mid-execution:

Coordinator: assigned tasks 1, 2, 3
Agent A: completed task 1
Agent B: processing task 2 ... [failure]
Agent C: completed task 3

Recovery requires answering: does task 2 restart in isolation; are tasks 1 and 3 re-executed; and how is the coordinator's view of progress reconstructed? Without durable, per-step state, the only safe recovery is to re-run everything. With checkpointing at each step, completed sub-tasks are skipped on recovery:

async def hierarchical_with_checkpoints(document):
    coordinator = Coordinator()
    tasks = await coordinator.plan(document)      # persisted
    results = []
    for task in tasks:
        results.append(await execute(task))       # checkpointed per task
    return await coordinator.synthesize(results)

This is the multi-agent instance of the durable-execution requirement discussed in the workflow-reliability literature: coordination correctness under partial failure is a property of the execution substrate, not of the pattern alone.

Pattern selection

Operational considerations

Independent of pattern, production multi-agent systems generally require: a defined inter-agent communication protocol; timeouts on every agent invocation; circuit breakers to prevent cascading failures; explicit handling of partial completion; distributed tracing across agents; tested conflict scenarios for shared resources; and durable recovery mid-workflow.

References

1. CrewAI, orchestration concepts (documentation). https://docs.crewai.com/
2. Microsoft, AutoGen conversation patterns (documentation). https://microsoft.github.io/autogen/
3. Du, Y. et al., "Improving Factuality and Reasoning in Language Models through Multiagent Debate," arXiv:2305.14325. https://arxiv.org/abs/2305.14325
4. Hayes-Roth, B., "A blackboard architecture for control," Artificial Intelligence 26(3), 1985. https://doi.org/10.1016/0004-3702(85)90063-3