Delegation Depth Limits: How Deep Should Subagents Go?

Set the runtime maximum depth at two levels below the orchestrator. That gives you three roles: orchestrator, worker, checker. This covers the most common reliable pattern, a maker that produces and a checker that validates, with the orchestrator assembling the final result.

Allow three levels only when all four of these conditions hold:

1. The task decomposes into independent subtasks, not a sequence. Sequential steps belong in one agent with a turn limit, because each nested call creates an irreversible context split (the nested subagent guide).
2. Each subtask's output can be verified mechanically: schema validation, tests passing, a diff applying, a numeric tolerance. If a human has to judge whether the leaf did good work, depth buys you nothing.
3. The leaf returns a compressed result. A useful stop rule: write the summary you expect on a sticky note. If it is under about 500 tokens, or the parent could produce it with two tool calls, do not nest (the nested subagent guide).
4. A per-branch token budget and a wall-clock timeout apply at each hop.

Reject anything deeper unless a named owner signs off for a specific task type. That is not bureaucracy: it is the only way to keep the exception from becoming the default.

Microsoft's guidance points the same direction: use the lowest level of complexity that reliably meets requirements, because each level adds coordination overhead, latency, and failure modes (Azure Architecture Center). A single agent with good tools is often the right default for enterprise work.

Before you argue about the number, measure it. Three quantities matter per hop.

Latency. Take the median latency of one model call in your workload, then add the fixed cost of a handoff. Published production figures give a sense of scale: a four-agent sequential pipeline accumulated roughly 950ms of coordination overhead while actual processing took 500ms, and a three-agent pipeline consumed 29,000 tokens versus 10,000 for an equivalent single-agent approach (the production patterns survey). Those numbers are from one team's pipeline, so measure yours, but expect coordination to cost roughly as much as the work.

Tokens. Each hop resends a system prompt, the delegation prompt, and the returned summary. Multiply by the branch count. An orchestrator with four workers each spawning two children has eight leaf conversations plus four intermediate ones plus the orchestrator, and the orchestrator pays to read every returned summary. The production survey notes that at four or more workers, orchestrator context frequently exceeds window limits (the production patterns survey).

Failure probability. If a single call fails or drifts with probability p, and a branch makes n calls, the branch is reliable only if every call succeeds. With p = 0.02 and 10 calls, about 18% of branches have at least one failure. That is why verification at each level, not just at the top, matters.

Here is a worked depth budget for a concrete task: reviewing a 40-file pull request for security, performance, and style issues.

• Depth 0 (one agent): about 12 model calls, one context, roughly 40,000 tokens read in one window. Simple to debug, but the context fills and later files get less attention.
• Depth 1 (orchestrator plus three reviewers): three worker conversations running in parallel, each returning a summary. Estimate 3 x (system prompt + 12 file reads + summary) plus the orchestrator's dispatch and aggregation. Roughly 3x the token cost of depth 0 for better isolation and wall-clock time near the slowest reviewer.
• Depth 2 (each reviewer spawns a per-directory checker): with 40 files across 8 directories, you get 24 leaf conversations plus 3 reviewer conversations plus 1 orchestrator. Token cost roughly doubles again versus depth 1, and every leaf needs its own budget or one runaway directory eats the branch allowance.
• Depth 3 would only pay off if directories themselves needed recursive exploration with per-package conventions and rolled-up summaries (the nested subagent guide). For a 40-file review, it does not.

The decision rule falls out: depth 2 buys parallel isolation and a verification layer for roughly 2 to 3 times the single-agent token cost. Depth 3 buys more only when the work is genuinely tree-shaped. Below that threshold, the extra level is overhead you pay for twice, once in tokens and once in debugging.

A limit written in a prompt is a suggestion. A limit enforced in the runtime is a control. Four guardrails do the work.

1. Runtime depth check with rejection. Pass current depth in the delegation payload. When an agent tries to spawn a child that would exceed the cap, the runtime returns an error the parent must handle, not a warning it can ignore. Omit the spawn tool from agents at the maximum depth so the ceiling cannot be attempted at all; this is how one CLI caps nesting by withholding the tool at the deepest level (the nested subagent comparison).

2. Per-branch token and dollar budgets. Give each top-level branch an allowance, and deduct every descendant call from it. When the branch is exhausted, it stops and reports partial results rather than continuing until the request fails. The same survey that found $0.50 test runs turning into $50,000 monthly bills at scale is the argument for this (the production patterns survey).

3. Wall-clock timeouts at each hop. A total timeout is not enough; a slow leaf needs to be cut off without killing the branch. Set a per-call timeout, a per-level timeout, and a run-level deadline, and log which one fired.

