Unbounded Agent Spawning Is a Fork Bomb With Good Intentions
Multi-agent LLM orchestration without spawn limits behaves like a fork bomb. Depth, breadth, cost, and privilege bounds fix it — here's how.
The multi-agent orchestration pattern is genuinely powerful: hand an agent a big task and let it spawn sub-agents to research, implement in parallel, and review. But if a spawned agent can itself spawn agents, with no limit on how far that recursion goes, you've built the classic Unix fork bomb — just with a language model in the loop and an API bill instead of a crashed process table.
The underlying issue isn't multi-agent orchestration itself; it's ungoverned spawning. Anthropic's own guidance flags that isolated sub-agents can each burn thousands of tokens for a short summary — fine once, ruinous when a confused parent spawns a dozen children who each spawn a dozen more. The fix isn't banning spawning; it's treating it as a metered privilege rather than a default capability.
The proposed model rests on four bounds: role-gating so most agents are leaves with the spawn tools physically stripped out; a depth cap that can only shrink as it's inherited down the tree, never grow; a breadth cap on concurrent children per parent plus a hard dollar ceiling on total spend; and a privilege lattice ensuring a child can never end up more powerful than its parent. Together these bounds turn an open-ended worst case into a number you can calculate in advance from the config alone.
Grounded in a real implementation (agentproto), the approach echoes the OWASP Agentic Top 10 principle of least agency: give an agent only the autonomy its specific task requires, and make the rest structurally unavailable rather than merely discouraged.