Multi-Agent Systems: Patterns That Ship to Production

Everyone is building multi-agent systems. Most of them shouldn't be.

I've spent enough time debugging multi-agent workflows to have a strong opinion on this: a single well-prompted agent with good tools beats a complex multi-agent system 80% of the time. The remaining 20% is where multi-agent architectures genuinely shine, and where most of the interesting production problems live.

The gap between a multi-agent demo and a multi-agent production system is enormous. Here's what actually works.

When You Actually Need Multiple Agents#

Before reaching for a multi-agent architecture, be honest about whether you need one. If your "agents" are different system prompts calling the same model with the same tools, you don't have a multi-agent system. You have a complicated single agent.

You genuinely need multiple agents when:

• Different models serve different roles: a fast, cheap model for classification routing and a capable model for complex reasoning
• Different permission levels are required: one agent reads from production databases, another only touches sandboxed environments
• Context windows need isolation: agent A's context would pollute agent B's decision-making
• Different execution environments: one agent runs server-side, another runs in-browser, another in a secure enclave
• Parallelism matters: multiple independent subtasks can execute simultaneously

If none of these apply, simplify. The patterns in Building Production AI Agents will get you further than a premature multi-agent architecture. A single agent with a well-designed tool set and a clear system prompt will be more reliable, cheaper to run, and dramatically easier to debug.

The Orchestrator-Worker Pattern#

Of the multi-agent patterns I've deployed, one ships more than all others combined: the orchestrator-worker pattern.

The orchestrator holds the plan. Workers are stateless executors. Structured output flows between every boundary.

The key properties:

• Workers don't talk to each other. All communication goes through the orchestrator. This eliminates an entire class of coordination bugs.
• Workers are stateless. They receive a task, execute it, return a result. No memory between invocations. This makes them replaceable and testable.
• The orchestrator is the only agent with the full picture. It decides what to do next based on accumulated results.

I've seen teams build peer-to-peer agent networks where every agent can message every other agent. It works in demos. In production, it's a debugging nightmare. Stick with the hub-and-spoke model until you have overwhelming evidence that you need something more complex.

Structured Output Is Non-Negotiable#

The single biggest mistake in multi-agent systems: passing raw LLM text between agents.

Don't do this. Ever. Every agent boundary needs a schema. Every output gets validated before it crosses that boundary.

import { z } from 'zod';

// Define strict schemas for agent outputs
const ResearchResult = z.object({
  query: z.string(),
  findings: z.array(z.object({
    source: z.string(),
    summary: z.string().max(500),
    confidence: z.enum(['high', 'medium', 'low']),
    relevant_quotes: z.array(z.string()).max(3),
  })),
  gaps: z.array(z.string()),
  recommended_next_steps: z.array(z.string()).max(3),
});

type ResearchResult = z.infer<typeof ResearchResult>;

// Validate at every boundary
function handleWorkerOutput(raw: unknown): ResearchResult {
  const parsed = ResearchResult.safeParse(raw);
  if (!parsed.success) {
    // Don't silently continue with bad data
    throw new AgentBoundaryError(
      'Research worker returned invalid output',
      parsed.error.issues
    );
  }
  return parsed.data;
}

This seems like overhead. It isn't. Without schemas, you get cascading failures where agent B hallucinates because agent A returned something ambiguous. With schemas, you catch problems at the boundary where they originate.

The Coordination Pitfalls#

After deploying enough of these systems, the failure modes become predictable. Here are the three that burn teams most often.

Infinite Loops#

Agent A asks agent B for clarification. Agent B asks agent A for more context. Neither has new information. They loop until you hit a rate limit or a billing alert.

Mitigation: hard iteration counters at every level. The orchestrator tracks total workflow steps. Each worker has a maximum number of LLM calls. Both are non-negotiable limits, not suggestions.

const WORKFLOW_LIMITS = {
  maxTotalSteps: 25,
  maxWorkerCalls: 5,
  maxRetries: 2,
  timeoutMs: 120_000,
} as const;

Cascading Hallucinations#

Worker A hallucinates a fact. The orchestrator passes it to Worker B as context. Worker B builds on the hallucination. By the time a human sees the output, the original error is buried under layers of confident-sounding reasoning.

