Multi-Agent Orchestration Patterns

Multi-agent systems fail in predictable ways. The most common failure mode is not an individual agent making a bad decision — it is the coordination layer between agents producing incoherent results, infinite loops, or silent degradation. The architecture of how agents communicate is as important as the capabilities of each agent.

Three patterns cover most production use cases. Understanding where each fits prevents the most expensive mistakes.

Pattern 1 — The Supervisor

A single orchestrator agent receives the task, decomposes it into subtasks, dispatches subtasks to specialist agents, synthesizes results, and handles failures.

User → [Supervisor Agent]
           ├─→ [Research Agent]  → results
           ├─→ [Code Agent]      → results
           └─→ [Writer Agent]    → results
       [Supervisor] synthesizes → User

When it works: Tasks with heterogeneous subtask types where the supervisor can reason about which specialist to invoke. Research + analysis + writing pipelines, multi-step coding tasks, and complex customer support are natural fits.

Implementation:

class SupervisorAgent:
    def __init__(self, specialists: dict[str, Agent]):
        self.specialists = specialists

    async def run(self, task: str) -> str:
        plan = await self.plan(task)
        results = {}
        for step in plan.steps:
            agent = self.specialists[step.agent_type]
            results[step.id] = await agent.run(step.task, context=results)
        return await self.synthesize(task, results)

Failure modes:

• The supervisor becomes a bottleneck — every result passes through it
• Supervisor hallucinations about which specialist to use compound downstream
• Planning quality is bounded by the supervisor's reasoning capability

Mitigation: Build deterministic routing for well-known task types. Only involve the LLM supervisor for genuinely ambiguous decomposition.

Pattern 2 — The Pipeline

Agents are arranged in a fixed sequence. Each agent receives the output of the previous as input. No dynamic routing.

User → [Planner] → [Executor] → [Validator] → [Formatter] → User

When it works: Tasks with predictable, sequential stages where each stage's output is well-defined. Document processing, code generation → test → fix cycles, and ETL transformations fit cleanly.

Implementation:

async def run_pipeline(
    input: str,
    stages: list[Agent]
) -> PipelineResult:
    current = input
    trace = []
    for stage in stages:
        result = await stage.run(current)
        trace.append({'stage': stage.name, 'output': result})
        if not result.success:
            return PipelineResult(failed_at=stage.name, trace=trace)
        current = result.output
    return PipelineResult(output=current, trace=trace)

Failure modes:

• Error propagation: a bad output from stage N corrupts all subsequent stages
• No flexibility for tasks that need to loop or branch

Mitigation: Add validation checkpoints between stages. Define clear contracts for what each stage accepts and produces — use Pydantic or Zod to enforce them programmatically.

Pattern 3 — Debate (Multi-Agent Verification)

Multiple agents independently solve the same task, then reconcile their results — either through a judge agent or through a structured consensus protocol.

User → [Agent A] → answer_A ─┐
     → [Agent B] → answer_B ─┤→ [Judge/Consensus] → User
     → [Agent C] → answer_C ─┘

When it works: High-stakes decisions, factual verification, security analysis, and any domain where false confidence is more dangerous than latency. Medical, legal, and financial applications often require this pattern.

Implementation:

async def debate_round(
    question: str,
    agents: list[Agent],
    judge: Agent
) -> DebateResult:
    answers = await asyncio.gather(*[a.run(question) for a in agents])
    consensus = await judge.run(
        f"Evaluate these answers to: {question}\n\n" +
        "\n\n".join(f"Agent {i}: {a.output}" for i, a in enumerate(answers))
    )
    return DebateResult(
        answers=answers,
        consensus=consensus.output,
        confidence=consensus.confidence
    )

Failure modes:

• Latency multiplies with number of agents — debate is inherently parallel but still slower than single-agent
• Judge agent can be manipulated by confident-sounding wrong answers
• Cost scales linearly with agent count per query

Mitigation: Use debate selectively, triggered by confidence thresholds from a cheaper single-agent pass. Reserve full debate for cases where the first agent flags uncertainty.

Choosing the Right Pattern

Criterion	Supervisor	Pipeline	Debate
Task structure	Variable	Fixed sequential	Parallel verification
Latency priority	Medium	Low	High (acceptable)
Failure tolerance	Medium	Low (one bad stage = failure)	High
Cost	Medium	Low	High
Correctness requirement	Medium	Medium	High

In practice: most applications use a hybrid. A supervisor orchestrates a pipeline for the happy path, and triggers a debate round when the pipeline confidence is below threshold.

The architecture decision is not about which pattern is "best" — it is about which coordination topology matches the structure of the problem. Map the task first; choose the pattern second.