Running subagents in parallel has been possible for a while, but one constraint always felt cramped to me: a subagent could not delegate further. In the automated blog pipeline I run as an indie developer, the generation subagent had to carry quality checks and consistency validation inside its own context, and the parent agent ended up relaying every intermediate step — a middle-management traffic jam, essentially.
The June 2026 update removed that ceiling. Subagents can now spawn their own subagents, nested up to five levels deep. I rebuilt the delegation structure of my solo-dev publishing pipeline around it, and my short answer so far is this: just because you can go five levels deep does not mean you should. Here is how I arrived at that conclusion.
From a Flat Fan-Out to a Delegation Tree
Until now, a subagent setup was a single-tier fan: one parent launching several peers, with no further delegation below them. With nesting, a child can launch grandchildren, and you can design the whole thing as a tree.
This matters wherever task decomposition is naturally recursive. "Update articles across four sites" splits into per-site child tasks, which split again into generation and verification. Previously the parent had to manage that third tier directly, which meant cross-site details leaking into the parent's context. With nesting, each site's messiness stays contained under its own child, and the parent only sees aggregated results.
Dynamic workflows (currently in research preview) also build multi-tier agent structures, but they are composed on the workflow-definition side. Nesting, by contrast, lets you shape the tree purely through prompt design. I wrote about the former in Running Claude Code's Dynamic Workflows: What I Learned About Orchestrating Subagents.
The First Wall: The Telephone-Game Problem
On day one I deliberately tried a full five-level stack: planning → per-site → article generation → section writing → proofreading. It worked, technically. But looking at the output, one thing stood out: every level you descend, the upstream intent fades a little.
Each subagent runs in an isolated context, and the only thing it can hand back to its parent is a final text report. So a five-level tree delivers a summary of a summary of a summary to the root. In my case, fine-grained style constraints specified by the parent had evaporated by around level three and never reached the proofreader at level five. The reverse direction suffers too: a meaningful red flag spotted at the bottom layer arrived at the top compressed into a single passing sentence.
Cost scales just as honestly. If each level fans out, call counts multiply: three levels at three-way parallelism is 27 invocations; four levels makes it 81. Depth buys you context isolation, but it charges you information decay and cost on the same receipt.
My Conclusion: Match Depth to the Number of Distinct Responsibilities
After a few days of experimenting, I settled on a rule: the number of levels should equal the number of genuinely distinct responsibilities in the task. My pipeline has three — overall planning and aggregation, per-target execution, and artifact verification — so I stopped at three levels.
- Parent (planning): checks topic overlap and assigns what gets written for which site. It never touches article content
- Child (execution): generates one site's article and keeps all reference-data loading inside its own context
- Grandchild (verification): runs the quality gates and returns a verdict. Separating generation from verification also avoids the classic failure where a writer grades its own homework too kindly
The useful question, whenever I am tempted to add a fourth level, is whether the new layer represents a new responsibility or merely a subdivision of an existing one. Section writing is a subdivision of execution, not a new responsibility — so it belongs in the child's prompt as a procedure, not in the tree as a level. Drawing that line made the whole structure far easier to reason about.
Working Rules for Deep Delegation
A few rules hardened while getting the three-level setup stable.
Give every level an explicit output contract. As a countermeasure to summary decay, each subagent's instructions end with a mandatory report format. I paste a fragment like this into every child and grandchild prompt:
## Report format (required, no omissions)
- Artifact path: <absolute path of the file generated/verified>
- Verdict: exactly one word, PASS or FAIL
- If FAIL: quote the violating text verbatim (do not paraphrase)
- Notes for the level above: 1-3 linesThe "quote verbatim, do not paraphrase" line earns its keep. Without it, a violation found by the verifier reaches the top softened into "minor issues noted."
Pass large state through files, not reports. The more data crosses level boundaries, the faster report-based handoff collapses. Writing artifacts and intermediate data to files and putting only paths in the report proved far sturdier. I covered the trade-offs in Three State-Passing Patterns for Claude Code Subagents — Lessons from 4 Months of Automated Blog Pipelines.
Assume a silent grandchild is invisible from the root. The deeper the tree, the more a stalled bottom-level task looks, from above, like nothing more than "the child is slow." Giving each level a timeout guideline plus an instruction to cut losses and report partial results prevents one stuck leaf from dragging down the whole run. For actually diagnosing the stuck agent, the steps in Diagnosing Claude Code Subagents That Stall or Never Return applied unchanged.
Start by Demoting One Relay-Only Step
I think the healthiest reading of the five-level limit is not "a feature to max out" but "a design ceiling that no longer binds you." If you already run subagents in parallel, my suggested first step is small: find one step where the parent merely relays results from one child to another, and move it under the child instead. You will feel the parent's context getting lighter the same day.
I am only a few days into running this structure, so its long-term stability is still something I am watching. If you are building multi-tier automation of your own, I hope these notes save you a detour.