Red Hat puts hierarchy, not agent count, at the center of multi-agent scale

A new Red Hat engineering account argues that multi-agent systems hit a coordination limit before they hit a context-window limit. Its proposed remedy is hierarchical orchestration: a top-level planner routes work to domain orchestrators, which then coordinate their own specialists.

The pattern grew out of an enterprise troubleshooting assistant spanning documents, source repositories, chat history and infrastructure. In the initial design, each source had a specialist agent and a final model merged their outputs. That worked for parallel lookups but produced disconnected summaries when an answer depended on the relationship between sources.

Why a merger is not an orchestrator

A merger waits for one round of outputs and combines them. Red Hat’s replacement plans before delegating, rewrites a broad request into prompts suited to each specialist, reviews partial answers and can ask an agent to investigate again when another result exposes a gap or contradiction.

That distinction matters for incident questions. A chat message may establish when an application failed, the cluster may expose a restart loop, and the repository may reveal a missing production environment variable. The useful answer is the causal chain across those sources, not three individually correct summaries.

One coordinator also reaches a ceiling

Putting every specialist behind one orchestrator fixes ownership but expands the model’s routing decision on every turn. Red Hat describes the resulting failure mode as attention dilution: the orchestrator delegates too widely, chooses the wrong specialist or sends duplicate work as the catalog of agents grows.

The hierarchical design narrows that catalog. A top-level orchestrator chooses among a small number of domains; each domain coordinator knows its local agents and context. Red Hat argues that this makes routing sharper and contains weak output inside one branch instead of mixing every coordination path in one prompt.

The price of hierarchy

More orchestration layers mean more model calls, latency and opportunities for routing errors. A flat merger remains cheaper for low-stakes aggregation. The hierarchy becomes easier to justify when work requires follow-up investigation, nested recovery or reasoning across sources.

The post does not provide comparative evaluation data, so the architecture should be treated as a design hypothesis backed by implementation experience rather than a measured scaling law. Teams adopting it still need routing-quality tests, traces for delegation failures, explicit memory boundaries and budgets for tokens and end-to-end latency.

A practical starting point is to compare three versions of the same workflow: direct fan-out and merge, one active orchestrator, and two-level domain routing. Measure task completion, duplicate calls, wrong routes, recovery behavior and cost. The central lesson is testable: adding specialists is only useful while the coordination layer can still decide who should do what next.