multi-agent-orchestration

Multi-Agent Orchestration

Purpose

Splitting a task across multiple agents can reduce per-agent context load, allow specialization (a narrower system prompt and tool set per role), and enable parallelism — but it also multiplies the surface area for coordination failures: duplicated work, agents that silently disagree, lost context at hand-off boundaries, and cost/latency from redundant model calls. Multi-agent orchestration is not automatically better than a single well-designed agent; it is a specific tool for specific shapes of problem. This skill covers the common orchestration topologies (supervisor/worker, pipeline, debate/parallel-with-aggregation), when each is justified over a single agent, and how to keep hand-offs between agents reliable.

When to use

• A single agent's context or tool set has grown large enough that it shows role confusion or degraded performance on any one sub-task (a concrete threshold to check, established in agent-architecture-design, before reaching for multi-agent as a fix).
• A task naturally decomposes into independent workstreams that can run in parallel (e.g. researching three unrelated topics before synthesizing).
• A task benefits from specialist framing — a code-review sub-agent with a narrow reviewer persona genuinely produces better reviews than one generalist agent asked to "also review code" among ten other jobs.
• You need a distinct verification/critic role separate from the agent that produced the output, to catch errors the producing agent is blind to.
• Debugging duplicated work, contradictory outputs, or lost context between cooperating agents in an existing multi-agent system.

Prerequisites & environment

• A working single-agent implementation first — multi-agent orchestration should be an evolution from a scoped single agent, not a starting design, since most of its coordination problems only become visible once you've seen where a single agent actually strains.
• An orchestration mechanism: a supervisor process/agent that dispatches to sub-agents and collects results, whether hand-rolled or via a framework/runtime.
• A shared understanding across the team of what state, if any, is common vs. private to each sub-agent (see step 3 below) — undocumented shared state is the most common source of multi-agent bugs.
• Cost/latency budget awareness: N agents each making LLM calls costs roughly N× a single agent's calls for the same step, before accounting for coordination overhead (see llm-cost-and-latency-optimization).