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
takesmaxCostUsd
— 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.