Multi-Agent Patterns

Single-agent systems hit a ceiling. Context windows fill up, tool sets conflict, and latency compounds when one model tries to do everything. Multi-agent architectures break problems into scoped responsibilities, each handled by an agent with its own context, tools, and constraints.

Orchestration Patterns

Every multi-agent system is a variation or composition of these four patterns.

Higher-level architectures compose from these primitives:

• Coordinator/Dispatcher: A lightweight router classifies requests and dispatches to the right specialist without performing work itself. (Orchestrator/Workers variant.)
• Review/Critique Loop: A generator produces output; a reviewer evaluates against criteria and cycles feedback until approved or a retry limit is hit. (Orchestrator/Workers + Handoff.)
• Hierarchical Decomposition: The orchestrator breaks a complex task into sub-problems, each potentially managed by a lower-level orchestrator. Recursive delegation down to leaf workers. (Nested Orchestrator/Workers.)

Start with the simplest pattern that solves the problem. A single orchestrator with two workers handles most cases. Add complexity only when you observe bottlenecks, not in anticipation of them.

Orchestrator/Workers

sequenceDiagram
    participant U as User
    participant O as Orchestrator
    participant W1 as Research Agent
    participant W2 as Code Agent
    participant W3 as Review Agent

    U->>O: "Add OAuth to the API"
    O->>W1: Explore auth patterns in codebase
    W1-->>O: Found: session-based auth in src/auth/
    O->>W2: Implement OAuth flow
    W2-->>O: Created 3 files, updated 2
    O->>W3: Review changes for security
    W3-->>O: LGTM, 1 suggestion
    O->>W2: Apply suggestion
    W2-->>O: Done
    O-->>U: OAuth implemented, PR ready

Parallel Fan-Out

sequenceDiagram
    participant O as Orchestrator
    participant A as Search Agent
    participant B as Test Agent
    participant C as Docs Agent

    O->>A: Search for all usages of deprecated API
    O->>B: Generate tests for new endpoint
    O->>C: Update API reference docs

    Note over A,C: All three run simultaneously

    A-->>O: Found 14 usages across 8 files
    B-->>O: 6 tests written, all passing
    C-->>O: Docs updated with new endpoint
    O->>O: Merge results into plan

Cross-Platform Comparison

Memory Over Messaging

This is the single most important architectural insight for multi-agent systems: shared state outperforms agent-to-agent messaging. The instinct is to design chatty agent networks that mirror human collaboration — agents sending messages, negotiating, clarifying. This is slow, token-expensive, and brittle. The better pattern: agents read from and write to shared state (filesystem, session dict, graph state, or database). They do not talk to each other; they talk to the state. Design around data flow, not conversation flow. Memory engineering — deciding what state to expose, when to persist it, and how to scope access — matters more than optimizing inter-agent prompts.

Delegation with Isolation

Each sub-agent in a production system requires strict boundaries. Sharing a single context window, tool set, and permission level across agents defeats the purpose of decomposition. Every delegated agent needs four things defined at spawn time:

• Own context window. Do not inherit the parent’s full conversation history. Pass only information relevant to the specific task. Keeps the sub-agent focused and avoids context window waste.
• Restricted tool set. Define an explicit allowlist of tools per sub-agent. A research agent has no business writing to the filesystem; a deploy agent should not search the web. Deny by default.
• Defined return format. Sub-agents must return structured data, not free-form prose. Use output schemas or explicit formatting instructions so the orchestrator’s synthesis is deterministic.
• Optional model override. Not every sub-agent needs the most capable model. A triage agent can run on a smaller, faster model; a code review agent may benefit from a reasoning model. Match the model to the task.

Communication Protocols

Performance Data

Multi-agent architectures show 45% faster problem resolution and 60% more accurate outcomes compared to equivalent single-agent implementations, driven by specialization (scoped agents outperform general ones), parallelism (fan-out reduces wall-clock time), and review loops (catching errors without human intervention). Caveat: these gains are task-dependent — on sequential reasoning tasks, multi-agent decomposition can degrade performance by 39-70%, so multi-agent is not universally better. Token efficiency improves 30-50% from smaller per-agent context windows.

Choosing a Pattern