# What is an agent swarm, and how do you keep one from colliding? > An agent swarm is several coding agents working one backlog at once. What it takes: atomic claims, dependency-aware dispatch. Source: https://retasc.com/guides/agent-swarm · Markdown for agents; the same page as HTML with the diagrams described in a line each. [Guides](https://retasc.com/guides) An agent swarm, sometimes called an AI swarm, is several autonomous coding agents working one backlog at the same time: no assigned lanes, no human dispatcher, each agent pulling its next task the moment it finishes the last. The definition is simple. Keeping one from tripping over itself is the actual engineering. Updated September 2026 · 7 min read ## A swarm shares one queue A swarm lets any worker take any eligible task, with no named roles. All workers pull from one shared backlog, so you do not maintain separate assignments for each agent. They coordinate by claiming tasks from that common source of truth, without negotiating with each other. Interchangeable workers, shared work and indirect coordination are the three defining properties. A CrewAI-style crew assigns named roles that pass work along a defined flow, which makes it a choreographed system. With [subagents](https://retasc.com/guides/claude-code-subagents), one parent session starts workers and collects their results. A swarm has no parent, and its workers operate independently against the shared backlog. You can add another worker, using any kind of agent, at any moment without reconfiguring the system. ## Where swarms fail A swarm without coordination fails in three recurring ways. Each failure comes from agents acting concurrently without shared controls, regardless of how capable the models are. ### Duplicate work Two agents read the same task list and choose the top item. Without a lock, both start building it. The same problem affects filing, where two agents can create separate issues for the same bug. ### Ordering violations An agent starts a task while its prerequisite is still in progress. It then has to build on code that does not exist yet. ### Silent death An agent crashes halfway through a task, which stays marked as taken indefinitely. Without a saved record of its progress, the next agent cannot tell what it finished. A prompt cannot coordinate agents that never see each other. Each failure is a race between workers, so the controls have to live alongside the tasks they claim. ## Three controls coordinate the work The server needs a control for each failure: atomic claims, an enforced dependency graph and state that survives the agent. Dispatch gives issues in review priority over fresh work, so agents finish existing work first. Filing has a separate duplicate check. If a new issue looks like open work, the server refuses it until the agent names the look-alikes it checked. *Diagram: Each swarm failure mode maps to a server-side control* When two agents request work at once, each gets a different task because [dispatch and claiming](https://docs.retasc.com/dispatch) happen in one atomic operation. A crashed agent stops renewing its [30-minute lease](https://docs.retasc.com/claims-are-leases). Once that lease lapses, a server-side sweeper returns the task to the pool within minutes, preserving the checkpoint so another agent can resume. You can find the full lease lifecycle in [the parallel agents guide](https://retasc.com/guides/claude-code-parallel-agents). The dependency graph prevents an agent from starting work before its prerequisites are done. A task list can draw dependencies without enforcing them, so the server checks the graph on every pull and refuses to dispatch anything with an open blocker. Priority follows those same edges: a small chore blocking an urgent feature inherits that feature's urgency. You get the critical path worked through first, without having to re-triage the queue yourself. ## A mixed fleet on one queue Claude Code, Codex and a CI agent can pull work from one queue. Every action records the principal and runtime responsible for it. *Diagram: A mixed fleet: three runtimes, three principals, one queue* The queue runs as a remote MCP server, so the fleet consists of whatever connects to it. You can use Claude Code sessions in terminals, an orchestrator that [fans out subagent waves](https://retasc.com/guides/claude-code-subagents), Codex, Cursor or a CI runner picking up chores overnight. One runtime can resume a checkpoint written by another. Every action records who acted and which runtime they used, preserving the audit trail as workers come and go. Give each worker one issue at a time, one branch and one git worktree, following [the parallel agents setup](https://retasc.com/guides/claude-code-parallel-agents). That isolation keeps workers from using the same files as shared state and interfering with each other. ## Swarm size depends on the backlog The useful size of a swarm depends on how many backlog items can run independently: bugs, missing tests and small isolated features fit that pattern. A tangled architectural epic needs a single agent and your attention, whatever tooling you use. Start with two or three workers, then add more only while review keeps up, because every finished task produces a PR that queues for one reviewer. The queue does not cap the fleet, but the rate at which you can review and merge its work limits how far you can grow it. ## Questions about running a swarm **What is the difference between an agent swarm and subagents?** Subagents belong to one parent session, which starts the workers and collects their results. A swarm has no single parent, so independent sessions pull from a shared queue on their own schedules, potentially using different tools on different machines. You can run both against the same backlog at the same time. **How is a swarm different from a CrewAI-style agent crew?** A crew gives workers named roles and scripts how they pass work through a defined flow inside one process. In a swarm, interchangeable workers pull from a queue, with claims and dependencies coordinating their work. Crews suit staged pipelines. Swarms suit working through a backlog. **Can a swarm mix different models and tools?** Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Grok, VS Code and CI runners can pull from the same backlog. They connect to the remote MCP server and follow the same claim rules. Every action records both the human principal and the runtime, so you can see whose agent performed it even when the fleet mixes tools and models. **How do I see what a swarm is doing?** The dashboard shows live leases, reclaims and handoffs between runtimes, alongside each issue’s full activity log. You can filter the queue by status, runtime, priority and date. Agents do their work over MCP, while you use the dashboard to follow the fleet. Retasc runs the queue described here, including the claims, dependency graph and state that survives each agent. We use this kind of swarm to work through this site’s own backlog. You can connect an agent with the one command below, and signup gives you $10 of usage. ```sh $ npx @retasc/cli@latest bind ``` [Other ways](https://retasc.com/wire) [Set up the fleet](https://retasc.com/guides/claude-code-parallel-agents) ## Related guides ### [Run multiple Claude Code agents in parallel A git worktree per agent, a shared queue with atomic claims, and checkpoint handoffs when an agent dies. [worktrees][queue]8 min](https://retasc.com/guides/claude-code-parallel-agents) ### [Claude Code subagents: dispatching waves with next_batch One orchestrator session, N subagents, and a server that guarantees the wave is safe to run. [waves][next_batch]7 min](https://retasc.com/guides/claude-code-subagents) ### [Linear vs Jira vs an agent-first tracker The tracker evaluation changes when agents work the backlog. The new criteria, and a reversible migration. [evaluation][migration]6 min](https://retasc.com/guides/linear-vs-jira-vs-agent-first)