# Day 43: When hierarchy helps multi-agent work scale

What happens when the control tower itself gets overloaded? You give it managers.

Agent hierarchy is context management wearing an org chart. One supervisor coordinating fifteen specialists eventually drowns in its own tracking state: too many threads, too much status, too many decisions in one context window. So you insert a layer: a director reasoning about three managers, each managing five workers, with no single agent holding the whole operation.

## Compression is the feature and the bug

Results roll upward as summaries. Each level trades detail for span of control, and that compression is precisely the point. It is what lets the director think strategically without drowning in worker-level minutiae.

It is also where information dies. Every summarisation hop loses fidelity, in both directions: instructions dilute travelling down, findings blur travelling up. A worker surfaces a subtle but critical caveat; the manager compresses it into a bullet; the director never sees it and decides without it.

So design the exception explicitly: **which findings must bypass compression and travel raw?** Safety issues, contradictions, blocked work, anything that invalidates a premise the level above is relying on. Without a defined escalation channel, hierarchies systematically lose exactly the information that would have changed the decision.

## The adoption test is structural

Hierarchy fits when the work itself nests. Portfolios containing projects. Codebases containing modules containing files. Regions containing accounts. There, the levels correspond to something real, and each one has genuinely distinct authority.

If your task graph is flat, adding layers adds hops, tokens, latency, and places to lose detail while organising nothing. The tell is easy to check: **if two levels make the same kind of decision, one of them is ceremony.**

## Bound the escalation

Hierarchies invent a failure mode the flat supervisor pattern does not have: escalation loops. A worker escalates to its manager, which escalates to the director, which pushes back down, which escalates again.

Each hop looks reasonable. The cycle is not. Give escalation a depth limit and a terminal authority — someone, ultimately a human, who decides rather than forwards.

## Closing thought

Hierarchy scales delegation when responsibility genuinely nests. Applied to flat work, it is middle management for software: more meetings, same decisions, slower.

*Day 43 of 60 Days of Production AI Systems.*

---

**Previous:** [Day 42: Why supervisor agents help and where they bottleneck](https://blog.vamsiannamreddy.com/day-42-why-supervisor-agents-help-and-where-they-bottleneck)  
**Next:** [Day 44: Why dynamic dispatch needs ownership rules](https://blog.vamsiannamreddy.com/day-44-why-dynamic-dispatch-needs-ownership-rules)  

*Day 43 of 60 · Multi-Agent Design Patterns (chapter 8 of 10)*