E3 · Hierarchy

Family: Multi-agent

Nested orchestrators: a supervisor of supervisors, with recursive decomposition.

Principle

Instead of a single orchestrator, several levels: each supervisor splits its share of the problem and hands it to sub-supervisors or agents. The decomposition is recursive, like Russian dolls. Each subtree has an owner.

The problem it solves

A very large problem, or an organisation split across several teams, exceeds what a single orchestrator can keep in mind.

When to use it

  • Very large open-ended problems (research, planning), where decomposition naturally happens over several levels.
  • Multi-team organisations, where each subtree has a distinct owner.

When to avoid it

  • Almost always at the start: each level adds latency, cost and information loss. Begin with a single orchestrator (E1).

Common pitfalls

The anti-patterns that misuse this pattern, best established first. Each sheet describes the symptoms, the public incidents and the remedies.

Loop, stopping and orchestration

  • AP39 · Unchecked propagation — One agent’s output becomes the next one’s input unchecked, and a local error ends up in the deliverable.
  • AP38 · Vague delegation — A subtask handed over in a few words: whatever is not written in the brief does not exist for the subagent.
  • AP45 · Multi-hop latency — LLM calls chained in series with no latency budget: the answer arrives after the sum of every step.

All anti-patterns

Synonyms by vendor

  • Hierarchical task decomposition (Google Cloud)
  • The Russian doll (Google ADK)
  • Hierarchical (LangGraph)
  • Hierarchical orchestration (AWS)

Neighbouring patterns

Sources

Content reviewed on 2026-10-02

Pattern catalogue