A tree of agents delegating to agents multiplies throughput and hides work in equal measure, and the second effect is the one nobody plans for.
The appeal of a subagent hierarchy is obvious the first time you use one properly. One agent decomposes a task, hands pieces to several workers, those workers run in parallel, and the whole thing that would have taken you an afternoon sequentially finishes in the time the slowest branch takes. I use this pattern constantly now — an orchestrator that plans and verifies, workers that execute. The throughput gain is real and I wouldn't give it back.
What I underestimated when I started was how completely a hierarchy like this can hide its own state from you. When one agent is working, you can watch it. When five agents are working and each of them has, in turn, spawned two more to handle sub-pieces, you are no longer watching agents — you are watching a report about agents, written by an agent, about other agents you cannot see. Every layer between you and the actual work is a place where something can go wrong and get summarised into something that sounds fine. The summarising itself is the risk: a layer that is honestly trying to be helpful will compress three paragraphs of caveats and partial failures into one clean sentence, because that is what a good summary does, and the caveats are exactly the part you needed to see.
The specific failure I've hit more than once is a worker reporting a task complete because a subagent it spawned reported completion to it, and that subagent's own claim was never independently checked against anything real — no test run, no file diff, no screenshot. Confidence doesn't attenuate as it passes up the tree. If anything it compounds, because each layer rephrases "probably done" as "done" on its way up, and by the time it reaches you it reads as fact.
The rule that has actually helped is to cap how deep delegation is allowed to go and to make every layer's claim contingent on evidence a layer above it can check directly — a passing test command, a diff, a file that exists on disk — rather than on prose from the layer below. A subagent that says "I fixed it" is a claim. A subagent that pastes the actual test output showing pass counts is evidence. Only evidence should be allowed to cross a layer boundary; prose summaries should stay local to whichever layer produced them. A cap on depth matters for a separate reason too: past three or four levels, the cost of coordinating the tree starts to exceed the throughput it buys, because every extra layer is another place a message can be misread on the way down and another place a result can be softened on the way back up.
The other thing that matters is naming and visibility discipline that scales with the tree, not against it. When you have one agent, you know what it's doing because you're looking at it. When you have a tree, the only way to keep that property is to make every node identifiable and every node's output inspectable on demand — which agent, working on what, spawned by whom, reporting to whom. Skip that and the hierarchy stops being a tool you're directing and becomes a haunted house: work is happening somewhere in the structure, results are arriving, and you have no reliable way to trace either back to a cause.
I still build deep hierarchies when the task genuinely decomposes that way. But I've stopped trusting a hierarchy to self-report its own health. The orchestrator layer's real job isn't decomposition — decomposition is the easy part. Its real job is verification: pulling real evidence up through every layer of the tree instead of accepting the tree's own word for what it did, because a five-level delegation chain that only ever tells you good news is not a sign that everything went well.