The definition, precisely
Three properties separate a swarm from other multi-agent shapes. The workers are interchangeable: any agent can take any eligible task, so there are no named roles. The work is shared: one backlog, not per-agent assignments. And coordination is indirect: agents never negotiate with each other, they just claim tasks from a common source of truth.
That rules out two things the term gets confused with. A crew (the CrewAI shape) scripts named roles passing work along a defined flow; it is choreography, not a swarm. And subagents are one parent session fanning out workers it will collect; a swarm has no parent. The distinguishing mark of a swarm is that you can add a worker, of any kind, at any moment, and nothing needs reconfiguring.
Where swarms fail
Every swarm that runs on hope fails the same three ways, and all three are concurrency failures, not intelligence failures.
Duplicate work
Two agents read the same task list and pick the same top item. Nothing locked it, so both build it.
Ordering violations
An agent starts a task whose prerequisite is still in flight, and builds on code that does not exist yet.
Silent death
An agent crashes mid-task. Its task looks taken forever, and what it finished is written down nowhere.
Prompting cannot fix any of these, because each one is a race between agents that never see each other. The fixes have to live where the tasks live.
The three controls a swarm needs
Each failure maps to one server-side control, and the combination is what makes a swarm boring to operate.
Claims kill duplicate work: handing out a task and claiming it are one atomic operation, so two agents asking at once get two different tasks. Leases kill silent death: a crashed agent stops renewing, and once its lease lapses a server-side sweeper returns the task to the pool within minutes, checkpoint intact, for the next agent to resume. The full lease lifecycle is in the parallel agents guide.
The dependency graph kills ordering violations, and this is the piece most task lists draw without enforcing. Drawing an edge is easy; refusing to dispatch a task while anything blocking it is open, and recomputing that on every single pull, is what makes the edge real. Priority flows through the same graph: a small chore blocking an urgent feature inherits the urgency, so the critical path drains first without a human re-triaging.
A swarm in practice
Here is what the shape looks like when it is real: a mixed fleet on one queue, every action attributed to a principal and a runtime.
The mix is the point. Because the queue is a remote MCP server, the swarm is whatever connects: Claude Code sessions in terminals, an orchestrator that itself fans out subagent waves, Codex, Cursor, a CI runner picking up chores overnight. A checkpoint written by one runtime is resumed by another, and the identity on every action means the audit trail survives the churn.
Each worker still follows the ground rules from the parallel agents setup: one issue at a time, one branch, one git worktree, so the file system never becomes the shared state that breaks everything.
Swarm size, and when not to swarm
Swarms scale with the independence of the backlog, not with your appetite. A pile of bugs, missing tests and small isolated features swarms beautifully. One tangled architectural epic does not; it wants a single agent and your attention, whatever the tooling. And every finished task becomes a PR that queues on one reviewer, so grow the swarm only while review keeps up. Two or three workers is the honest starting size; the queue does not cap the fleet, your merge bandwidth does.
Questions that come up
What is the difference between an agent swarm and subagents?
Subagents are one session fanning work out to workers it spawned and will collect. A swarm has no single parent: independent sessions, possibly different tools on different machines, each pulling from the shared queue on its own schedule. Both shapes can run against the same backlog at the same time.
How is a swarm different from a CrewAI-style agent crew?
A crew scripts collaboration: named roles passing work along a defined flow inside one process. A swarm is unscripted: interchangeable workers pulling from a queue, coordinated by claims and dependencies rather than by a conversation. Crews suit staged pipelines; swarms suit draining a backlog.
Can a swarm mix different models and tools?
Yes, that is most of the point. The queue is a remote MCP server, so Claude Code, Codex, Cursor, OpenCode, Cline, Gemini and CI runners pull from the same backlog under the same claim rules, and every action is attributed to a human principal plus a runtime, so you always know whose agent did what.
How do I see what a swarm is doing?
The dashboard shows the fleet live: leases ticking, reclaims, cross-runtime handoffs, the queue filterable by status, runtime, priority and date, and every issue’s full activity log. The work happens over MCP; the dashboard is the human half of the loop.
Retasc is the queue in this guide: the claims, the graph and the durable state live on its server, and this site’s own backlog is worked by exactly this kind of swarm. Connecting an agent takes three commands, and signup seeds the first $10 of usage.