Teams

Two agents worked in the last chapter - a builder and a verifier who didn’t trust it - and you closed that chapter on a question nobody answered: who verifies the verifier? Not a third agent. The last chapter’s real answer was structural - a verifier that can’t chat back can only fix itself through a rule file you edit by hand, so the regress stops at you, not at another watcher. That structural move - remove the temptation instead of policing it - is the one this chapter runs again, at a bigger scale.

stash’s readability extractor mangles too many sites, and you’ve decided to replace it outright with a new extraction engine. That’s not one fix. It’s at least three, wearing one migration’s name - the extractor itself needs new logic, every already-saved row needs its content re-extracted and the full-text index rebuilt against the new shape, and the tiny web UI and CLI need to handle whatever that new shape turns out to be.

Fan that out flat, the way the last chapter taught you, and you get three domains’ worth of workers all reporting to the same thread - yours. You become the bottleneck the whole point of subagents was supposed to remove: reading every domain’s back-and-forth yourself, because nothing stands between you and the workers. More agents on the job doesn’t mean less work for you. Past a certain point it means more windows to watch and more coordination to do by hand, and that coordination cost is the real villain of this chapter, not the migration itself.

Here’s the claim this chapter is going to earn, not just assert: a lead per domain turns however many workers are underneath it into one report you actually read, and that ratio gets better the bigger the team gets - but the tokens spent don’t shrink, they move, and every layer you add back (a lead, an expertise file, a peer channel between leads) has to pay for itself against what it costs to build and run. Some of what you’re about to build will clear that bar easily. At least one piece of it, run at the wrong size, won’t - and this chapter says so when the trace shows it, instead of only celebrating the wins.

• Orchestration - add the missing layer between you and the workers: leads, one per domain, structurally forbidden from touching a file themselves. Count what that actually buys you, then the real reason to decompose the migration at all - it was never about context size.
• Expertise - give each lead a place to keep what it’s learned about its own lane, so the extraction lead gets better at extraction over the migration instead of re-discovering the same dead end every spawn.
• Coms - let two leads talk to each other directly when the hierarchy gets in the way, and run the honest test for whether that channel - or any of this - was worth building at all.

By the end you’ll have run a real three-tier team on a real migration, added every layer’s cost and payoff to the running ledger, and be able to say, without hand-waving, whether it was the right tool for the job. Start with orchestration.