Bibliothèque de concepts
Multi-Agent Orchestration
Coordinating multiple specialized agents to solve a problem together — through hierarchical orchestrator-worker patterns, peer-to-peer collaboration, or graph-based state machines.
What it is
Multi-agent orchestration is the pattern of using more than one LLM-powered agent to solve a single goal. Each agent has a specialized role, prompt, and tool set. They coordinate through some structure — a coordinator dispatches to workers, peers exchange messages, or a state graph governs transitions.
The common patterns: orchestrator-worker (a coordinator decomposes the goal and dispatches to specialists), peer collaboration (agents converse to converge on an answer), graph-based (a state machine routes between agents based on conditions), and pipeline (sequential specialist agents).
The choice between single-agent and multi-agent is the most consequential architecture decision in this category. Multi-agent systems are more expensive, slower, and harder to reason about than single-agent ones. They are right when the problem genuinely benefits from decomposition.
Why it matters
Multi-agent architectures unlock work that single agents cannot do well. Tasks that span multiple domains, require parallel sub-investigation, or involve genuinely different specializations benefit from decomposition. A research task that needs document search, data analysis, and synthesis genuinely benefits from three agents with three tool sets — each specialized, each with focused context.
The trap: most “multi-agent” systems in production are single-agent problems being over-engineered. Three agents arguing in expensive context windows about a problem one agent could have solved is a common failure mode. The marginal cost of additional agents — latency, tokens, coordination complexity — is high. The benefit only materializes when the decomposition is genuinely useful.
This is where senior architects earn their pay. Knowing when multi-agent helps and when it hurts is judgment grounded in production experience.
How it works
Orchestrator-worker. A coordinator agent receives the goal, decomposes it into sub-tasks, and dispatches each to a specialist agent. The coordinator integrates results. Right pattern when sub-tasks are independent and large enough to merit dedicated context. Coordinator’s prompt is meaningfully harder to write than a single agent’s — it has to reason about decomposition, parallelism, and integration.
Peer collaboration. Multiple agents exchange messages, often with distinct roles (analyst, critic, synthesizer). Each iteration improves the answer. Right pattern when the work benefits from explicit critique. Cost climbs fast — every “round” multiplies tokens.
Graph state machine. A state graph defines transitions between agents. State is explicit and persistent. The graph runtime — LangGraph, Temporal — handles routing, retries, and durability. Right pattern when the system is production-critical with multiple paths and observability needs.
Pipeline. Specialist agents run sequentially, each transforming the output of the previous. Closer to a chained workflow than true multi-agent, but useful when the stages are well-defined.
The cross-cutting concerns:
Communication protocol. How do agents pass information? Free-text messages are flexible but lossy. Structured handoffs (typed objects) are clearer but rigid. Most production systems converge on structured handoffs with free-text annotations.
Termination. When does the system stop? Time, iterations, cost ceiling, explicit completion signal — all matter. Without explicit termination conditions, multi-agent systems loop expensively.
Cost management. Each agent’s context grows with every step. Naive multi-agent burns context budget quickly. Active context pruning, summarization between handoffs, and per-agent token budgets are all production necessities.
Debugging. When something goes wrong, which agent caused it? Trace-level observability (one trace per goal, with sub-spans per agent) is non-negotiable for production.
Vendor comparison
| Framework | Pattern strength | Best for |
|---|---|---|
| LangGraph | Graph state machine | Production multi-agent systems with durability and observability |
| CrewAI | Orchestrator-worker, role-based | Fast prototyping, accessible mental model |
| AutoGen (Microsoft) | Peer collaboration, conversational | Research, multi-agent conversation patterns |
| OpenAI Agents SDK | Single-agent + handoffs | Lighter multi-agent patterns tied to OpenAI |
| Anthropic / MCP-native | Single-agent + tool-rich; orchestrator pattern via app code | Tool-heavy multi-agent backed by Claude |
| Temporal + LLM | Graph + durable workflows | Long-running multi-agent with replay and durability |
LangGraph is the production default for multi-agent in 2026. The graph state machine model handles the things that matter in production — explicit state, durability, retry semantics, observability — better than the alternatives. The learning curve is real but pays back.
CrewAI is the right answer for prototyping multi-agent ideas quickly. Role-based agents with sensible defaults get you to a demo fast. I treat CrewAI prototypes as exploration; for production I usually rebuild on LangGraph.
AutoGen is strongest for research-flavored multi-agent conversation patterns. Microsoft-centric integrations are a benefit if your stack is Azure.
Temporal with LLM activities is the most interesting newer pattern. If your multi-agent system is long-running (hours, days), durable across worker failures, and has human-in-the-loop steps, Temporal handles the workflow primitives better than agent-specific frameworks.
Yoann’s take
My default starting point is single-agent. I move to multi-agent when one of three conditions is true: the problem genuinely has independent sub-tasks that can run in parallel for material latency benefit, the specialists need very different tool sets that cannot fit in one context, or the work involves genuine critique loops that benefit from a separate critic agent. Most “we need multi-agent” requests fail those tests and end up better served by a single agent with more tools or a prompt-chain pattern. When multi-agent is the right call, my framework is LangGraph for production and CrewAI for prototyping. The mistake to avoid: starting with multi-agent because it sounds sophisticated. Sophistication is meeting the requirement at the lowest necessary complexity, not the highest possible.
— Yoann
Related reading
- Agentic AI Architecture Patterns
- Production Patterns for Agentic Systems
- Cost and Latency Budgeting for AI
- What Is an Agent, Really
External references
- LangGraph multi-agent documentation
- AutoGen patterns library
- Temporal AI workflows blog series