Sub-Agents

A sub-agent is a second model context, spawned by the first, handed one task, and returning its conclusion rather than its working. Line C is delegation topology and this is its second rung. The move itself is ordinary: when a job does not fit in one window, split it. What the term adds is a number for what the split costs, because it is usually reached for in the belief that it is free or that it is faster, and it is neither.

The mechanism

Two plans over the same work. planMonolith puts the preamble and every task in one context. planPerTask gives each task its own context containing the preamble plus that one task.

The arithmetic is not subtle once you write it down. Per-task pays the preamble once per worker. With a 490-token classification prompt and thirty short issuer records, that repetition is not a rounding error, it is the entire bill.

Build it

Measured over the real thirty-item universe at three window sizes:

window 100000  monolith 1507 total, fits 30/30
               per-task 16297 total, peak 553, 30 workers
               premium +14790 tokens (+981%), preamble paid 30x
               -> monolith

window    700  monolith 1507 total, OVER
               per-task 16297 total, peak 553, 30 workers
               capacity: monolith holds 5/30
               -> per-task

Run the same demo against a different domain and the premium is +1029% instead of +981%. That near-agreement is the actual lesson: the premium is 29P/(P+30r), a ratio between the preamble and one item, and it has nothing to do with what the items are. Swapping the corpus moves it by five per cent. Making the preamble smaller, or the items bigger, moves it by an order of magnitude.

Ten times the tokens. Fanning out is not an optimisation and it is not a speedup you get for free; it is a capacity purchase. What it buys is a per-worker context that does not grow with the size of the job, so the run does not stop working when the twenty-eighth issuer is added.

compare() reports which of the two decisions it is making, in words, in the artifact. Anyone who reaches for sub-agents to go faster on a job that already fits is paying a 981% premium for nothing, and the recommendation string says so rather than leaving them to infer it from two totals.

The receipt

artifacts/11-subagents.json, with all three windows, the premium in tokens and percent, the monolith's capacity in tasks, and the recommendation.

Note what the peak column shows: per-task peaks at 553 tokens regardless of how many items exist. That flat line is the whole product. The monolith's 1507 grows with every issuer added and eventually crosses whatever window you have.

Where it overlaps

Line C is delegation topology and this is its first rung; term 22 turns the same move into a pattern with a merge step, and term 29 gives it a longer leash and worse observability. Line A is context economics, and this unit is where the economics stop being about one request and start being about a fleet of them. Line H is isolation: each worker's context is isolated by construction, which is the cheap version of what term 13 does to the filesystem with worktrees.

The premium measured here is also the setup for interstitial I. All 14790 extra tokens are repeated preamble, which is exactly what term 12 makes nearly free and exactly what term 20 wants to shrink. Those two pull in opposite directions on the same 490 tokens, and this artifact is the number they argue over.

Why this is built before it is taught

Taught at 11, built at 6. Sub-agents are a context-budget decision before they are an orchestration decision, so the work belongs immediately after term 2 where the budget is established, rather than after the tier boundary where the tier list happens to put it. The teach order is the meme's and does not move; the build order is the one the repository follows.