SwarmForge: Uncle Bob's Agent Orchestration

Robert C. Martin, the man who wrote Clean Code, has spent the last few months building a multi agent coordination system, and the shape of it is exactly what you'd guess. SwarmForge runs a group of AI agents in tmux sessions, each in its own git worktree, each holding a role from a software-craftsmanship playbook: a specifier writing Gherkin, a coder doing TDD, a cleaner running DRY and CRAP reviews, an architect guarding dependency direction, a hardener doing mutation testing, and QA verifying the lot.

The discipline isn't decoration. It is the product. Take the roles away and you have tmux with extra steps.

unclebob/swarm-forge started on April 17, 2026 and reached 2,069 stars by August 10. The account is Robert C. Martin's, confirmed by the profile's name, the Uncle Bob Consulting company field and the cleancoder.com link. One caution before anything else: the README's first line, above the title, tells you not to spend money on a "bankrbot SWARM token." Somebody is trading on the name. It isn't his.

Key Takeaways:

• main is documentary. The runnable configurations live on branches named two-pack, four-pack and six-pack, and you install by pulling a branch tarball, not by cloning.
• Each role can run a different backend: claude, codex, copilot or grok, chosen per role in a config file.
• Agents work in separate git worktrees under .worktrees/, which is how six of them edit one project without colliding.
• Behaviour comes from a layered "constitution" of prompt articles plus per-role prompt files, all project-local and all editable.
• There is no licence file. Absent one, default copyright applies and all rights are reserved, whatever the public repository implies.

What SwarmForge is

A tmux orchestration layer with opinions, sized in three configurations.

two-pack is the fast one: a coder implementing with TDD and unit tests, and a cleaner that batches the coder's handoffs and does cleanup, DRY and CRAP review, architectural review, encapsulation fixes and mutation hardening. Flow runs coder to cleaner and back. No specification step, no acceptance tests.

four-pack adds specification. A specifier turns your intent into precise Gherkin acceptance specs and asks for approval before handing off; the coder implements approved slices; a refactorer does behaviour-preserving cleanup, coverage work and property-test support; an architect owns structure and dependency direction and signals completion.

six-pack splits every quality gate into its own agent: specifier, coder, cleaner, architect, hardender for mutation work, and QA converting the specifier's procedures into executable scripts and running final verification. Six agents, one project, one linear flow ending in a completion notification.

You pick a size to match the job, which is a more honest interface than "how many agents do you want."

Why the author of Clean Code built an agent orchestrator

Read the role list again and it's a familiar argument in new clothes.

Martin's long-running position is that software quality comes from process discipline rather than individual brilliance: write the test first, keep the design clean, review structure separately from behaviour, verify what you claim. Agents make that argument sharper, not weaker. A model will happily write code with no tests, restructure something it shouldn't have touched, and report success. Roles with fixed responsibilities and mandatory handoffs are a way of forcing the process onto something that has no professional instincts of its own.

The "constitution" mechanism is the same idea one level up. swarmforge/constitution.prompt points agents at article files under swarmforge/constitution/articles/, shared articles come from main, and each workflow branch adds its own local ones. Rules as a layered document, versioned in your project, rather than as a giant system prompt nobody reads.

Whether it produces better code than one strong agent doing everything is unproven, and nothing in the repository claims otherwise. What it produces for certain is legibility: you can watch each role in its own terminal and see where the work stalled, which is the thing that's usually missing when you run several coding agents in parallel.

How the multi agent coordination actually works

Multi agent coordination here rests on three mechanisms, none of them exotic, which is rather the point.

Git worktrees handle isolation. Roles assigned a dedicated worktree name get one created under .worktrees/, so the coder and the refactorer aren't fighting over the same checkout. Git already solved this problem; SwarmForge just uses the solution.

Tmux handles process management. One session per configured role, one terminal surface each where the backend supports it, so the swarm is observable in the plainest possible sense: you look at it.

Handoff scripts handle communication. The shared swarmforge/scripts/ directory goes onto each agent's PATH, including handoff helpers, so agents pass work along by running commands rather than through a message bus. All swarm state stays local in .swarmforge/.

