Pattern 01: the central orchestrator
How does the orchestrator pattern work?
The lead receives the goal, writes a plan, and hands each subagent a narrower task with its own instructions and tools. Subagents work, often in parallel, and return results. The lead evaluates them, may send another round, and writes the final answer. In LangChain's terms, "all routing passes through the main agent." (LangChain multi-agent docs)
orchestrator-worker pattern, where a lead agent coordinates the process
Anthropic built its research feature this way, with specialized subagents running in parallel. With an Opus 4 lead and Sonnet 4 subagents, the system "outperformed single-agent Claude Opus 4 by 90.2%" on their internal research eval.
Microsoft's Magentic orchestration is the same idea with a planner on top: "A manager agent dynamically coordinates specialized agents." (Microsoft Agent Framework orchestrations)
Why do teams pick a central orchestrator?
It is easy to reason about. There is one place to read the plan, one place to add guardrails and one trace to debug. Parallel subagents cut wall-clock time on breadth-first work such as research. And because the lead holds the full picture, it can decide when the job is done, which is the single hardest thing to get right in multi-agent systems.
Where does the orchestrator pattern break?
The lead becomes a bottleneck. Anthropic notes "our lead agents execute subagents synchronously," so the whole system waits for the slowest subagent. Going asynchronous "adds challenges in result coordination, state consistency, and error propagation."
The lead only knows what subagents report. A subagent that discovered a constraint, and summarized it away, leaves the lead planning on bad information. That is the failure Cognition warns about when it says to share "full agent traces, not just individual messages." (Cognition)
It assumes one owner. An orchestrator in LangGraph cannot directly direct a Copilot Studio agent owned by another team without protocol work. Microsoft's Copilot Studio docs list real costs of chaining agents: citations may not persist between agents and every orchestration hop adds latency. (Copilot Studio multi-agent docs)
It costs tokens. Multi-agent systems use "about 15× more tokens than chats," per Anthropic.
When does the central orchestrator pattern work, and when does it break?
When it works
- The task splits into separable subtasks
- One team owns all agents
- Steps are mostly predictable
- You want one trace to debug
- The lead can judge “done”
When it breaks
- Subtasks depend on each other in real time
- Agents live in different frameworks or vendors
- Humans need to step in mid-task
- The lead's context window becomes the limit
- Latency matters more than thoroughness
Which tools use the central orchestrator pattern?
| Tool | How it coordinates | Good for | Source |
|---|---|---|---|
| LangGraph | Subagents as tools, all routing through a main agent; explicit graph | Python/TS teams wanting control | LangChain docs |
| Microsoft Agent Framework | Magentic manager agent; graph workflows; human-in-the-loop on all orchestrations | .NET and Python on Azure | Microsoft Learn |
| CrewAI | Hierarchical process “automatically assigns a manager” | Role-based crews | GitHub |
| Mastra | Supervisor agent delegates using each subagent's description | TypeScript teams | Mastra docs |
| IBM watsonx Orchestrate | Supervisor-style routing across agents and tools, with agent management | Enterprises on IBM | IBM |
| OpenAI Agents SDK | Agents as tools (manager style) | Lightweight Python/TS apps | OpenAI docs |
What do people ask about the central orchestrator pattern?
Not sure which pattern fits?
Six questions, about a minute. You'll get a pattern, a shortlist and the tradeoffs.
Last reviewed: September 2026