Every topology has a structural weak spot. Knowing yours before you build determines whether the failure is survivable.
Key facts.
- In hierarchical manager-worker systems, the orchestrator accounts for 67.7% of failures and executors 32.3% — the single decision-maker is also the single largest failure point (MAST, arXiv:2503.13657, 2025).
- Debate topologies fail through sycophancy cascading: agents converge on the majority opinion rather than the correct one, and the group produces confident wrong answers (Galileo AI, 2025).
- Microsoft's AutoGen engineering team recommends a hard limit of three agents in group chat configurations to limit sycophancy and non-convergence (Microsoft AutoGen, 2025).
- 40% of multi-agent pilots fail within six months of production — and topology mismatch is cited consistently as a leading structural cause, ahead of model capability gaps (Gazzurelli, 2025).
Manager-worker: the orchestrator is your biggest single point of failure
Manager-worker is the most common multi-agent pattern. One orchestrator holds the plan and delegates sub-tasks to specialized workers. It is the right choice when tasks decompose cleanly into independent parallel sub-tasks and the orchestrator can maintain global state across them.
The failure mode is concentrated at the top. If the orchestrator misunderstands a worker's output, replans from stale state, or loses track of which sub-tasks are in flight, the entire plan degrades. Workers are locally correct; the orchestrator's integration error makes the system wrong. MAST data confirms this concentration: 67.7% of failures in hierarchical systems trace to orchestrator behavior, not worker behavior.
The practical implication: invest your observability budget at the orchestrator boundary. Log every worker output the orchestrator receives and every planning decision it makes immediately after. The gap between those two data points is where most hierarchical failures live.
Debate topologies: why more perspectives produce false consensus
Debate topologies — where agents propose, challenge, and refine answers in a group — sound like a natural fit for high-stakes decisions. The theory is that adversarial pressure improves answer quality. The production behavior is often the opposite.
LLMs trained on human text learned that agreement is a social positive. When one agent stakes out a position with confidence, other agents weight their updates toward the majority position. After two or three rounds, all agents have converged — but on the first confident answer, not the best answer. This is sycophancy cascading, and it produces confident wrong outputs that are harder to catch than individual agent errors because the "consensus" looks authoritative.
Debate also fails to converge. Without a moderator enforcing round limits and a decision rule, agents argue indefinitely. Microsoft's hard limit of three agents in group chat configurations reflects production experience, not theory.
Relay and hub topologies: how information degrades with each hop
In a relay chain, each agent receives the prior agent's output, adds its own transformation, and passes the result forward. The appeal is simplicity. The failure mode: errors from step one arrive at step two, which cannot distinguish input error from input truth. By step five, a minor upstream mistake has been treated as ground truth by four subsequent agents and is now deeply embedded in the output.
Hub topologies replace the chain with a central agent that routes outputs from any specialist to any other specialist. The hub adds bottleneck risk — all traffic flows through one agent — and paraphrase loss risk. When the hub summarizes Agent A's findings for Agent B's consumption, it introduces the hub's interpretation, not Agent A's raw output. Agent B is now acting on the hub's reading, not on A's data.
The fix for both: prefer direct agent-to-agent schema-validated communication over relay or hub-mediated relay. Each agent gets the original output from its predecessor, not a paraphrase.
Each topology has a characteristic failure signature. Knowing the signature lets you add the right guard before it fires.
| Topology | Best for | Primary failure mode | Guard |
|---|---|---|---|
| Manager-worker | Parallel independent sub-tasks | Orchestrator integration error (67.7% of failures) | Typed worker output + orchestrator observability |
| Debate / group chat | Multi-perspective evaluation | Sycophancy cascading + non-convergence | Max 3 agents + hard round limit + decision rule |
| Relay chain | Sequential dependent transformations | Upstream error accumulation | Validation gate at each hop before forwarding |
| Hub | Dynamic cross-specialist routing | Bottleneck + paraphrase loss | Direct schema-validated A-to-B where possible |
The topology you pick determines which failure modes are structurally possible in your system. VibeModel's Pattern Intelligence Layer maps which topology-task combinations in your deployment surface the highest failure rates so you can match shape to problem — and add the right guard for the specific failure that shape introduces — before it hits production.
Frequently asked questions
Which multi-agent topology is most reliable?
None is universally most reliable — each has a different failure signature. Manager-worker is reliable for parallel tasks with clean decomposition but breaks at the orchestrator. Debate is unreliable for most production tasks due to sycophancy. Reliability comes from matching topology to task structure, not from choosing a "safe" default.
What is sycophancy cascading in a debate topology?
Sycophancy cascading is when agents in a group chat progressively align with the first confident answer, regardless of whether it is correct. Each subsequent round increases convergence pressure. The result is a unanimous but potentially wrong conclusion that looks like high-quality deliberation.
Why does Microsoft recommend a limit of three agents in group chat?
Because empirical production data shows that sycophancy cascading and non-convergence both worsen with agent count. At three agents, a dissenting agent can still hold position. At five or more, majority pressure typically overrides any minority view within two rounds.
Can I switch topologies at runtime based on the task?
Yes, and some advanced systems do this. The risk is that dynamic topology switching requires the orchestrator to correctly classify each task before routing, and misclassification introduces the wrong topology's failure mode. Start with a static topology matched to your dominant task type; switch dynamically only once you have observability that shows the static choice failing.