The pitch for an agent fleet is seductive and mostly wrong. You picture a swarm that divides the work, talks amongst itself, and clears your backlog while you sleep. What you get on the first try is forty processes editing the same file, three of them undoing each other, and a bill that arrives before any of the results do.
I want to be honest about the boring premise before the clever parts. A fleet is a distributed system that happens to think. Every failure mode you already know from queues and workers shows up again, except the workers are non-deterministic now and occasionally argue with you. If you’ve run services at scale you have most of the instincts already. If you haven’t, the model will teach you the expensive way.
Why not one big agent
The single-agent design fails the way a single overloaded engineer fails. Context. One agent holding the whole problem spends most of its budget re-reading state it already saw, and the output sags as the conversation grows. By its tenth task a long session ships worse work than it did on its first. The model didn’t get dumber. The signal it needs is buried under everything it’s already done.
Splitting the work fixes the economics more than the intelligence, which surprised me. A narrow agent with a sharp brief and a small window is cheaper and easier to reason about than one generalist trying to be everything. You pay for that in coordination. Coordination is a problem you can engineer. Lost context isn’t.
Isolation is the whole game
First week, I let the agents share a working directory.
By Thursday I had a HEAD pointing at a commit no agent remembered making, an index full of half-staged changes from three tasks, and a watcher process that had stashed someone’s uncommitted work mid-edit. Two hours to reconstruct what happened, and I only managed it because one agent had logged its diff before the stash ate it.
The fix was unglamorous. One task, one worktree, one branch, one pull request. Every agent that touches the repo gets its own checkout. When a run dies, its partial work sits on its own branch instead of poisoning everyone else’s.
# one task = one worktree = one branch = one PR
REPO="$(git rev-parse --show-toplevel)"
WT="${REPO}/.work/task-${SLUG}-$(date +%s)"
git -C "$REPO" fetch origin master
git -C "$REPO" worktree add "$WT" origin/master
cd "$WT"
# pause the rebase watcher so it can't stash mid-run
touch "$(git rev-parse --git-path skip-auto-rebase-watcher)"
echo "agent isolated in $WT"Notice what the script doesn’t do. It never assumes the parent directory is clean, and it never shares a checkout. The paranoia is the point. It costs a few seconds of setup per task plus some disk, and in exchange no two agents can touch each other’s HEAD. Merge conflicts move to the end, where a human looks at them on purpose, instead of happening silently in the middle. That whole class of Thursday bug stopped existing.
Knowing when to fan out
The instinct to spawn is usually too eager, and I was worse about this than most. Every cold spawn re-pays a fixed setup cost: loading the brief, warming the cache, establishing the worktree. Fan out for trivial work and you spend more on overhead than you save on wall clock.
The arithmetic is almost embarrassingly simple. With N independent pieces of work that each take t seconds, going parallel only beats going in order when (N - 1) × t exceeds the spawn cost. Two tasks means both have to be genuinely slow before a second agent earns its seat. Ten tasks and you fan out without thinking about it. Below the line, you do the work inline and skip the ceremony.
I still get this wrong when I’m impatient. The tell is a fleet that feels busy and finishes late.
Three months in, it does real work. It audits its own pull requests, files findings as issues, routes each to the right narrow agent, and loops until a human is the only thing between a fix and master. None of that came from a smarter model. It came from treating the agents like what they are, which is a herd of fast, forgetful, occasionally brilliant workers, and building fences that let a herd be useful.
Part three gets into the review loop, which is where this started earning its keep.