Agents Managing Agents

Vibe-God · 6 min read

Eventually a planning agent spawns workers that spawn workers: a research lead fanning out to area specialists, each fanning out to readers. Agents managing agents is orchestration (lesson 22) gone recursive — and the honest first statement is that recursion adds less novelty than it seems: the topology is lesson 22 at each level, the lanes are lesson 13, the hazards are lesson 19, the briefs are lesson 11. What is genuinely new is one unsettling fact: nobody chose the tree. You wrote one prompt; the structure — how many agents, how deep, doing what — was decided by models, at runtime, out of sight. Two controls make that acceptable, and they are the whole lesson. Everything else is inherited machinery you already know how to build.

Control one: a shared budget, spent before use

The instinct is per-agent limits: cap each agent at N tokens, cap each at K children. Run the arithmetic on a tree and the instinct collapses: limits compose multiplicatively. K children per node across three levels is K³ leaf agents — modest per-node caps, every single agent inside its individual limit, and the total spend bounded by nothing you ever looked at or approved. A per-agent ceiling is not a budget. It's a per-agent ceiling. The tree's shape — which no one chose — is what actually sets the spend, and it was decided at runtime by the enthusiasm of intermediate planners.

The control that works is a single pool for the whole tree: one number, decremented as any agent anywhere in the tree spends, checked before each unit of work rather than reconciled after (lesson 5's refuse-up-front shape, shared across the fleet). Pool empty, tree stops — mid-plan if that's where it lands. Attach two companions:

  • A depth limit. A plain number: no delegation below level three. Less about cost than about meaning: a level-5 worker executes a brief five lossy translations removed from anything you said — a game of telephone where every player also improvises. Wide-and-shallow trees keep every worker's brief traceable to your intent; deep trees dissolve accountability layer by layer. (If a task seems to need depth five, that's usually lesson 22's signal that the decomposition is wrong, not that the limit is.)
  • A spend ledger. Every draw on the pool tagged: which agent, how much, for what. When a tree overspends — one will — the question is never "how much?" (the pool answered that) but "on what?", and a total cannot answer it. The ledger is also your routing feedback (lesson 10): it shows which subtrees deserved the strong model and which burned it on flat work.

Control two: a kill switch that stays killed

Runaways happen: a worker loops, a planner re-plans forever, a subtree starts returning garbage that a parent dutifully synthesizes. Stopping a tree is harder than stopping a process — children of a halted parent keep running unless something tells them otherwise. So the switch is a shared flag every agent checks before each unit of work — before, so a tripped switch means no further spend anywhere, not "everyone finishes their current expensive thing first." Three properties, each purchased by an incident somewhere:

  1. Anything may trip it. The monitor, a worker detecting nonsense in its own inputs, you. False trips are cheap — you restart. A missed trip isn't.
  2. Nothing untrips it but a human. Lesson 17's halt-and-stay-halted, with the same logic: a system that can clear its own kill switch will, eventually, at the worst possible time. The tripped tree is a good state — visible, stationary, inspectable.
  3. The first reason is preserved. When one trip cascades into five (children failing because the parent stopped), later reasons must not overwrite the original. That first reason is the entire post-mortem; everything after it is echo.
you: one promptplannerplannerworkers…workers…workers…workers…K children per node,3 levels = K³ agents —nobody chose this shapecontrol 1 — one shared budget pool for the whole tree, spent before usecontrol 2 — a kill switch any agent can trip, that only a human can clear
Per-agent limits compose multiplicatively - modest caps at every node and an unbounded total, because the tree's runtime-decided shape is what actually sets the spend. The pool makes the total a number you chose; the switch makes the whole tree stoppable from anywhere and restartable only by you. Everything else is lesson 22, applied at each level.

The posture: manage the worst case, judge the fruit

Supervision here is not choreography. You cannot review what every third-level worker does — that inability is the point of the tree — so you bound what the tree can do rather than watch what it does do: pool, depth, ledger, switch, plus the perimeter you already own, because hooks and containment (lessons 15, 13) apply to every agent at every level — the environment doesn't care who spawned the process, which is exactly what makes environmental enforcement the right kind (lesson 26's indifference principle, again).

Then judge the tree by its fruit: evaluate the final output (lesson 21), gate its consequences (lesson 28), and resist helicoptering the middle layers. The diagnostic that closes the loop: if a tree needs constant mid-level correction, the fix is never more supervision. It's a better brief (lesson 11), a shallower tree, or the honest admission that this job wanted lesson 22's single orchestrator — or lesson 6's single attended session — all along. Recursion is a capability multiplier, and it multiplies whatever you hand it: good briefs and hard boundaries, or vagueness and hope. Hand it the former, and the fleet is the closest thing this course has to magic. Hand it the latter, and the ledger will show you exactly where the hope went.

A personal teaching project, in development. The registry it builds is a teaching artifact and is not an assurance opinion about any issuer. Not affiliated with or endorsed by any employer, or by any vendor whose tools it describes. Where a unit depends on a specific flag or path, it names the version it was verified against. All units.