Multi-Agent Systems in Production: 5 Patterns That Actually Work

Introduction

Multi-agent looks great in demos. In production, most teams over-engineer it. The cost — more LLM calls, higher latency, harder debugging, opaque failures — usually exceeds the benefit unless you're using the right pattern for the right problem.

This post breaks down the five multi-agent patterns we've shipped to production, the criteria for picking the right one, and the failure modes we see most often when teams reach for multi-agent before they've exhausted simpler architectures.

If you're considering multi-agent for a project, this is the framework we use with clients to decide whether you actually need it.

First: when you shouldn't use multi-agent

Default to a single agent. Adding agents adds: more LLM calls (cost), sequential coordination (latency), debugging complexity (every additional agent is another component that can fail), and a steeper learning curve for your team.

You don't need multi-agent when:

• A single well-prompted agent with structured outputs handles the task adequately.
• The task is essentially classification + tool call (one decision, one action).
• Quality is acceptable from a single agent and the marginal improvement from multi-agent doesn't justify the overhead.
• You don't have the engineering capacity to build evals, observability, and orchestration for multiple agents.

The hard question to ask before reaching for multi-agent: "What specifically does this give me that a well-built single agent doesn't?" If the answer is vague, stay with the single agent.

Pattern 1: Orchestrator + workers

One coordinator agent routes incoming requests to specialist worker agents. Each worker has a bounded scope and a focused prompt; the orchestrator handles the dispatch logic.

When it wins

When requests have clear categories and each category benefits from a specialized prompt or different toolset. The orchestrator does intent classification; workers do the actual work.

pseudocode
Orchestrator Agent
  ├── Classifies incoming request
  ├── Routes to appropriate worker
  │
  ├── Support Worker (FAQ, troubleshooting)
  ├── Billing Worker (refunds, plan changes)
  ├── Escalation Worker (complex cases → human)
  └── Sales Worker (upgrade questions)

When it loses

When categories overlap heavily and routing becomes lossy. Or when the orchestrator's judgment is the bottleneck and adding workers doesn't help.

Real production example

PostAgent uses this pattern for content generation: an orchestrator reads your shipped work and dispatches to specialized worker agents for different content types — technical posts, product launches, retrospectives. Each worker has a focused prompt and structured output schema.

Pattern 2: Planner + critic + executor

A planner agent decides what to do. A critic agent reviews the plan and flags issues. An executor agent runs the plan if approved (or after revision).

When it wins

When tasks have multiple steps, the cost of an incorrect action is high, and a second-pass review materially improves quality. The critic loop catches obvious errors before they reach production.

When it loses

When latency is critical (you're doubling LLM calls) or tasks are simple enough that planning is overkill. Also breaks down if the critic is no better-trained than the planner — you're just doubling the same biases.

Real production example

Code generation agents: planner drafts the implementation approach, critic reviews for security issues and edge cases, executor writes the actual code. The critic catches issues like SQL injection, missing input validation, or incorrect error handling.

Pattern 3: Three-judge jury

Three agents with deliberately different perspectives vote on outputs. Majority wins; ties go to human review.

When it wins

When quality matters more than latency, single-agent outputs are inconsistent in ways that bias affects, and you can articulate distinct evaluation perspectives.

When it loses

When you can't define meaningfully different agent roles. Three agents with the same prompt give you the same answer three times — that's just noise.

Real production example

PostAgent's quality gate uses three judges: Anti-Slop (filters generic LinkedIn fluff), Cynical Engineer (rejects vague claims and feel-good content), AI Builder (filters content that doesn't match the author's actual work). Each judge has a distinct rubric. A draft passes only if 2 of 3 approve.

Pattern 4: Hierarchical handoff

Tier-1 agent handles routine cases, escalates to tier-2 when it can't. Tier-2 handles harder cases, escalates to humans when needed. Each tier passes context to the next.

When it wins

When cases have a natural complexity gradient and you want to optimize cost. Use smaller, faster, cheaper models for tier-1; larger, more capable models for tier-2.

When it loses

When cases are uniformly complex (no clear "easy cases") or when the tier-1 → tier-2 handoff loses critical context.

Real production example

Customer support escalation: tier-1 uses GPT-4-mini against the knowledge base for routine questions; if confidence is low or the user explicitly asks for escalation, tier-2 (GPT-4 with more tools and context) takes over. If tier-2 can't resolve, escalates to human with a full context summary.

Pattern 5: Shared-state collaboration

Multiple agents read and write to a shared scratchpad or state object. Each agent contributes its expertise; the final answer emerges from collaboration.

When it wins

When tasks genuinely require collaboration across distinct expertise areas. Research projects, complex troubleshooting, multi-domain decisions.

When it loses

Most of the time. This is the most flexible pattern and the hardest to debug. Default to a simpler pattern unless you can articulate a specific reason this is the right one.

Real production example

Pre-sales research: agents specialized in financial analysis, technical architecture review, and competitive landscape all read shared context (the prospect's company data) and contribute findings to a shared report. A coordinator agent synthesizes the final output. Useful for one specific high-value use case; overkill for most.

Pattern comparison: cost, latency, complexity

Rough orders of magnitude for each pattern:

• Single agent: 1x cost, 1x latency, baseline complexity.
• Orchestrator + workers: 1.5-2x cost (orchestrator + 1 worker per turn), 1.5x latency, moderate complexity.
• Planner + critic + executor: 3x cost, 2.5x latency, higher complexity.
• Three-judge jury: 3-4x cost (drafter + 3 judges), 2x latency (judges can run in parallel), moderate complexity.
• Hierarchical handoff: 1-2x cost (tier-2 only fires on hard cases), variable latency, moderate complexity.
• Shared-state collaboration: 4-10x cost, 3x+ latency, high complexity.

These multipliers add up fast. A single agent at $0.05 per execution becomes $0.50 per execution under shared-state collaboration. Make sure the quality improvement justifies the cost.

How to pick the right pattern

A practical framework:

• If you can solve the task with a single well-built agent, do that. Don't reach for multi-agent prematurely.
• If you have clear request categories, use orchestrator + workers. This is the most common pattern and works for a wide range of use cases.
• If quality is critical and you can articulate distinct evaluation perspectives, use three-judge jury.
• If you have a clear complexity gradient and want to optimize cost, use hierarchical handoff.
• If you have multi-step planning with high error cost, use planner + critic + executor.
• If you have truly multi-domain reasoning needs and you can articulate why, use shared-state. But default to "no" — most teams don't need this.

Conclusion

Multi-agent isn't a goal. It's a tool that solves specific problems at specific costs. The best multi-agent architecture is the simplest one that meets your quality and behavior requirements.

Start with a single agent. Measure quality. If quality is insufficient, identify the specific failure mode, pick the pattern that addresses it, and adopt only that pattern. Resist the temptation to use multi-agent because it sounds sophisticated.

If you're evaluating multi-agent architecture for a project, we're happy to walk through the trade-offs. Sometimes the right answer is "your single agent is fine, fix the prompt." Sometimes it's "you need three-judge jury for this content generation use case." The right framework helps you tell which.