Putting a Number on Depth

The limit belongs where the spawn is actually decided, not in the instructions handed to the model. A sentence in a prompt is a suggestion that holds until the model is under pressure or until untrusted content argues otherwise. A check in the dispatcher that refuses to spawn past a depth is a hard stop, and hard stops are what a bound needs to be.

The mechanism is simple to describe. Every task carries the depth it sits at. The orchestrator reads that depth, and when it equals the configured maximum it does not spawn; it runs the task itself with whatever tools it has. A common and useful setting is a maximum depth of one, which means a top-level agent may delegate, and every helper it creates is a leaf that finishes the work directly.

Reaching the maximum should not be treated as an error. A leaf that cannot divide its job any further is expected behaviour, and the right output is a completed result or an honest report that it could not finish. The wrong outcome is a leaf that returns a plan instead of a result, because a plan shaped like progress hides a task that never ran.

The reason to enforce this in code rather than in prose is that the failure is silent. An over-deep tree does not raise an error; it simply costs more and finishes later. Silent failures are exactly the ones that belong behind a structural check rather than a polite request.