5 Multi-Agent Patterns That Actually Work

Why Patterns Matter

Most multi-agent systems fail not because the models are bad, but because the orchestration is wrong. You can have the best LLM in the world, and if you wire agents together without a clear pattern, you get hallucinations compounding on hallucinations, costs spiraling, and outputs that are worse than a single-agent call.

These five patterns are battle-tested in production systems. Each solves a specific class of problem. Pick the right one for your task, and multi-agent goes from a buzzword to a genuine force multiplier.

---

Pattern 1: Sequential Pipeline

Agents in a chain, each transforms the output of the previous one.

When to Use

• Tasks with clear stages: research → draft → review → polish
• When each stage requires different expertise or model capabilities
• When you need auditability — you can inspect the output at every stage

Code Pattern

# Sequential Pipeline
stages = [
    {"agent": "researcher",  "model": "sonnet",  "prompt": "Find relevant sources for: {topic}"},
    {"agent": "writer",      "model": "sonnet",  "prompt": "Write a draft using these sources: {prev_output}"},
    {"agent": "editor",      "model": "opus",    "prompt": "Review and improve this draft: {prev_output}"},
    {"agent": "fact_checker", "model": "haiku",   "prompt": "Verify all claims in: {prev_output}"},
]

result = initial_input
for stage in stages:
    result = call_agent(
        model=stage["model"],
        system=stage["prompt"].format(prev_output=result, topic=initial_input)
    )
    save_checkpoint(stage["agent"], result)  # Audit trail

Real-World Example

A content generation pipeline: Agent 1 researches a topic using web search tools. Agent 2 writes a structured draft. Agent 3 (using a stronger model) reviews for accuracy and tone. Agent 4 (using a cheap model) does a final fact-check pass.

Common Pitfalls

• Error propagation: A mistake in stage 1 compounds through all stages. Add validation gates between stages.
• Latency: Every stage adds round-trip time. Four stages with Opus means 30-60 seconds total.
• Context loss: Later agents may not understand decisions made in earlier stages. Pass structured metadata, not just raw text.

Cost Implications

Linear cost scaling. Four stages = 4x the token cost of a single call. Mitigate by using cheaper models (Haiku) for simpler stages and reserving expensive models (Opus) for the stage that requires the most reasoning.

---

Pattern 2: Parallel Fan-Out

Split work into independent chunks, process simultaneously, merge results.

When to Use

• Tasks that are naturally decomposable (analyze 10 files, test 5 endpoints, review 3 PRs)
• When latency matters more than cost — parallel execution cuts wall-clock time dramatically
• When sub-tasks do not depend on each other

Code Pattern

import asyncio

async def fan_out(tasks: list[dict]) -> list[str]:
    """Dispatch independent tasks to parallel agents, merge results."""
    
    async def run_agent(task):
        return await call_agent_async(
            model=task["model"],
            system=task["prompt"],
            input=task["input"]
        )
    
    # Fan out — all agents run simultaneously
    results = await asyncio.gather(*[run_agent(t) for t in tasks])
    
    # Merge — a synthesizer combines parallel outputs
    merged = await call_agent_async(
        model="sonnet",
        system="Synthesize these independent analyses into a coherent report.",
        input="\n---\n".join(results)
    )
    return merged

# Example: analyze 5 modules in parallel
tasks = [
    {"model": "haiku", "prompt": "Review this module for bugs.", "input": module}
    for module in modules
]
report = await fan_out(tasks)

Real-World Example

Code review across a large PR. Instead of one agent reading 20 files sequentially, dispatch 5 agents that each review 4 files. A synthesizer agent merges findings into a unified review with deduplicated issues.

Common Pitfalls

• Merge conflicts: Parallel agents may produce contradictory recommendations. The synthesizer must be explicit about resolving conflicts.
• Uneven workloads: If one task takes 10x longer than the others, you wait for the slowest. Balance chunk sizes.
• Shared state: If agents need to read/write the same file, fan-out breaks. Use this pattern only for truly independent work.

Cost Implications

Same total cost as sequential (same number of tokens), but wall-clock time drops to the duration of the slowest agent. The merge step adds a small overhead. Best cost-per-latency ratio of all patterns.

---

Pattern 3: Hierarchical Delegation

A manager agent plans the work and assigns sub-tasks to worker agents.

When to Use

• Complex, multi-step projects where the plan itself requires intelligence
• When different sub-tasks need different tools or capabilities
• When you want a single agent responsible for quality and coordination

Code Pattern

# Manager creates the plan
plan = call_agent(
    model="opus",
    system="""You are a project manager. Break this task into independent sub-tasks.
    Output JSON: [{"id": 1, "task": "...", "model": "haiku|sonnet|opus", "tools": [...]}]""",
    input=user_request
)

# Workers execute in parallel where possible
results = {}
for task in plan["tasks"]:
    results[task["id"]] = call_agent(
        model=task["model"],
        system=f"Complete this task: {task['task']}",
        tools=task["tools"]
    )

# Manager reviews and integrates
final = call_agent(
    model="opus",
    system="Review all worker outputs. Fix issues. Produce the final deliverable.",
    input={"plan": plan, "results": results}
)

Real-World Example

Building a feature end-to-end. The manager (Opus) analyzes the requirements, creates a plan with 6 tasks: update schema, create API endpoint, write UI component, add tests, update docs, and create migration. It assigns each to the appropriate model and tool set. Workers execute. Manager reviews all outputs and ensures they fit together.

