An Agent That Can Spawn Agents Is a Fork Bomb With Good Intentions

A developer warns that giving AI agents the ability to spawn sub-agents without limits creates a recursive fork bomb pattern, leading to runaway costs and resource exhaustion. The post, written by the creator of agentproto, argues that spawning must be a metered privilege with depth and breadth caps, not an unbounded capability. The fix is privilege-gated spawning where child agents cannot exceed their parent's permissions.

Disclosure up front: I build agentproto , one of the tools in this market. The primitives in the back half are real and the fields are checkable; the problem in the front half is everyone's. Corrections welcome — file an issue. Here's the multi-agent dream, and it's a good one: you hand one capable agent a big task, and instead of grinding through it alone, it spins up a little team — one sub-agent to research, two to implement in parallel, one to review — waits for them all, and hands you the merged result. An orchestrator that manages orchestrators. It works, and it's genuinely powerful. Now read that sentence again with an engineer's paranoia. An orchestrator that manages orchestrators. If an agent can spawn agents, then the agents it spawns You already know this shape. It's the oldest prank in the Unix book: : { :|:& };: a function that calls two copies of itself, forever That's a fork bomb. It does nothing malicious — each copy just politely starts two more, until the process table is full and the machine is on its knees. A coding agent with an unbounded spawn tool is the same structure with a language model in the middle and your API bill underneath. The one idea, if you remember nothing else: Spawning isn't a feature you turn on. It's a privilege you grant — and a privilege with no depth, no breadth, and no ceiling is a fork bomb with good intentions. When you give an agent a spawn sub agent tool, you're not just adding a capability. You're granting it the right to grant itself the same capability, recursively, as many times as its reasoning talks it into. Most setups make that grant implicitly and totally: if the tool is in the toolset, spawning is unlimited — any depth, any number of children, and each child just as privileged as the parent. Two things make that expensive fast, and neither is hypothetical. First, cost. Anthropic's own guidance on sub-agents is that you isolate exploration in them precisely because each one can burn ten thousand tokens to hand back a five-line summary — cheap when it's one, a bonfire when a confused parent The receipt that should slow you down.The sharpest orchestration writers converge on one rule:the number of agents a job spawns is the output of the orchestration decision, not the input. You don't pick a multi-agent workflow because you can — you pick it because the work's shape demands it. An agent that spawns because spawning is available has skipped the only decision that mattered. So the problem isn't multi-agent orchestration. It's ungoverned spawning — handing an LLM a recursive, self-replicating capability and trusting its judgment to not run it off a cliff. The fix isn't "don't spawn." It's "make spawning a metered privilege." Place yourself honestly before you build. Four postures, each with a ceiling. Unbounded. Any agent holding the spawn tool spawns freely — any depth, any count. Powerful, and one confused reasoning loop from a runaway tree and a bill with a comma you didn't expect. Ceiling: the first agent that decides the answer to "this is hard" is "spawn more agents." Concurrency-capped by hand. You cap how many agents run at once, in your own harness code, watching a dashboard. Better — but it's your attention doing the capping, and it doesn't stop depth , just width at one instant. Ceiling: you, watching. Worktree-isolated only. You give each parallel agent its own git worktree so they don't stomp each other's files — the near-universal isolation trick, and a good one. But a worktree isolates the filesystem , not the right to spawn . A tidily-isolated agent can still fork-bomb. Ceiling: clean files, unbounded tree. Privilege-gated. Spawning is a role, capped by depth and breadth, and a child can never grant itself more than the parent had. This is the one that can't run away, and it's the one you can declare instead of police. Where are you?If your honest answer is"any agent with the tool can spawnyou don't have orchestration — you have a fork bomb that as much as it wants," hasn't gone off yet. The rest of this is four bounds that make sure it never does. The first bound is the bluntest: most agents in a tree should be leaves that physically cannot delegate. In agentproto that's a spawn-time role. // this child does the work and CANNOT spawn — the spawn tools are removed agent start { adapter: "claude-code", role: "executor", // leaf: agent start / agent prompt are stripped cwd: "/abs/host/path", prompt: "Implement the retry cap in src/payments/retry.ts. Do not delegate." } An executor is a leaf by construction: the agent start and agent prompt tools are stripped from its toolset , and asking it to become an orchestrator is simply ignored — no amount of clever prompting gives it back the ability to spawn, because the capability isn't in the room. A supervisor may delegate. That single distinction turns "every agent is a potential parent" into "spawning is a named privilege that most of the tree doesn't hold." This is the same lesson the OWASP Agentic Top 10 files under least agency : give an agent only the autonomy its task needs. A worker implementing a function doesn't need the right to raise an army. Take it away, and a whole class of runaway trees becomes unrepresentable. Leaves can't spawn, but supervisors can, and a chain of supervisors is still a recursion. So the second bound caps how deep the tree can go, and makes the cap one-directional. agent start { role: "supervisor", orchestrator: { maxDepth: 3, maxChildren: 8 }, // this subtree, bounded // … } maxDepth defaults to 3 and has a hard ceiling of 8 — a spawn that would exceed it is rejected outright, not queued. The load-bearing detail is the direction: a recursive spawn can only lower the inherited cap, never raise it. A parent at depth 3 can hand a child a budget of 2; that child cannot hand Depth stops the tree going infinitely down ; breadth stops any one node exploding sideways . maxChildren defaults to 8 concurrently-alive sub-agents per parent and, like depth, a recursive spawn can only lower the inherited quota — never raise it. That's the direct antidote to the :|: in the fork bomb — the part where one process becomes two becomes four. Cap the branching factor and the geometric explosion can't start. Combined with depth, your worst case is now a known number of agents maxChildren ^ maxDepth , and shrinking as it descends , not an open-ended one. You can look at a spawn config and say exactly how bad a confused run gets. That sentence is impossible in the unbounded world. Cost gets its own hard stop.Independently of the tree shape, each session takes maxCostUsd — a cumulative dollar ceiling; the session is stopped at the next turn-end once it's exceeded. Depth and breadth bound thecount; this bounds thespenddirectly, so even a legal-sized tree of expensive turns has a number it can't cross. The last bound is the subtle one, and it's what makes the other three trustworthy: a child can never end up more powerful than the parent that made it. The daemon enforces a privilege lattice — a spawn made through an orchestrator may only create a role at or below the caller's own level, never something more privileged, and an explicit tools allowlist can only ever narrow the toolset, never widen it. A child can never grant itself scope its parent didn't have. And the parent's view is boxed, too. The daemon mints a per-child scope-token , injects a scoped sub-gateway into that child's session, and revokes the token when the session exits . A parent's session tree shows only Four bounds, one property: you can hand an agent the genuinely powerful ability to build and run a team, and still be able to state — before it runs — the maximum depth, the maximum breadth, the maximum spend, and the ceiling on privilege. The capability stays; the fork bomb becomes unrepresentable. Real infrastructure, real sharp corners. Four I hit live: turn-end is a transient event, so the wait times out on a child that already succeeded. Teach the parent the fallback: if the wait times out, read the child's output to confirm, or take an event cursor session tree , or you'll leak running agents. cwd must be a real host pathAnd the fair comparison. Vendors do ship sub-agents — Claude Code's Agent Teams will run a team for you, and inside one vendor's stack it's smooth and needs none of this wiring. Two things a built-in team doesn't give you: the spawn tree stays inside that vendor your cheap open-model executors aren't invited , and the governance is theirs, not a set of depth/breadth/role/cost bounds you declare and own. If you live entirely in one vendor and never want a mixed fleet, take the built-in — it's less work. If you want to spawn across vendors and sleep at night, the bounds have to be yours. The instinct to stop agents from spawning is the wrong lesson — spawning a team is exactly the leverage that makes agents worth orchestrating. The right lesson is that a self-replicating capability handed to a probabilistic reasoner needs the same thing every other powerful capability needs: limits it can't rewrite. So grant the privilege deliberately. Make most agents leaves that can't delegate. Cap the depth so the recursion has a floor. Cap the breadth so no node fans into a swarm. Cap the spend and the privilege so a child is always smaller than its parent. Do that and "an agent that spawns agents" stops being a fork bomb and starts being what you actually wanted: a team with a foreman, and a foreman who can't accidentally hire the whole city. Let the agent build its team. Just make sure the tree has a floor, the branches have a limit, and the whole thing dies when the job's done. If your orchestrator bounds spawning a cleaner way — or you've found a runaway tree these four bounds wouldn't have caught — tell me where. I'll fix the piece. Written by the maintainer of agentproto Apache-2.0, source — a local, cross-vendor daemon for running and governing coding agents. Same contract as our /compare page: dated facts, named strengths, corrections by issue. Got something wrong? File an issue. Building agentproto in the open — follow @theagentproto and @agentik ai on X.