TL;DR
The power to call other agents is also the risk: without limits, delegation can spiral into uncontrolled recursion — agents delegating in circles, burning calls with no answer. Three limits keep it bounded: a depth cap (the most important), a cost budget, and a timeout. With them, the worst case is a graceful fallback, not a runaway bill.
When delegation runs away
Delegation gives agents the power to call other agents. That same power is the risk: without limits, an agent-to-agent system can spiral. A router delegates to a specialist, which delegates to another, which delegates back — and now you're burning calls and money on a loop that may never produce an answer. Three limits keep it bounded.
Depth limits — the most important
A depth limit caps how many levels of delegation are allowed. The router is depth
0; each hand-off adds 1. At the cap, a sub-agent simply can't delegate further — its
delegate_* tools aren't even offered to it.
Your lab sets maxDepth. With maxDepth: 2, the router can delegate to a specialist
(depth 1) and that specialist can delegate once more (depth 2), but no deeper. It's the
single most important guard against runaway delegation, and it fails gracefully — the
deepest agent just answers directly instead of handing off.
Cost limits
Every agent run costs tokens. A cost limit caps the total spend for a single request across all its delegations, so one expensive question can't quietly run up a huge bill. When the budget is hit, the system stops delegating and returns what it has.
Timeouts
A timeout caps wall-clock time. Delegation adds round-trips, and a slow (or stuck) specialist shouldn't hang the whole request forever. A timeout cuts it off and lets the parent fall back.
| Limit | Caps | Without it |
|---|---|---|
Depth (maxDepth) | Levels of delegation | Infinite recursion — agents in circles |
| Cost | Total tokens/spend per request | One question quietly runs up a huge bill |
| Timeout | Wall-clock time | A stuck specialist hangs the whole request |
The failure mode to fear
Of all the things that can go wrong with agent-to-agent systems, the one to respect most is uncontrolled recursion — agents delegating in circles, multiplying cost and latency with no answer at the end. It's the agent version of an infinite loop, except each iteration costs a real model call. That's the checkpoint: the failure mode is runaway recursion, and the depth limit is the single best guard — it makes infinite delegation structurally impossible, while cost and timeout are the backstops that bound the damage of anything the depth cap doesn't catch.
Analogy
Delegation without a depth limit is a manager who, when busy, hires another manager to handle the work — who hires another. The depth cap is a rule: "you may delegate at most twice, then you handle it yourself." Cost and timeout are the company budget and the end-of-day deadline — the backstops that stop runaway delegation even if the org chart somehow loops.
Common mistake
Treating depth, cost, and timeout limits as optional polish to add later. They're not features — they're the safety rails that make delegation production-safe at all. A multi-agent system shipped without a depth cap isn't "mostly fine"; it's one mis-classification away from an infinite loop on a real bill. Set the limits first, then build the delegation.
Key takeaways
Key takeaways
- The danger of agent-to-agent systems is uncontrolled recursion — an infinite loop that costs money.
- Depth limit (
maxDepth) is the most important guard; it fails gracefully to a direct answer. - Cost and timeout limits are the backstops that bound spend and wall-clock time.
- Set the limits before you build the delegation — they're rails, not polish.
You've built a production-shaped agent
You've now built an agent that learns, uses tools, grounds answers in your docs, connects to real services via MCP, is observable through traces, is measured by evals, is guarded against unsafe input and output, and delegates to specialists within safe limits. That's a production-shaped agent — end to end.
Go deeper: least privilege and the trust boundary between agents
Limits stop runaway delegation; a second discipline stops misused delegation — especially as agents call agents built by other teams (the A2A future from the last lesson):
- Least privilege per agent. A specialist should hold only the tools its job needs. The billing agent can issue refunds; the technical agent can't. If a sub-agent is compromised or tricked (prompt injection, Module 8), least privilege bounds the blast radius to what that agent could already do.
- Guardrails at the boundary. A sub-agent's output is another agent's input — so the input guardrails from Module 8 apply between agents, not just at the user edge. A parent shouldn't blindly trust a child's output any more than a user's.
- Don't let delegation launder authority. If a user isn't allowed to do something directly, delegating through three agents shouldn't grant it. Authority checks belong at the action, not at the entry point.
The unifying idea: every agent boundary is a trust boundary. The limits in this lesson keep delegation bounded; least privilege and boundary guardrails keep it safe. Both are what turn a clever multi-agent demo into something you can actually ship.