Depth and Spend Limits for Delegating Agents

Depth is the number of levels where a subagent is allowed to call another subagent. Level 1 is the orchestrator, level 2 is a direct subagent, level 3 is a subagent of a subagent, and so on.

Pick depth from the task shape, not from a feeling that more agents must be better. Azure's architecture guidance on orchestration patterns says to use the lowest level of complexity that reliably meets your requirements, because each level adds coordination overhead, latency and cost Azure Architecture Center on agent patterns. In practice that means:

The reason to keep the default at two or three levels is that deeper recursion is rarely what produces the gain. Anthropic's improvement came from breadth (parallel subagents exploring independent threads with fresh context), not from depth, and the same write-up notes that most coding tasks have fewer truly parallelizable subtasks than research Anthropic's multi-agent research system. LangChain's comparison of multi-agent architectures makes a related point: the subagent pattern keeps centralized control by having the supervisor call subagents as tools, with one extra model call per interaction, and that overhead is the price of context isolation LangChain on multi-agent architecture. Every extra level pays that overhead again.

A decision rule that works in practice: allow depth 3 by default, and require a measured quality improvement before allowing 4. If a task needs to be split twice before the leaf work is small enough, that usually signals that the task prompt or the context handoff is wrong, not that you need another layer.

Width is the number of agents alive at once across the whole tree. Pick it from the natural width of the work: one subagent per file, per source, per module, per document, or per candidate hypothesis.

A useful data point for sizing: Anthropic's research system spawns roughly 3 to 5 specialized subagents in parallel for a lead agent's plan in the analysis of that system The AI Engineer on Anthropic's research system. That is a deliberate small number chosen for research queries, where each subagent owns an independent thread. If your cap is set from the work instead (say 12 files, 12 subagents), you get a cap that scales with the input, which is what you want for variable-size tasks.

Two operational constraints should also feed into the number:

• Concurrency limits. Beam AI's failure analysis of fan-out patterns notes that fifteen concurrent agents issuing requests can exceed an API rate limit even when each agent is well within its individual limit Beam AI on orchestration patterns. Set the count cap at or below what your provider and your own infrastructure will absorb in parallel.
• Coordination conflict. The same analysis points out that shared-state conflicts scale quadratically with the number of agents, so five agents have 10 possible pairwise interactions and ten agents have 45 Beam AI on orchestration patterns. If your subagents write to shared state, keep the cap low.

A working recipe: set the count cap to the number of independent units of work, then round down to your safe concurrency limit. For a 40-file review, cap at 8 subagents and run them in waves of 8 rather than 40 at once.

The spend cap is the total tokens across the whole run: orchestrator plus every subagent plus synthesis. Set it from what you can absorb per request, and work backwards from the value of the task.

Anthropic's economics section says this directly: multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance, given roughly 15x the tokens of a chat Anthropic's multi-agent research system. That gives you a simple decision rule.

Worked example. Suppose your acceptable cost per delegated run is 40 times the cost of a single chat turn on the same model, because the task (a competitive analysis that a person would otherwise spend half a day on) is worth far more than that. If a chat turn on your routing model is roughly T tokens, your run cap is about 40T. Split it like this:

• Orchestrator planning and synthesis: 25 percent of the cap.
• Subagent work: 60 percent of the cap, divided by the number of subagents you expect.
• Reserve for retries: 15 percent, held back so a single failed branch does not consume the whole budget.

The per-subagent allowance then becomes a check on your count cap: if 60 percent of 40T divided by 12 subagents is less than a reasonable single-subagent task needs, either the count is too high or the run cap is too low. That arithmetic catches mis-sized budgets before production does.

Two notes on where the numbers come from. Token usage was found to explain most of the performance variance in Anthropic's analysis, with tool call count and model choice as the other factors Anthropic's multi-agent research system, so a budget that is too small does not just save money, it degrades quality. And because multi-agent systems burn tokens quickly, the same analysis recommends them only for high-value, heavily parallelizable tasks Anthropic's multi-agent research system.

Enforce limits in the orchestrator, not in the subagent prompt. A prompt instruction is advice; the orchestrator is the only component that sees the whole tree.

