Subagents on Subagents: How Many Layers Deep Is Too Many?

Agents are starting to spawn agents. Give an agent a sufficiently large job and one increasingly common strategy is delegation. The parent agent decides that part of the work should be handled somewhere else, spins up a subagent with its own context and instructions, waits for the result, and continues. That subagent may eventually do the same thing.

There are good reasons to work this way. A subagent can have a narrower job, a cleaner context window, different tools, or instructions specialized for the task it has been given. It can also do a large amount of exploratory work without dumping all of that context back into the parent. Once agents can delegate recursively, though, an obvious question appears: how many layers deep should we let them go?

I don’t think there is a magic number. Two layers isn’t inherently safe and five layers isn’t inherently reckless. The more useful question is what happens when something goes wrong at each layer, and how much of the graph now depends on the mistake.

Subagents turn agent execution into a graph

You can think about a parent spawning subagents as a tree. The parent delegates to several workers, some workers delegate again, and results eventually flow back toward the top. But real systems quickly become more complicated than trees.

One agent’s research becomes another agent’s input. Several branches get joined together. A reviewer evaluates the output of a worker. A planner produces a plan that several executors follow. Some branches run in parallel while others cannot begin until their dependencies finish. At that point, you have a graph.

That is roughly what people have started calling graph engineering: making the nodes, dependencies, routing, and state transitions between pieces of agentic work explicit. This framing changes the way we think about subagents because instead of asking only, “How many agents are running?” or “How deeply are they nested?”, we can ask what each node produces, which other nodes consume it, and what portion of the eventual result depends on it.

That is a much more useful way to reason about reliability because not every node carries the same amount of risk. Some nodes sit at the edge of the graph and produce a small, isolated contribution. Others sit high in the graph and establish the premises that many later nodes will use.

Errors have a blast radius

Imagine an agent producing a competitive analysis. The first agent decides which competitors matter. Three subagents research those companies. Their outputs feed another agent that compares the products. That comparison goes to another agent that identifies strategic threats, and a final agent writes recommendations.

If the final writing agent phrases one recommendation poorly, you have a fairly localized problem. Most of the underlying work is still intact. If the first agent picks the wrong competitors, everything downstream can be perfectly executed and the final answer can still be wrong.

The important distinction is where the error entered the graph and how much work depends on it. An upstream node does not merely contribute one incorrect output. It can establish the premises under which many downstream agents operate, and those agents may then reinforce the mistake because, from their perspective, the bad output is simply part of their input.

A mistake at a leaf may damage one leaf. A mistake near the root can poison an entire branch, and the problem gets worse with fan-out. Suppose one planning agent produces a decomposition that feeds ten workers. An error in that plan now has ten opportunities to propagate, and those workers may each produce outputs that feed additional nodes.

The number of layers matters, but the downstream influence of each layer matters more. A deeply nested agent working on an isolated task may have very little impact on the final result, while a shallow agent making an early routing or planning decision may determine everything that follows.

Every handoff can harden a mistake

There is another problem with deeply nested subagents: information gets transformed at every boundary. A subagent might inspect twenty documents and return a five-paragraph summary. Its parent uses that summary to create a plan. Another agent receives part of the plan and turns it into an analysis, while a final agent synthesizes several analyses into a recommendation.

Each step may be individually reasonable, but each one is operating on the artifact produced by the previous step rather than necessarily on the original evidence. That means a small mistake can gradually become an assumption.

Recursive delegation makes this particularly easy to miss because the parent often does not see everything its descendants saw. Context isolation is part of the benefit of subagents, but it also creates distance between the final decision and the evidence that originally supported it.

Graph engineering should be dependency engineering

This is why I think one of the most important parts of graph engineering will be deciding what is allowed to depend on what. If an agent produces something with enormous downstream influence, that node deserves more scrutiny than a node producing an isolated piece of the final response.

Maybe it should have a verifier. Maybe its output needs to be structured. Maybe the original evidence should travel alongside its conclusion. Maybe several agents should independently produce the result before the graph moves forward. In some cases, a human may need to approve it before the artifact is allowed to fan out into the rest of the graph.

The graph makes these decisions visible. Instead of one agent recursively spawning workers and passing summaries around however it sees fit, you can explicitly model something like evidence → analysis → plan → execution → synthesis and decide which artifacts cross each boundary.

You can also decide where branches fan out, where they join, where provenance needs to be preserved, and where checks should happen before a high-impact artifact becomes the premise for another five nodes. Graph engineering gives us more than a way to coordinate agents. It gives us a way to control the propagation of uncertainty through the system.

So how deep is too deep?

I don’t think the answer is three agents or four layers or some other universal limit. A deep graph where each node has a narrow responsibility, strong inputs, explicit outputs, and limited downstream influence may be quite reliable. A shallow graph can be extremely fragile if one early agent makes a broad judgment that every other agent blindly accepts.

The metric I care about is closer to blast radius. For any agent-generated artifact, ask what else becomes wrong if that artifact is wrong. If the answer is one small part of the final output, you can probably tolerate a fairly agentic node. If the answer is every remaining step in the workflow, that node deserves a very different engineering standard.

As agents get better at spawning subagents, it will become increasingly easy to build impressive towers of delegation. Agent A asks Agent B, which asks Agents C and D, which each spin up their own workers, and eventually a polished result bubbles back to the surface. The engineering challenge is not how deep we can make those graphs, but whether we understand which nodes have enough downstream influence to bring the rest of the graph down with them.