A Swarm ships the whole project
State a goal. A Project Manager agent assembles a team and writes a plan you can read, edit and argue with. Once you sign off, it drives the work through Build → QA → E2E and lands it on your branch, with a timeline, a design canvas and a live console along the way. A single Involvement dial decides how much stays on your desk.
Define → Run kickoff
Document · Flow · Timeline · Canvas
Involvement dial, 10 gate kinds
Your branch, or one GitHub PR
A run, stage by stage
Real captures from a live daemon running real projects. Click any image to enlarge it.
How a Swarm run moves
From a stated goal to work landed on your branch · layer-level view
The engine combines proven pieces — the sub-agent tree, the Team loop and the goal-seeking Loop harness — as sibling teams rather than deeper nesting. Read the hands-on guide on the docs site.
Built for long, real projects
What weeks of real runs on real apps added to the engine and the UI.
The plan is a document
Document, Flow, Timeline and Canvas views. You can edit, drag, add, drop or regenerate tasks, and copy the plan as JSON for machines.
Talk to the PM
Ask for a change in plain words. The PM proposes a set of edits, each one checked against the plan, and you apply all of them or none.
Team charter
Roles, responsibilities and the reasoning behind each seat. The PM says which seats it would drop, and contract seats bind the plan.
Deadlines that matter
Set deadlines and milestones in Define. The PM plans against them, and the Console warns you when the forecast slips past one.
Run controls
Pause, Stop, Stop now, Continue, Restart or start a new run. Continue rebuilds deleted worktrees from their branches.
Honest budgets
Budget tokens count cached re-reads at a tenth. Spend is broken down by phase, cap suggestions come from past runs, and a provider usage limit fails over to your backup provider.
An agent can run it
Hand a swarm to one of your agents. It runs routine operations itself and sends you a confirmation card for anything outside its mandate.
Safe landing
Worktrees live beside your repo, never inside it. The final land fast-forwards your base branch and never merges into your checkout.
Two engines, one surface
Every Project runs one of two execution engines. Pick by the shape of the work: a quick, known build that a single agent can hold, or an open-ended project that needs a whole team.
The basic Project pipeline
A formal, linear, controlled process. One agent runs a known plan from start to finish — no manager, no team, no coordination overhead. It is built for smaller, one-off projects whose outcome is more or less known up front and whose work fits inside a single context window.
- →Faster — one plan, straight through, no back-and-forth.
- →Simpler — deterministic steps you can follow at a glance.
- →Same Timeline & Canvas — on the Plan card of any standard project.
An org that finishes the job
For larger, more complex, open-ended work that no single agent can hold in context. A Project Manager assembles a multi-agent team: agents you pick, plus specialists the PM hires to fill gaps as the plan takes shape. Contract agents exist only for the run, and you can promote a useful one to a permanent agent once the project ships.
- →A plan you sign off, in work phases with review milestones.
- →Sibling QA and E2E teams that try to break the work.
- →Crash-safe checkpoints: a run resumes rather than restarting.
On the Projects page, Adaptive Swarm opens the kickoff wizard, and a standard project keeps its own direct flow. Start structured and stay direct, or run a Swarm when the work outgrows one agent.
The six phases of a run
Assembly → Planning → Build → QA → E2E → Sign-off. Each phase rolls up to the PM, and the console always names the stage the run is in.
Assembly — a team with a charter
A five-step kickoff — Define → Team → Brainstorm → Plan → Run. You state a goal and set the rails, and the PM proposes the smallest team that covers the work, with one owner for each workstream. It drafts a team charter: each member’s role, responsibilities, and why they are here. It also flags overlaps and names any specialists it needs to hire.
Past five seats you get a warning, never a cap. Remove a member or ask the PM to revise the charter before you approve it.
Planning — a plan you can read, edit, and argue with
The PM turns the brainstorm into ordered work phases and review milestones, with an owner, dependencies, and acceptance checks for every task. An audit pass raises any design questions it missed. Until you sign off, you can edit tasks, drag them between phases, add or drop work, regenerate the plan, or talk it over with the PM. The PM replies with a checked set of changes, and nothing applies until you press Apply.
Deadlines from Define are in the PM’s prompt, and the plan’s Timeline shows whether the work fits.
Build — parallel worktrees, one integration branch
Workers run up to five at a time, each in its own git worktree beside your repo. Finished work is squash-merged into swarm/<run>/integration task by task, and a conflict goes back to the task’s owner. Named milestones pause for your review, and a smoke check (build, type-check, test collection) has to pass before QA starts.
When the plan needs expertise nobody on the team has, the PM hires a contract specialist (see below).
QA — an audit team that tries to break it
Read-only QA reviewers split the work into partitions and audit them in parallel. Critical and high findings go back to the task’s owner, and the fix ⇄ audit loop repeats. The console names the stage, for example QA fixes · cycle 1 · 17 findings (9 blocking) · fixes 2 of 5 done.
If QA stalls or hits its cycle limit, the run stops and asks you: accept as is, change approach (with your guidance), or drop the task. It asks at every Involvement level.
E2E — real end-to-end exercise
An E2E team exercises the integrated project with a real browser and screen recording, not mocks, and saves its evidence with the run. Its findings go back to the PM just like QA’s. When a run resumes, partitions that already passed on unchanged code are reused instead of re-tested.
Testers get browser tools that the build and QA teams never hold. Each team gets only the tools it needs.
Sign-off — land it safely
You give the final approval. The swarm squashes the integration branch in a scratch worktree and fast-forwards your base branch, or merges one GitHub PR. It never merges into or resets your own checkout. If your local changes are in the way, it stops and tells you, and the commit waits on swarm/<run>/land.
Every run is checkpointed. A crash, reboot, or provider usage limit pauses the run, and it resumes from where it stopped.
One dial governs every gate
Involvement sets how much of the run needs you. Each checkpoint is a gate set to require (you decide), notify (it proceeds unless you veto), or skip. Override any single gate in the Team step.
You approve every checkpoint: team, plan, task assignments, phase transitions, milestones, QA findings and the final sign-off. Design decisions ask you too.
You approve the team, plan, phase transitions, milestones and final sign-off. The PM handles routine calls. Only high-impact decisions (schema, spend, security, public-facing) come to you.
You approve the team, plan and milestones, and then it runs. The PM makes design decisions and logs its reasons. You still sign off at the end.
The PM decides and proceeds. You are notified at each gate and can veto within a grace window (five minutes by default). Danger-floor tools still ask you.
Gates that need you never time out, and the time you take to decide is not charged to the run. When QA or E2E gets stuck, the run always stops for your decision, at every level.
Three ways the team works together
Collaboration mode decides whether agents work heads-down or talk to each other during a run. It is set per run and safe to change between runs.
Isolated
The coordinator hands each worker its task and collects the result. There is no shared room: agents work heads-down and in parallel.
Fastest and cheapest — maximum parallelism, tightest token budget. Best when the plan is cleanly partitioned and agents have no reason to talk.
On-demand
A shared group-chat room exists, and the PM pulls from it, asking specific agents for input at the right moment and organizing every answer.
Structured collaboration without the noise. The PM gets the input it needs when it needs it, and nothing else clutters the room.
Collaborative
An open floor: agents chime in when a topic is relevant and stay quiet when it is not, exchange peer-to-peer DMs on a side channel, and share a running project map the PM keeps up to date — even after context compaction.
Agents catch each other’s blind spots in real time. Choose it for the most interdependent, ambiguous work, where one agent’s decision changes another’s job.
A room stays durable under load: it compacts to a rolling summary, keeps a searchable history, and holds an always-in-context project map. If a rail trips, the chatter scales back and the run still finishes.
The PM is the tool broker
The PM holds every tool and gives each agent a least-privilege profile, granting more on request. Testers get a browser, auditors are read-only, and builders get only what their task needs. A configurable danger floor of high-consequence tools (GitHub, database queries, device commands, messaging) always asks a human, even at Full.
When the plan reveals a capability gap, the PM hires a contract agent: a lightweight specialist with its own persona and skills that exists only for the run. If you name a contract seat on the Team step, the plan must staff it. Afterward, you can promote a useful specialist to a permanent agent.
Real git, from the first commit
Each builder works in its own worktree and branch, kept beside
your repo in <repo>.swarm-worktrees/, never inside it. Work squash-merges into
swarm/<run>/integration, and you can review the diff in the app. Choose local git,
GitHub PRs on a new private repo or the existing repo in your project folder (it uses your gh
login), or no repo for one-offs.
Budget rails bound every run: agents at once, a token budget, a per-agent cap, a time limit, and QA and E2E cycles. You can see them live in the console, and you can raise them when you continue a run.
Structured Execution or Adaptive Swarm?
Every Project picks one execution engine. They are siblings behind the same surface: choose by the shape of the work, not by the tooling.
| Dimension | Structured Execution | Adaptive Swarm |
|---|---|---|
| Best for | Smaller, well-structured plans | Large, exploratory, or open-ended work |
| Plan | Fixed, deterministic, one active job | Work phases and milestones, audited, editable until you sign off |
| Team | One agent | PM → workers + contract specialists, plus QA & E2E teams |
| Quality pass | Per-task validation | Smoke check, dedicated audit team, real-browser E2E |
| Schedule & design | Timeline & Canvas on the Plan card | Timeline & Canvas, deadlines in the PM's prompt, slip warnings |
| Delivery | Files in the project workspace | Fast-forward of your base branch, or one GitHub PR |
| Resume after a crash | Job-level | Per-run checkpoints; Continue rebuilds worktrees |
Where Adaptive Swarm stands today
Adaptive Swarm is on by default in the Open Beta. That includes the five-step kickoff, the plan document and PM plan chat, Timeline & Canvas, the Involvement dial and gate overrides, budget rails, contract agents, the three collaboration modes, run controls, and checkpoint-resume. We have been running it on real multi-week app projects, and those runs drive most of the fixes above. Local git is the default and most-used repo mode. Formal revisions to a plan you have already approved are still being built behind a flag.
Defaults, budget behavior and gate behavior may change before general availability.
Give a goal. Get a project.
Adaptive Swarm runs entirely on your self-hosted daemon, with your code, your repo and your machine. Install Snippbot and choose Adaptive Swarm when you create a new project.