I have a Claude agent I call the coordinator. Its whole job is to coordinate a fleet of other Claude agents — each one a “domain owner” that lives on its own patch of the system — by passing messages back and forth over tmux (think of it as a set of always-on terminal windows agents can type into) and little text mailboxes.
The coordinator is a manager. It’s not supposed to touch anything. It’s supposed to decide who handles a thing and let them go handle it.
So one afternoon I asked it to figure out why something was flaky across a few hosts. And I watched my manager roll up its sleeves and start doing the work itself. It opened an SSH session, ran journalctl to read logs on one box, grepped for errors on another, probed a third — five or six diagnostic commands, all in its own window, reading every line of raw output back into its own head.
Then it got ambitious and tried to spawn four fresh helper agents to fan out across the hosts in parallel.
Both moves felt productive. Both were the mistake.
Here’s the thing I hadn’t internalized: an agent’s context window — the amount of conversation and text it can hold in mind at once, like the number of open browser tabs before the laptop chokes — is a budget. And the coordinator’s budget is the most expensive one in the whole fleet. Every peer agent can burn its own context reading log spew; that’s what they’re for. But when the coordinator reads a thousand lines of journalctl output, it fills the one head that’s supposed to stay clear enough to see the whole board. It trades the map for a shovel.
Once I saw it that way, the fix wrote itself as a lane rule.
Back-and-forth investigation across hosts — the kind where round two depends on what you learned in round one — goes to a persistent tmux peer, because that peer keeps its state across rounds and remembers what it already checked. A one-off, self-contained question (“is port X open, yes or no”) goes to a stateless subagent, a cold-context helper you spin up, ask once, and throw away. And any tactical probe — the actual SSH-and-grep — lives in the lane of whoever owns that domain, never the coordinator’s.
The coordinator produces synthesis and routing. WHO does this. Never HOW, never the raw output.
The smell test and the three primitives give me the detail
The rule I gave the coordinator is a physical smell test: if you’re about to write a Bash block with 5+ SSH probes or parallel greps, stop — that’s delegation you skipped.
The decision tree it now follows:
Task arrives
│
├─ Iterative? (round N depends on round N-1 findings)
│ → route to a PERSISTENT tmux peer (keeps state across rounds)
│
├─ One-shot, distillable to a single answer?
│ → spawn a STATELESS subagent (cold context, returns synthesis, dies)
│
└─ Tactical probe on a specific host?
→ it belongs to that host's DOMAIN-OWNER peer, not the coordinatorWhy parallel subagents were wrong for the multi-host case: subagents start cold and can’t carry findings between rounds, so a back-and-forth investigation across four of them means the coordinator has to re-synthesize four raw dumps itself — the exact context blowup I was trying to avoid. Persistent peers hold their own thread; you get back a conclusion, not a transcript.
The general principle: in any multi-agent system, the coordinator’s attention is the scarcest resource you have, and it degrades silently — nothing errors out, the manager just gets slower and dumber as its head fills with detail it should never have seen. So treat context-preservation as an architectural constraint, not good manners. Give your top agent one job — decide who — and make “am I about to do labor?” a hard stop, not a judgment call.