Common Pitfalls

• Over-delegation: The manager creates too many fine-grained tasks, adding overhead. Keep tasks chunky enough to be meaningful.
• Manager bottleneck: The manager must understand all the work to review it. If the task is too complex, the manager's review becomes superficial.
• Cost: The manager runs twice (planning + review), and workers run once each. This is the most expensive pattern.

Cost Implications

Highest cost per task. Manager uses Opus (expensive) twice. Offset by using Haiku/Sonnet for workers. Best for high-value tasks where quality justifies the cost — shipping a feature, writing a research paper, designing an architecture.

---

Pattern 4: Debate and Judge

Two agents argue opposing positions. A third agent judges the best answer.

When to Use

• Decisions with genuine trade-offs (architecture choices, design decisions)
• When you want to reduce bias — a single agent tends to commit to its first answer
• Code review where catching subtle bugs matters more than speed

Code Pattern

# Two advocates argue different positions
advocate_a = call_agent(
    model="sonnet",
    system="You are Advocate A. Argue FOR this approach. Be specific and cite evidence.",
    input=question
)

advocate_b = call_agent(
    model="sonnet",
    system="You are Advocate B. Argue AGAINST this approach. Find weaknesses, propose alternatives.",
    input=question
)

# Judge evaluates both arguments
verdict = call_agent(
    model="opus",
    system="""You are the Judge. Read both arguments carefully.
    Identify the strongest points from each side.
    Render a verdict with clear reasoning.
    If neither side is fully correct, synthesize the best answer.""",
    input=f"FOR:\n{advocate_a}\n\nAGAINST:\n{advocate_b}"
)

Real-World Example

Choosing between microservices and a monolith for a new project. Advocate A argues for microservices with scaling benefits. Advocate B argues for a monolith with simplicity and speed. The Judge (Opus) weighs both arguments against the actual project constraints and renders a decision with clear reasoning.

Common Pitfalls

• Weak advocacy: If advocates are too agreeable, you get a fake debate. Make system prompts explicitly adversarial.
• Judge bias: The judge may favor the first argument it reads. Randomize the order.
• Overkill for simple decisions: Do not debate whether to use const or let. Reserve this for genuinely ambiguous decisions.

Cost Implications

3x the cost of a single call. The judge should be the strongest model (Opus). Advocates can use Sonnet to save cost. Use this pattern sparingly — it is a precision tool, not a default workflow.

---

Pattern 5: Mixture of Agents

Multiple models answer the same question. A meta-agent selects or synthesizes the best response.

When to Use

• When no single model is reliably the best for a task
• Maximizing answer quality for high-stakes outputs (legal analysis, medical summaries, critical code)
• When you want confidence scoring — agreement between models signals reliability

Code Pattern

# Query multiple models with the same prompt
models = ["claude-opus-4-6", "gpt-4o", "gemini-2.5-pro"]

responses = await asyncio.gather(*[
    call_model_async(model=m, prompt=question) for m in models
])

# Meta-agent synthesizes the best answer
best = await call_agent_async(
    model="claude-opus-4-6",
    system="""You received answers from 3 different AI models.
    Compare them. Identify where they agree (high confidence) and disagree (needs scrutiny).
    Produce the single best answer, noting confidence level.""",
    input="\n---\n".join(
        f"Model {i+1} ({models[i]}):\n{r}" for i, r in enumerate(responses)
    )
)

Real-World Example

Generating a security audit for a smart contract. Claude, GPT-4o, and Gemini each independently analyze the contract. A meta-agent compares all three analyses. Vulnerabilities flagged by all three models are high-confidence. Vulnerabilities flagged by only one model are marked for human review.

Common Pitfalls

• Cost explosion: Running 3+ models per query is 3x+ the cost. Only use for high-value outputs.
• API management: You need API keys and error handling for multiple providers. Failures in one model should not block the others.
• False consensus: Models trained on similar data may agree on the same wrong answer. Diversity of model architecture matters.

Cost Implications

Most expensive pattern. 3-5x the cost of a single call, plus the meta-agent. Reserve for critical outputs where the cost of being wrong exceeds the cost of running multiple models.

---

Decision Framework: Which Pattern to Use

Situation	Pattern	Why
Clear multi-step workflow	Sequential Pipeline	Each stage has distinct input/output
Independent sub-tasks	Parallel Fan-Out	Minimize latency, maximize throughput
Complex project with planning	Hierarchical Delegation	Manager ensures coherence
Ambiguous decision	Debate and Judge	Surface trade-offs, reduce bias
High-stakes single output	Mixture of Agents	Maximize quality through diversity
Simple task	No pattern — single agent	Overhead not justified

The 80/20 Rule

80% of tasks need a single agent call. Do not reach for multi-agent patterns by default. Use them when the task complexity genuinely demands it. The best pattern is the simplest one that produces the quality you need.

---

Cost Optimization Across All Patterns

1. Use the cheapest model that works. Haiku 4.5 handles 80% of sub-tasks. Sonnet for medium complexity. Opus only for planning, judging, and critical reasoning.
2. Cache intermediate results. If a pipeline stage produces useful output, save it. Do not recompute.
3. Set token limits. Workers do not need 8,000-token responses. Cap output tokens to what the task requires.
4. Monitor and measure. Track cost-per-task and quality-per-task. If a cheaper model produces equivalent quality, switch.
5. Fail fast. Add validation between stages. If an early stage produces garbage, abort instead of paying for downstream processing.