TL;DR
A mega-agent that does everything has a swollen prompt, every tool bound at once, and tangled traces. Delegation splits it into a router plus focused specialists: the router classifies a request and hands off; each specialist has its own prompt, tools, and context. Split when concerns are genuinely distinct — stay flat when they're not.
The mega-agent problem
Your agent has grown. It answers billing questions, debugs technical issues, looks up accounts, searches docs, and applies guardrails. To do all that, its system prompt has swollen into a wall of instructions, it carries every tool for every job, and a single trace mixes billing logic with technical logic. That's a mega-agent, and it has three quiet costs:
- Diluted focus. One prompt trying to be an expert at everything is an expert at nothing — instructions for one job distract the model on another.
- Tangled traces. When something breaks, you read one long trace where every concern is interleaved. Which step was the billing part?
- All tools, all the time. Technical questions never need
lookup_account, but it's bound anyway — more for the model to weigh on every turn.
Delegation: a router plus specialists
The fix is delegation: split the one agent into a router plus focused specialists. The router is itself an agent — it doesn't answer directly; it reads the request, decides which specialist fits, and hands off. Each specialist is a complete agent with its own prompt, its own tools, and its own context.
| Mega-agent | Router + specialists | |
|---|---|---|
| System prompt | One giant wall of rules | Small router prompt; focused specialist prompts |
| Tools | Every tool, every turn | Each specialist carries only its own |
| Trace | One interleaved log | A tree: router → the specialist it picked → its steps |
| Focus | Expert at nothing | Each specialist expert at one thing |
The router's prompt stays small ("classify and delegate"); each specialist's prompt stays focused; and the trace becomes a tree you can actually read.
Analogy
A mega-agent is a single employee who is reception, billing, and IT support all at once — competent at none, and you can never tell which hat they had on when something went wrong. Delegation is a receptionist (router) who listens and forwards you to the right specialist. Each person does one job well, and the hand-off is on the record.
When NOT to split
Delegation is powerful, but it isn't free — every hand-off is another agent run, which means more latency, more cost, and more moving parts. That's the checkpoint: splitting is the wrong call when:
- The job is simple. A single-purpose agent with a clear prompt and a couple of tools doesn't need a router. You'd add complexity for nothing.
- The specialists would overlap heavily. If two "specialists" share most of their prompt and tools, they're really one agent — splitting just duplicates.
- Latency is critical. Each delegation hop adds a round-trip. If the request must be answered in one fast call, a flat agent wins.
Split when the concerns are genuinely distinct and each is substantial enough to earn its own focus. Otherwise, keep it flat.
Common mistake
Splitting because it feels more "architected." Sub-agents are a tool for managing genuine complexity, not a default. A router in front of one trivial specialist is pure overhead — extra latency, extra cost, extra failure modes, zero benefit. The best architecture is the simplest one that does the job.
Key takeaways
Key takeaways
- A mega-agent suffers diluted focus, tangled traces, and all-tools-all-the-time.
- Delegation = a router that classifies and hands off to focused specialists.
- Each specialist has its own prompt, tools, and context; the trace becomes a tree.
- Split for genuinely distinct, substantial concerns — stay flat for simple or overlapping ones.
Go deeper: sub-agents as context isolation
The deepest reason delegation helps isn't tidiness — it's context isolation, which ties back to what you've learned about tokens and keeping a prompt focused:
- Each specialist sees only its own context. The billing specialist's prompt, tools, and retrieved docs are all billing-specific. It never has to wade through technical instructions, so it can focus entirely on the job at hand.
- Smaller prompts, lower cost. A focused specialist sends fewer tokens per call than a mega-prompt would (Module 6's cost lesson) — even across several agents, the total can be less than one bloated agent re-sending everything every turn.
- Independent evolution. You can improve the billing specialist's prompt, swap its model, or add a tool without touching the technical one — and re-run its slice of the eval suite in isolation.
Seen this way, a sub-agent is a unit of focused context with a clean interface. The next lesson is about the shapes those hand-offs can take.