Prerequisites are correspondingly unglamorous: zsh, git, tmux, Babashka for the Clojure-flavoured scripting, and at least one agent backend configured. Getting started means curling a branch archive into your project directory and running ./swarm, which on first use fetches the shared scripts from main and launches the configured windows.

The `caffeinate` detail, and what it admits

Buried in the setup notes: while a swarm is active, SwarmForge tries to stop the host from sleeping, using caffeinate on macOS and systemd-inhibit on Linux where available. You can turn it off with SWARMFORGE_PREVENT_SLEEP=0.

That single line is the most revealing thing in the documentation, because it concedes what local orchestration is up against. Six agents doing specification, implementation, cleanup, architecture, hardening and QA on a real feature is not a five-minute job. It's a long job. And the machine has to be awake, unlocked and undisturbed for all of it, with the README admitting that display lock or a manual sleep can still interrupt agents depending on the OS.

So the ceiling isn't the orchestration quality. It's that the work is pinned to a laptop somebody needs to close, which is the same wall every local agent harness eventually hits.

Where this fits, and the licence problem

For a solo developer who wants craftsmanship discipline applied to agent work on a real project, this is a thoughtful setup and the branch sizing means you don't pay six agents' worth of tokens for a small change. Watching a specifier argue with a coder in adjacent terminals is also, genuinely, a good way to learn what these tools do badly.

For a company, stop at the licence. There is no licence file in the repository, and that isn't a formality: without an explicit grant, default copyright applies and nobody has permission to use, copy, modify or distribute the work. Public on GitHub is not a licence. Any legal review will flag it, and the fix is an issue asking the author to add one, not a decision you make on his behalf.

The other consideration is human. Six agents producing handoffs faster than anyone can read them is a supervision problem dressed as a productivity gain, and the way people and agents actually work in parallel matters more than how many sessions tmux can hold.

The vocabulary, for anyone who didn't do the reading

Several role descriptions use terms that are standard in Martin's world and obscure everywhere else, so here they are in plain language.

Gherkin is the Given/When/Then syntax for writing acceptance criteria that both a person and a test runner can read. The specifier produces these and waits for your approval before anything gets built, which is the one human checkpoint the workflow insists on.

CRAP is an actual metric, the Change Risk Anti-Patterns score, combining cyclomatic complexity with test coverage. Complicated code with poor coverage scores badly. A cleaner running "CRAP review" is hunting exactly that combination.

Mutation hardening means deliberately changing the code, flipping a comparison, deleting a line, and checking whether the tests notice. Tests that pass against mutated code are tests that weren't testing anything. It's the strongest available answer to coverage numbers that look good and mean nothing, and giving an agent that job is a decent way to catch another agent writing decorative tests.

Property tests check that a rule holds across generated inputs instead of the three cases someone thought of.

Put together, the six-pack roster is a quality process with agents slotted into it, rather than agents with a process bolted on afterwards. Multi agent coordination here means dividing responsibility, not dividing labour: each role exists because someone has to be accountable for one specific way software goes wrong.

FAQ

Who made swarm-forge?

Robert C. Martin, known as Uncle Bob and the author of Clean Code. The GitHub account unclebob carries his name, the company field reads Uncle Bob Consulting LLC, the linked site is cleancoder.com, and the account has existed since 2008. Unrelated: a crypto token using the SWARM name has no connection to the project, and the README says so in its first line.

Is swarm-forge open source or licensed?

No licence file exists in the repository as of August 2026. That means default copyright, all rights reserved, with no permission granted to use, modify or distribute it. Publishing code publicly does not by itself licence it. Treat it as unlicensed until the author says otherwise.

Which AI backends does SwarmForge support?

claude, codex, copilot and grok, selectable per role, so a specifier could run on one model and a coder on another. You need at least one configured before starting a swarm.

How many agents should I run?

The project answers this with branches instead of a slider. two-pack for small tasks wanting a tight implement-and-clean loop, four-pack when you want Gherkin specification and architectural review without a separate agent per gate, six-pack for major work where every quality gate gets its own owner.

Does SwarmForge need Clojure?

It needs Babashka, the fast-starting Clojure scripting runtime, along with zsh, git and tmux. You don't write Clojure to use it; the shared operational scripts do.