AI agent teams, explained: lead, bench, specialist

The moment a project gets big, the instinct kicks in: if one AI agent is good, five must be five times better. Spin up a swarm, point them at the codebase, and watch it fly.

It doesn't fly. It collides. More agents on one problem is one of the most reliable ways to make agentic development worse. But agent teams are real and useful — when you get the roles and the rhythm right. Here's the shape that works.

Why people reach for more agents

The appeal is obvious. A single agent is a bottleneck — it does one thing at a time. Throw more agents at the work and surely it parallelises, the way adding people to a team adds throughput.

The analogy breaks because agents don't coordinate like people. They don't have a quiet word at the coffee machine. Point several at the same files and they overwrite each other, contradict each other, and leave you a tangle nobody can reconstruct. The instinct is right that one agent is limited. The fix isn't a swarm.

The multi-agent anti-pattern

Here's the trap, stated plainly: running multiple agents simultaneously on the same surface burns cost, produces contradictory output, and makes session briefs impossible to write. It's one of the clearest anti-patterns in agentic development, and the research on what makes multi-agent coding actually work keeps landing on the same point — coordination, not raw parallelism, is the hard part.

Stuart Leo

Five agents on one problem isn't five times the output. It's five times the conflict, and no clean way to record what happened.

Lead, bench, specialist

A team that works has clear, distinct roles:

• The Lead Agent — one agent, one surface. It reads the contextbase, writes the code, manages git, extracts knowledge, and writes the session brief. One lead per codebase surface. This is the agent doing the building.
• Bench Agents — independent review on high-stakes calls. They review, they never execute. Invoked for a PRD, a security question, an architecture decision — and budget-capped. Their entire value is independence: a fresh perspective the lead doesn't have.
• Specialist Agents — scoped subagents for repeatable tasks. A tightly defined role with specific tools and a documented protocol: QA review, release-note authoring, code review against a standard.

Each role is a different job, not a clone of the same job. That's why it works where a swarm doesn't.

Sequential where there's an edge

The insight people miss isn't never run agents at once. It's that agents sequence when something connects them. The rhythm lead executes → bench reviews → lead acts on the review runs in order because there's an edge — the bench reads what the lead produced. You can't review an artefact that doesn't exist yet.

Where there's no edge and no shared surface, agents can run at the same time. A surface is everything an agent mutates or contends for — files, data, a rate-limited API, a deploy target. Two agents on one surface is the anti-pattern, however urgent the session feels. Twelve agents on twelve disjoint surfaces, each with a brief that clears the quality gate, is the method working. The test is the surface, not the headcount.

The failure I've watched catch people is false independence — two agents whose briefs never mention each other, quietly colliding over one shared database. Anything shared is a hidden edge, and hidden edges bite hardest because nothing in the brief says they exist.

Running wide buys breadth, though. It doesn't buy judgment. If I can't find two briefs with no edge between them, there's no team to spread the work across — it's one job, and one agent doing it in sequence is the right tool most days. When the work genuinely is independent, each agent gets its own isolated git worktree. That's the thing a crowd on one problem never was.

Those two questions — is there an edge, is there a shared surface — are the whole decision procedure, and they're worth having in front of you before you spin anything up. The full version is here.

The shared contextbase that holds it together

What coordinates an agent team isn't agents talking to each other. It's a shared contextbase — the version-controlled briefs, decisions and gotchas every agent reads before acting. The lead writes to it. The bench reviews against it. The specialists read it for their scoped job. One source of truth, on disk, that every agent and every human shares.

That's the difference between a team and a mob: a team reads from the same page.

Agents sequence when an edge connects them and run at once when nothing is shared — the test is the surface, not the headcount.

Start here: see multi-agent vs single agent, parallel agents with git worktrees, or read the method.