multi-agent-orchestration
Multi-Agent Orchestration
A multi-agent system is one where two or more LLM-powered agents collaborate, each with its own context window, tools, and (usually) prompt. The right reason to build one is separation of concerns that a single agent can't handle in one context: parallel work that would otherwise serialize, specialized expertise that bloats one agent's prompt, or scopes that need different tool access.
The wrong reason — and the most common one — is "agents are cool." A multi-agent system costs more (10-15x token usage is normal vs. a single-agent equivalent for the same task; Anthropic's reported figures in their multi-agent research system), introduces failure modes single agents don't have (cascading errors, coordination bugs, infinite delegation loops), and is significantly harder to debug. Reach for it when the alternative is worse, not by default.
The companion skill agent-design covers single-agent fundamentals — the agent loop, tool design, context management, runaway control. This skill is about what changes when there's more than one.
When to actually use multi-agent
Reach for multi-agent when at least one of these is true:
| Signal | Why it justifies the complexity |
|---|---|
| Parallel research over many sources | One agent reads 30 docs serially; ten agents each read 3 in parallel. The wall-clock saving is the point. |
| Specialization with conflicting context | A code-writing agent wants different system prompts, tools, and examples than a code-reviewing agent. Forcing them into one prompt produces a worse version of both. |
| Different tool/permission scopes | A "planner" agent shouldn't have file-write access; an "executor" agent shouldn't have access to PII the planner saw. |
| Workflow with verifiable handoffs | Researcher → writer → editor, where each phase has a clear "done" state and the next phase doesn't need the previous phase's reasoning. |
| Distinct user roles in one system | Customer agent, supervisor agent, internal-tools agent — each modeling a real role with real constraints. |