The enforceable pattern is reserve, dispatch, decrement, kill:

1. Reserve before dispatch. When the orchestrator decides to spawn a child, it first checks the remaining budget and the current depth. If either would be breached, it does not dispatch. Subtracting at dispatch time means two parallel branches cannot both spend the last of the budget.
2. Decrement on completion. When a child returns, record tokens actually used against the run total, and release any unused reservation. Recording actuals rather than estimates keeps the ledger honest.
3. Kill on breach. If a child exceeds its own allowance mid-run, cancel it and mark the branch as capped. Do not let it finish and reconcile later.
4. Stamp every result with its depth and its lineage. The parent needs to know which branch produced a result and how deep it went, so it can decide whether to retry shallower.

A minimal ledger looks like this in most orchestrators:

@dataclass
class RunBudget:
    max_depth: int = 3
    max_agents: int = 8
    max_tokens: int = 400_000
    tokens_used: int = 0
    agents_spawned: int = 0

def try_spawn(budget, parent_depth, estimate):
    if parent_depth + 1 > budget.max_depth:
        return "capped:depth"
    if budget.agents_spawned + 1 > budget.max_agents:
        return "capped:agents"
    if budget.tokens_used + estimate > budget.max_tokens:
        return "capped:tokens"
    budget.agents_spawned += 1
    budget.tokens_used += estimate       # reserve now, reconcile later
    return None                          # None means dispatch is allowed

The same structural idea appears in Azure's single-agent guidance, which recommends iteration limits to guard against infinite tool-call loops Azure Architecture Center on agent patterns. For multi-agent runs, depth and count are the equivalent guards. Observability matters here too: LangChain's architectural comparison distinguishes centralized orchestration, where all routing passes through the main agent, from peer patterns where workers talk directly LangChain on multi-agent architecture, and centralized control is what makes a single ledger possible.

For teams wiring this across more than one model provider, the reservation logic has to survive calls that return usage in different shapes. Quanta Inference exposes text, image, video, audio and embedding models through one OpenAI-compatible API with prepaid US dollar pricing Quanta Inference, which means one place to record token usage against the ledger.

A cap firing is a normal event, not an error. Handle it with three moves.

Return a partial result that names the cap. The child should hand back what it finished plus a structured marker, for example status: capped, cap: depth, depth_reached: 3. Naming the specific cap lets the parent, and later the person reading the trace, distinguish "we ran out of money" from "we ran out of allowed levels." This is the same graceful-degradation idea that LangChain's article on architecture selection covers when it explains why workers stay stateless and the orchestrator owns state and combination LangChain on multi-agent architecture.

Prune the branch. Do not retry the same capped path with the same settings. Mark the subagent's assigned slice as unresolved and keep the results from the branches that did finish. A fan-out pattern fails on partial results unless you have an explicit merge step, which is why the aggregation call needs to accept partial inputs and say what is missing Beam AI on orchestration patterns.

Let the parent retry shallower or escalate. The parent has two options, and the cap that fired decides which.

Escalation should be a first-class outcome, not a fallback you bolt on. Returning "I completed 9 of 12 sources and stopped at the spend cap" is a useful answer. The mistake is a run that either silently loops past its budget or dies with nothing.

You cannot tune caps you do not measure. Build a small harness that runs a fixed set of representative tasks against your orchestrator with the caps deliberately set low, and record which cap fires first and how often.

Two checks are worth automating:

• Depth distribution. Log the depth at which each subagent ran. If most leaves are at your maximum depth, the cap is shaping the work rather than bounding it, and you should ask whether the task decomposition is wrong.
• Budget burn per unit of output. Track tokens spent per finished subagent against the per-subagent allowance you calculated. A rising trend means context is being duplicated across handoffs, which is the compounding effect described in cost analyses of multi-agent systems Augment Code on cost compounding.

Finally, treat the caps as configuration, not constants. A research run and a code review run have different natural widths and different values per answer, so they should have different budgets. The orchestrator that reads depth, count and spend from a per-task profile will outlive one with the numbers hardcoded.