Mitigation: validate at every boundary. Don't just check structure; check semantics where possible. If a worker claims to have found data, verify the source exists. If the analysis references specific numbers, trace them back.

Runaway Costs#

A single workflow with four agents, each making three LLM calls with large contexts, costs 12x what you'd expect from a single-agent approach. Multiply by retries, and a $0.50 task becomes a $15 task.

Mitigation: budget limits per workflow, tracked in real-time. Kill workflows that exceed their budget before completion. It's better to fail fast and surface the problem than to let costs accumulate silently.

Observability for Multi-Agent Systems#

If debugging a single agent is hard, debugging four agents coordinating on a task is an order of magnitude harder. Observability isn't optional; it's a prerequisite.

The Minimum Viable Observability Stack#

• A single workflow_id propagated across every agent call, every tool invocation, every LLM request. If you can't trace a request from start to finish, you can't debug it.
• Token cost tracking per agent per step. Not just totals; breakdowns. You need to know which agent is burning tokens and on which step.
• Full input/output logging at every agent boundary. When something goes wrong, you need to see exactly what each agent received and what it returned.
• Replay capability. The most powerful debugging tool for multi-agent systems is the ability to replay a workflow with the same inputs and see where it diverges. This requires deterministic logging of every decision point.

Tools like LangSmith can help here, but I've found that most teams end up building custom observability because the coordination patterns are specific to their architecture. Start with structured logging and a trace viewer. Add complexity as you need it.

MCP as the Integration Layer#

One pattern that's emerged as genuinely useful: decoupling tool development from agent development using the Model Context Protocol. I cover the protocol in depth in my MCP enterprise guide, but here's the multi-agent angle.

The idea is straightforward. Instead of baking tools directly into agents, you build tools as MCP servers. Any agent can connect to any MCP server. Tool development and agent development become independent workstreams.

This has practical benefits:

• Tool reuse across agents: your database query tool works the same whether the research agent or the analysis agent calls it
• Independent deployment: update a tool without redeploying agents
• Standardised interface: every tool follows the same protocol, reducing integration friction
• Permission boundaries: MCP servers can enforce their own access controls

The tradeoff is added network latency and the overhead of running separate server processes. For most production systems, this is worth it. For latency-critical hot paths, you might still want tools in-process.

Frequently Asked Questions#

When should you use a multi-agent system instead of a single AI agent?#

You genuinely need multiple agents only when different models serve different roles, different permission levels are required, context windows need isolation between tasks, agents run in different execution environments, or independent subtasks benefit from parallelism. If none of these apply, a single well-prompted agent with good tools will be more reliable, cheaper, and easier to debug.

What is the orchestrator-worker pattern for multi-agent systems?#

The orchestrator-worker pattern is the most production-proven multi-agent architecture. A central orchestrator holds the plan and delegates discrete tasks to stateless worker agents. Workers never communicate directly with each other; all coordination flows through the orchestrator. Every agent boundary uses validated structured output schemas to prevent cascading hallucinations.

How do you control costs in multi-agent AI systems?#

Multi-agent workflows multiply costs because each agent makes multiple LLM calls with large contexts. Control costs by setting per-workflow budget limits tracked in real-time, enforcing hard iteration counters at every level (total workflow steps and per-worker call limits), and killing workflows that exceed their budget before completion. A workflow with four agents can easily cost 12x a single-agent approach before retries.

The Honest Assessment#

The best multi-agent systems I've seen in production are boring. They have strict boundaries between agents, structured communication at every interface, hard limits on iteration and cost, and comprehensive observability.

They don't use clever coordination strategies. They don't have agents negotiating with each other. They don't build emergent behaviour through agent interaction.

They have an orchestrator that follows a plan, workers that execute discrete tasks, and schemas that enforce contracts between them.

Start with a single agent. Add a second agent only when you have clear evidence that one agent can't handle the workload: different models, different permissions, different execution environments. Add a third only when two isn't enough. The rest of the AI delivery series covers the foundational patterns, from single-agent architecture through RAG and MCP, that should be solid before you reach for multi-agent coordination.

The boring architecture ships. The clever architecture produces conference talks. If you're navigating the broader challenge of getting AI from demo to deployment, From POC to Production covers the organisational patterns that matter just as much as the technical ones.