Teams

Two agents worked in the last chapter - a builder and a verifier who didn’t trust it. That’s enough for a job that splits into “do it” and “check it.” It is not enough for what’s sitting in front of you now: 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 (or ten) 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. What this migration actually wants is a chain of command: someone who owns each domain end to end, and doesn’t do the typing themselves.

This chapter builds that chain, then asks the question every chapter before it has quietly deferred: is any of this worth the tokens it costs?

• Orchestration - add the missing layer between you and the workers: leads, one per domain, who are structurally forbidden from touching a file themselves. And 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 starting from zero every spawn.
• Coms - let two leads talk to each other directly when the hierarchy gets in the way, and the honest test for whether that channel is worth building at all.

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