4. Escalation paths. When a leaf fails verification or exhausts budget, the branch returns a structured failure to its parent with the reason. The parent either retries once with more context, escalates to a stronger model, or surfaces the item to a human. This is the human-in-the-loop pattern applied at depth: humans intervene during execution to approve or correct actions that carry material consequences (the HITL deployment guide). For high-risk task types, make the approval record part of the audit trail, bound to the same trace as the action it authorized (the audit trail guide).

A minimal enforcement sketch:

MAX_DEPTH = 2
RISK_EXCEPTIONS = {"security-review": 3}  # task types with a named owner

def spawn(parent_ctx, task, task_type):
    limit = RISK_EXCEPTIONS.get(task_type, MAX_DEPTH)
    if parent_ctx.depth + 1 > limit:
        return {"status": "rejected", "reason": "depth_limit", "limit": limit}
    if parent_ctx.branch_tokens_left <= 0:
        return {"status": "rejected", "reason": "budget_exhausted"}
    return run_child(task,
                     depth=parent_ctx.depth + 1,
                     deadline=min(parent_ctx.deadline, now() + PER_HOP_TIMEOUT),
                     branch_budget=parent_ctx.branch_tokens_left)

Two details matter here. The exception list is keyed by task type and requires an owner in config, not in the prompt. And the deadline and budget are inherited downward, so a child can never outlive or outspend its parent.

Depth limits fail in production for an observability reason: the trace breaks at delegation boundaries. When an orchestrator enqueues work for a worker, or a worker calls another agent, there is no HTTP request carrying trace headers, so each delegation starts a fresh root span and the causal chain is lost (the tracing guide).

The fix is explicit context propagation. Capture the active span context, serialize it into the delegation message using the propagator, and reattach it on the other side so children create spans under the parent (OpenTelemetry context propagation). The format is standardized: a traceparent header carries version, trace ID, parent ID, and flags, and it can travel through any medium, including a message body or a database row (W3C Trace Context).

The industry is converging on conventions for agent-to-agent calls specifically. A proposal for distributed tracing in A2A systems puts traceparent and tracestate in message metadata under an extension key, names spans using the OpenTelemetry GenAI pattern (invoke_agent {agent_name} for client-side delegation), and adds a small set of agent-specific attributes (the A2A tracing proposal).

Once traces are connected, you can answer the questions that set your limit:

• What is the p50 and p95 latency of a delegation edge, by depth?
• What share of branch tokens are spent at each depth level?
• How often does a branch at depth n fail verification, versus depth n-1?
• Which task types actually benefit from the exception, and what do they cost?

Diagnostic signs to watch for, per the tracing guide: root spans with no parent appearing mid-sequence, trace ID discontinuities between the request entry and a later agent, tool call spans appearing as roots, and timing gaps with no explaining span (the tracing guide). Any of these means you are measuring fragments, not the tree, and your depth budget is guesswork.

Every extra level should buy one of four things: context isolation, parallelism, a security boundary, or a verification gate. If it buys none of them, cut it.

Spend a level when the work is a tree rather than a list, for example a monorepo where each package needs its own scoped exploration with its own conventions and rolled-up summaries (the nested subagent guide). Spend one when a research or review subtask drowns in raw output and a child can distill it before the parent sees anything.

Do not spend a level when the steps depend on each other. Five sequential steps belong in a single agent with a turn limit, not five nested calls, because each nesting adds an irreversible context split (the nested subagent guide). Do not spend one when the leaf would call a single tool: at that point you are paying a full agent prompt and a handoff to wrap one function call. And do not spend one when workers need to talk to each other. Nested agents communicate up and down, never sideways; peer coordination is a different architecture (JetBrains on orchestration).

Risk should tighten the limit, not loosen it. A workflow that can modify production systems, move money, or send external communications deserves fewer levels and more gates, because every hop is another place where intent can drift and another set of model calls that must be audited. The audit argument is simple: tool traces show what was called, but proving control requires a decision record that binds the agent, its delegation chain, the resource, the policy version, and any approval, all joined by correlation ID (the audit trail guide).

Delegation helps most when the parent receives only the conclusion and not the work that produced it (the orchestration guide). Depth is how many times you apply that trick. Each application costs tokens, latency, and traceability, so charge for it accordingly.

If you are building this out and want one endpoint for the text, image, embedding, and audio models your orchestrator and workers will call, with OpenAI-compatible requests and prepaid billing, Quanta Inference (https://quantaintelligence.ai/inference) is the natural next step.