AI agent swarm coding is the practice of splitting one software task into independent sub-tasks and running several AI coding agents on them at the same time, each in its own isolated workspace, with a coordination layer that decides who does what and a verification layer that decides what is allowed to merge. The word that matters is isolated. If two agents edit the same working tree, you don't have a swarm — you have a race condition with a chat interface.
This post defines the term properly, walks the architecture layer by layer, answers Thoughtworks' public caution about the technique, and compares the tools people actually use. We build one of them, so read the comparison with that in mind — we've tried to be straight about where the others are the better choice.
Swarm coding vs. one agent in a loop
Most "AI coding agent" products are a single agent iterating: read, edit, run tests, repeat. That agent is sequential by construction. It can be excellent and still be one worker.
A swarm changes the unit of work from a change to a plan. Something has to decompose the request before code is written, hand each agent a slice, keep the slices from colliding, and then decide whether the reassembled whole is actually correct. Those four responsibilities — decomposition, isolation, verification, integration — are what separates a swarm from a for-loop over prompts. Everything hard about swarms lives in them.
The architecture
Anatomy of a coding swarm
1 · Request
One feature description, at the altitude you'd give a tech lead.
2 · Orchestrator
Reads the repo, splits the work into ordered tasks, assigns each task the files it owns.
Agent A
own branch
Agent B
own worktree
Agent C
own file lane
3 · Review gate
Every task's diff judged before it merges — architecture, security, style. Rejections go back to the agent with the findings attached.
4 · Integration verifier
Runs tests and lints on the combined result — catches the bug where each task is correct alone and broken together.
5 · Pull request
A human merges. Always.
Decomposition is where quality is won or lost. A bad split produces five agents fighting over one file; a good split produces five agents that barely need to know about each other. In Factory Nexus the orchestrator reads the directory tree, recent git history, and dependencies before it proposes tasks, and each task declares the files it intends to touch — its file lane. Other tasks' files are explicitly fenced off in the prompt.
Isolation has two halves, and most discussions only cover one. Git isolation (a branch and a worktree per agent) stops textual conflicts. Semantic isolation (file lanes) stops two agents from independently deciding the same handler is theirs to rewrite. You need both. Lanes can't be rigid, though — when an agent discovers it needs a file outside its lane, ours writes a file request and exits rather than grabbing it; the coordinator grants the file if it's unowned or its owner has finished, then restarts the agent without spending its retry budget.
Verification is the part that makes swarms viable at all, and we'll come back to it in a moment, because it's exactly what Thoughtworks is worried about.
Integration is the step people forget. Five individually-correct diffs can still combine into a broken build. A final agent forks from the merged result, runs the full suite, and fixes cross-task breakage before the work is called done.
If you want the screen-by-screen version of this, we wrote it up in Agent Swarms in the UI.
Thoughtworks says proceed with caution. They're right.
Thoughtworks placed coding agent swarms in the caution ring of its Technology Radar (Volume 34, April 2026), with two objections worth quoting:
They remain costly and are still far from mature, which is why we advise caution when adopting this technique.
and, on the experiments that made swarms look good:
Those conditions are not representative of typical product development, where requirements are less defined and verification is harder.
Both are fair, and we'd rather engage with them than pretend otherwise.
On cost: it's real and it's structural. Five agents burn roughly five agents' worth of tokens, plus review passes, plus retries. A swarm is the wrong tool for a two-line fix, and any honest vendor will tell you the same. The economics only work when the task genuinely decomposes.
On verification: this is the correct objection, and it's the whole design constraint. If your definition of done is "the agent said it was finished," a swarm multiplies your problems by N. That's why nothing here merges on an agent's own say-so: three reviewers gate every task, a verifier re-checks the combination, and a human opens and merges the PR. If a repo has no meaningful tests, a swarm will amplify that weakness — start by fixing the tests, not by adding agents.
On maturity, and the 100-agent fantasy: the demos that circulate tend to be enormous swarms on greenfield toy problems. Our experience points the other way. Small deliberate teams beat big ones: the useful range is a handful of agents on a well-scoped feature in a real repo. Our plan caps reflect that on purpose — 1 concurrent agent on Free, 5 on Pro, 20 on Team — and the orchestrator queues work beyond the cap rather than shrinking the feature to fit. We have never seen a case where going wider fixed a problem that a better decomposition wouldn't have fixed more cheaply.
Where swarms actually pay off
Four shapes of work where parallel agents beat a single agent, all of which share a property: the task splits along file boundaries with few shared decisions.
- A feature that spans layers. Endpoint, UI, and tests are three lanes with a clear contract between them. This is the canonical case — one prompt, three agents, minimal overlap.
- Broad mechanical migrations. Renaming an API across 40 call sites, moving a deprecated library, updating a config pattern repo-wide. Each agent takes a directory; the integration pass catches whatever the pattern-match missed.
- Backlog burndown. A dozen small, independent, well-specified issues. Not one big problem — many little ones, which is the case a single sequential agent is worst at.
- Test and coverage work. Writing tests for existing modules parallelises almost perfectly, because test files are naturally isolated and the pass/fail signal is unambiguous.
The inverse is just as useful to know. Swarms are a poor fit for deep single-threaded debugging, for exploratory work where the requirements change as you learn, and for anything that hinges on one architectural decision every task depends on — in that last case, make the decision first, then fan out.
How the tools compare
Four things get called "agent swarms" and they are not the same category. Here's an honest read, including where each beats us.
| What it is | Coordination | Best when | |
|---|---|---|---|
| agency-swarm | Open-source Python framework for multi-agent "agencies", built on the OpenAI Agents SDK. Agents are org roles you define. | You write it. Roles, tools, and message flow are yours to design. | You want a general-purpose agent framework and full control. Not coding-specific — git, isolation and review are yours to build. |
| Claude-Flow / Ruflo | Open-source orchestration layer for Claude Code, with swarm and "hive-mind" modes and a large MCP tool surface. | Queen-led workers; hive-mind mode gives agents shared memory through a common store. | You live in Claude Code, want maximum configurability, and are happy owning the setup. Runs on your machine, on your subscription — genuinely cheaper for a solo developer. |
| Factory.ai | Enterprise "autonomy stack" whose Droid agent runs across an app, a CLI, and web/mobile; markets code review, QA and docs automation. | Not documented publicly in detail; sold as a full-SDLC platform. | You're an enterprise buying a whole SDLC platform with a sales motion attached. Different company to us, despite the name collision. |
| Factory Nexus | Hosted platform: decomposition, one worktree per agent, a mandatory three-reviewer gate, an integration verifier, and a PR on your repo. | Orchestrator assigns file lanes; a coordinator arbitrates file requests and queues work past your plan's cap. | You want the swarm opinions made for you and enforced. Less flexible than a framework, parallelism capped by plan, and it's our product — weigh accordingly. |
The category distinction matters more than any feature row: the first two are things you assemble, the last two are things you buy. If you enjoy owning the plumbing, a framework will always beat a platform on flexibility.
Frequently asked questions
Is agent swarm coding the same as multi-agent AI? No. Multi-agent is the general pattern — several LLM agents with roles, cooperating. Swarm coding is the narrow case where the agents write code against a shared repository, which forces the hard requirements: version-control isolation, file ownership, and a merge gate. Most multi-agent frameworks don't address any of those, because they weren't built for code.
How do parallel agents avoid overwriting each other? Two mechanisms, both required. Each agent gets its own git branch and worktree, so nobody shares a working directory. And each task is assigned a file lane at decomposition time, so two agents don't independently claim the same file. Conflicts that survive both are surfaced for resolution, never auto-resolved silently.
How many agents should run at once? Fewer than the demos suggest. Three to five on a well-scoped feature is the productive range; past that, coordination overhead and token cost grow faster than throughput. If more parallelism seems necessary, the decomposition is usually the thing to fix.
Does a swarm need tests to work? It needs some verification signal, and tests are the best one. Without it there's nothing to distinguish "done" from "the agent stopped." This is Thoughtworks' central objection and we think it's correct — a review gate helps, but it isn't a substitute for a suite that actually runs.
Is this cheaper than one agent? No — it's faster in wall-clock time, and it costs more in tokens. You're trading money for latency. That trade is worth it for a feature that decomposes cleanly and a waste for a small fix.
Can I use a swarm on an existing production repo? Yes, and that's the case worth optimising for. Agents work on branches off your repo, and nothing reaches your default branch without a pull request you review and merge yourself.
Try it on something real
The fastest way to judge whether swarm coding is hype is to point one at a feature you already understand and read the diff. No signup required.