Depth vs Breadth: Splitting a Delegation Budget

Write the budget as B. Before any splitting, subtract a reserve R for retries and verification. A workable default is 20 percent, so R = 0.2B and the allocatable pool is A = 0.8B. The reserve exists because agents fail multi-step tasks often: in simulation testing they fail nearly 70 percent of the time on multi-step office work, per an enterprise playbook on human-in-the-loop agents. You do not need to believe that number generalizes to your task to accept the implication: a plan with zero slack is a plan that has to succeed on the first try, every step.

Inside the allocatable pool, let d be chain depth and k be fan-out width at the deepest point. A pure chain of depth d costs d calls and produces 1 result. A pure fan-out of width k costs k calls and produces k results. A tree that branches b ways per level for L levels costs (b^(L+1) - 1) / (b - 1) calls, which grows geometrically and is the reason unbounded recursion burns budgets so fast. A real bug report describes exactly this: one delegation for "research Venmo integration options" spawned 48 or more background agents, most of them redundant, consuming over 1.5 million tokens, with the useful research done within the first three or four agents, as recorded in the Claude Code issue tracker.

Here is the same constraint set expressed as the arithmetic you can actually do before a run:

B = total subagent calls allowed
R = 0.2 * B          # reserve for retries and verification
A = B - R            # allocatable

pure chain:    cost = d,            results = 1
pure fan-out:  cost = k,            results = k
one branch:    cost = 1 + k,        results = k   (parent plans, k leaves execute)
b-ary tree:    cost = (b^(L+1)-1)/(b-1), results = b^L

constraint:    cost <= A
guardrail:     d <= min(depth_cap, A / 4)   # no single chain eats more than a quarter

That last line is the decision rule most teams miss. The maximum depth that fits is not the interesting number. The interesting number is the maximum depth you should allow, which is smaller, because a chain that consumes the whole allocatable pool turns one bad step into a total loss.

Take B = 100 calls. Reserve 20 for retries and verification. Allocatable pool A = 80.

Strategy 1, depth-heavy. A single research chain of depth 8, with each level asking one question and handing its notes up. Cost: 8 calls. It produces 1 leaf result. You could run ten such chains (80 calls) and get 10 results, or run one chain with retries and spend 8 calls plus up to 72 on re-running failed steps. The problem is that if step 5 of a chain fails, everything above it is wasted, and the retry has to resume from step 5 with a fresh briefing, not the original context.

Strategy 2, breadth-heavy. A parent that plans once, then dispatches 8 workers, each of which can itself spawn up to 9 children before returning. Cost: 1 parent + 8 workers + 71 grandchildren is impossible under an 80-call pool, so the honest arithmetic is 1 + 8 + 71 = 80, which yields 71 leaf results at the deepest tier. Compare that with the depth strategy's 10 results. Breadth wins by more than 7 to 1 whenever the subtasks are independent.

The 7-to-1 gap is the insight the first search result will not hand you. But read the last two rows before you go build a fan-out: the failure blast radius and the context cost pull in opposite directions from raw throughput.

Ask one question first: does step n+1 need the output of step n?

If no, the work is a list, and you should spend almost everything on breadth. The guidance in a comparison of subagent patterns is blunt about this: five steps that depend on each other belong in a single subagent with a raised turn limit, not in five nested calls, and nesting earns its keep mainly when the work is recursive in shape, per an analysis of nested subagent economics. A list wants width.

If yes, the work is a pipeline, and you spend on depth, but with two caps. Cap chain length at a quarter of the allocatable pool so no single failure is fatal. Cap the summary size each level returns, because returns add back to the parent's context window and running many subagents that each return detailed results re-floods the context you were trying to protect, as a distribution-versus-escalation guide notes.

A useful stop rule before you nest at all: write the summary you expect the leaf to return. If it is tiny, or the parent could have produced it with two tool calls, do not delegate, because you are paying a full subagent system prompt for very little.

There is a third shape worth naming, because it confuses people budgeting by depth. Some work is really a tree, not a list or a pipeline: exploring a monorepo where each package needs its own scoped sweep, or a review that needs security, performance and style specialists asked the same question. Trees pay for themselves because the leaf summaries roll up. But tree cost grows geometrically, so compute the call count before you run it, not after. The 48-agent incident is what happens when nobody does that arithmetic.

The 20 percent reserve is not lost capacity. It funds three things a plan without slack cannot do.

Verification passes. A verifier subagent that reads a leaf's output and checks it against the original brief costs one call per checked leaf. On a 71-leaf fan-out, checking every leaf would cost 71 calls, which is why you check a sample or check only the leaves with the riskiest claims. Budget the check before the run, or you will skip it under pressure.

Retries. A failed leaf is cheap to retry, one call. A failed chain step is expensive: the retry needs a re-briefing that reconstructs whatever the broken step was supposed to produce. This asymmetry is another reason to prefer breadth when the work allows it.

Human approval gates. If a leaf's output triggers a side effect, the approval is part of the control envelope, not a side conversation, and it should link to the same trace ID as the action it authorizes, per guidance on agent audit trails. Gates cost a call and some wall-clock time, and they belong in the plan rather than in an emergency.

A budget you cannot see being spent is not a budget. Distributed tracing is the mechanism: the W3C Trace Context specification defines the standard headers and value format for propagating context between services, which is what lets a downstream span attach to an upstream trace instead of starting a new one, as the specification sets out. OpenTelemetry builds on it, and its default propagator uses exactly those headers, per its context propagation documentation.

Agent delegation tends to break this. When an agent framework runs its tool loops internally, you see one top-level span for the whole agent execution and nothing about what happened inside, and the practical result is that one logical operation produces three to ten orphaned root spans with no way to join them, as an analysis of tracing across agent service boundaries documents. A delegation budget is only enforceable if each spawn shows up as a span with a parent, so that you can count calls per subtree in real time.

There is no finalized standard for this yet. A proposal for distributed tracing semantic conventions for A2A describes the failure directly: when one agent delegates to another, the trace breaks, because the SDK has no standard way to propagate the context and each delegation starts a fresh, disconnected trace. Until conventions settle, the practical advice is to propagate the trace context yourself through whatever carrier your delegation prompt uses, and to tag each spawn with the parent agent identity. The plumbing already exists in some harnesses: Claude Code added agent identity and parent identity headers to API requests, plus matching OpenTelemetry span attributes, before nested spawning was turned on, per the nested subagent guide.

Once spawns are traced, the budget is a query. Count spans by subtree, compare against the reserve, and stop spawning when the pool runs dry.

The hardest part of the split is not arithmetic. It is judgment about whether your subtasks are genuinely independent, how much a failed chain step would cost you, and which leaves deserve a verification pass. Those are architecture decisions, and they benefit from someone who has run the pattern before. A consulting engagement with Quanta Intelligence can pair you with an expert who reads your actual workflow and helps you size the split before you ship it.

If you are still choosing models for the leaves and the parent, worth remembering that orchestration and model choice both drive cost independent of call count; Quanta Inference gives you text, image, video, audio and embedding models through one OpenAI-compatible API key, which keeps the per-call accounting in one place when you are comparing allocation strategies.