You built an agent. It works.
Now you need 5 of them running in parallel, sharing state, and handing off work to each other.
Your pipeline breaks on the first real workload.
Here's the setup:
You're building a research agent system. A user asks a complex question. You need to:
• Fan out to 3 specialized sub-agents simultaneously
• One agent might spawn 2 more based on what it finds
• They all write back to shared context
• A final agent synthesizes everything
Classic multi-agent orchestration. You have 4 options for how agents coordinate.
A) Centralized Orchestrator — one controller agent dispatches tasks, collects results, manages shared state. Agents are dumb workers.
B) Decentralized Peer Handoff — each agent decides who gets the task next. No central controller. Agents communicate directly.
C) Shared Message Queue + Blackboard — all agents read/write to a shared blackboard. Coordination happens through state, not calls.
D) Hierarchical Nesting — orchestrator spawns sub-orchestrators. Each sub-tree is self-coordinating. Recursive decomposition of the problem.
Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments.
Drop your answer 👇
Top comments (4)
Answer: A — Centralized Orchestrator
Here's the full breakdown — and where each pattern actually belongs:
Why A wins (Centralized Orchestrator):
One agent owns the plan. It dispatches, collects, retries, and synthesizes. Every sub-agent is stateless and dumb on purpose — they receive a task, return a result, done.
This isn't a limitation. It's a feature.
When something fails, you know exactly where to look: the orchestrator. It holds the retry logic, the timeout budgets, the fallback paths. Sub-agents can die and restart without corrupting global state because the orchestrator is the only one maintaining it.
LangGraph, CrewAI, and every production-grade agentic framework defaults to this model for a reason. It's debuggable, observable, and deterministic. You can replay an orchestrator run from its state log. Try doing that with peer-to-peer handoffs.
Why B is the trap (Decentralized Peer Handoff):
This sounds elegant in theory. Agents self-organize, no bottleneck at the top.
The problem: who resolves conflicts? If Agent A hands off to Agent B, and Agent B decides the task actually belongs to Agent C, which also hands it back to Agent A — you have a cycle with no circuit breaker.
Peer handoff works in closed, well-defined pipelines (like a Git commit hook chain). It breaks the moment you have conditional routing, error recovery, or parallel fan-out.
Why C is partial credit (Shared Blackboard):
A shared blackboard is real and useful — but as a data layer, not a coordination mechanism.
Agents writing to and reading from shared state works for passing context. What it can't do cleanly is orchestrate who runs next, when, and with what inputs. You end up building an implicit orchestrator via polling — same thing, no visibility into it.
Use a blackboard for state sharing. Use an orchestrator for task routing. They're complementary, not alternatives.
Why D fits a specific problem (Hierarchical Nesting):
Hierarchical orchestration is the right model when the problem itself is hierarchically decomposable — like a pipeline where "summarize AI papers" fans out to 10 sub-tasks, each of which fans out further.
The catch: recursion adds latency and debugging complexity at every layer. If your problem doesn't naturally decompose into clean sub-trees, you're adding indirection for no gain. Default to flat centralized orchestration first. Reach for hierarchical only when the problem demands it.