A Swarm ships the whole project
State a goal. A Project Manager agent assembles a team, authors a living plan you sign off on, then drives it through Build → QA → E2E and lands the work as one GitHub PR. A single Involvement dial decides how much stays on your desk — and how much the PM decides on your behalf.
Assembly → Sign-off
Hierarchy of agents
Involvement dial
Squash-merged on approval
How a Swarm run moves
From a stated goal to a shipped, signed-off PR · layer-level view
The engine composes proven primitives — the sub-agent tree, the Team loop, and the goal-seeking Loop harness — as sibling teams, not deeper nesting. Read the full architecture on the docs site.
Two engines, one surface
Every Project runs one of two execution engines. Pick by the shape of the work — a quick, known build 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.
- →More direct — files land in the project workspace, done.
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 agents the PM creates to fill intelligence gaps as the plan takes shape. Contract agents fill project-specific roles — a niche specialist the work needs now but not forever — then dissolve back into a reusable pool once they are done.
- →A living plan the team enriches before it builds.
- →Sibling QA and E2E teams that try to break the work.
- →Crash-safe checkpoints — a run resumes, it does not restart.
Same Project surface, same wizard, same file workspace — the engine is a single radio button. Start structured and stay direct, or turn on the 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, who decides when it is done.
Assembly — the kickoff wizard
A guided Define → Team → Brainstorm → Plan → Launch flow. You state a goal, set the Involvement dial and budget rails, choose a repo mode, and pick (or mint) a Project Manager agent. You do not have to hand-build the whole team up front — the PM proposes the workers and specialists once the shape of the work is clear.
Reuses the existing Projects wizard shell — the swarm is a second execution type on a Project, not a separate surface.
Planning — brainstorm to a living plan
A real multi-agent round-table, not a lookalike. The PM and seed team explore the goal, then the PM authors a spec and the team enriches it toward comprehensive coverage — tasks, owners, dependencies — before a single line is built. The plan you approve is exactly what the build runs.
An audit pass checks the plan against goal, repo, and available tools, surfacing missed design questions for you to answer.
Build — dependency-aware fan-out
Worker agents own tasks and may spawn sub-agents to do the work. Each agent runs the full git cadence — its own worktree and feature branch off the shared integration trunk — and opens PRs the PM squash-merges. Work fans out by dependency, phase by phase, and rolls up to the PM.
When the plan reveals a capability gap, the PM mints a contract agent to fill it (see below).
QA — an audit team that tries to break it
A sibling QA team audits the finished work aggressively and produces structured findings. Anything blocking routes back to the PM for reassignment, and the fix ⇄ audit cycle repeats until it converges — or escalates to you if it cannot.
QA runs as its own root with a read-only tool profile — it inspects, it does not patch.
E2E — real end-to-end exercise
An E2E team exercises the project with real browser and MCP tooling — not mocks. Smoke passes run at runnable milestones; a full pass gates the release. Findings loop back to the PM exactly like QA.
Testers get browser-CDP and MCP tools the build and QA teams never hold — least privilege, per team.
Sign-off — one GitHub PR
The whole project lands as a single squash-merged GitHub PR to your main branch (a new repo is created if needed). You give the final approval; the swarm merges. Every run is checkpointed, so a crash, power loss, or budget-exhaustion resumes from the last known state instead of restarting.
The Involvement dial decides how many of these gates need you versus the PM deciding on your behalf.
One dial governs every gate
Involvement sets how much of the run needs you. Turn it up and the PM makes the recommended call and simply notifies you; turn it down and you approve each step.
You approve team, plan, every phase, and every high-impact action. Nothing consequential happens without a tap.
You sign off on the plan and the release; the PM handles routine phase transitions and reassignments on its own.
The PM makes recommended design decisions and only stops for the release sign-off and the danger-floor.
The PM runs the project end to end and notifies you. A configurable danger-floor of high-consequence tools still requires your approval.
Three ways the team works together
Collaboration mode decides whether agents work heads-down or talk to each other during a run — set per run, and safe to change between runs.
Isolated
The coordinator hands each worker its task and collects the result. 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 voice.
Structured collaboration without the noise — the PM gets exactly the input it needs, exactly when it needs it, and nothing else clutters the room.
Collaborative
An open floor: agents self-elect to chime in when a topic is relevant (and abstain when it is not), exchange peer-to-peer DMs on a side channel, and the PM keeps a running project map every agent sees — even after context compaction.
Agents catch each other’s blind spots in real time — the richest coordination, for the most interdependent, ambiguous work where a decision by one changes the job of another.
A room stays durable under load — it auto-compacts to a rolling summary, keeps a searchable history, and holds an always-in-context project map. If a rail trips, the chatter soft-degrades and the run still finishes.
The PM is the tool broker
The PM holds every tool and hands each agent a least-privilege profile, granting more on request. Testers get a browser; auditors get read-only; builders get exactly what their task needs. A configurable danger-floor of high-consequence tools always requires human approval — even at Full autonomy.
When the plan reveals a capability gap, the PM mints a contract agent — a lightweight ephemeral specialist (prompt + skills + run-scoped memory) that lives in a reusable pool and can be promoted to a permanent agent once the project ships.
Real git, from the first commit
Every build agent works in its own git worktree and feature branch
off a shared integration trunk (swarm/<run>). Agent PRs squash-merge into the trunk after
QA; the trunk becomes the single PR to your main branch — a new repo created if you need one.
For one-offs, pick the no-repo mode and skip git entirely. Budget rails — max agents, tokens, wall-clock, and QA/E2E cycles — bound every run, with live visibility as it works.
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 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 | Living — the team enriches it before build |
| Team | Worker pool executes tasks | PM → workers → sub-agents, plus QA & E2E teams |
| Quality pass | Per-task validation | Dedicated audit team + real browser/MCP E2E |
| Delivery | Files in the project workspace | One squash-merged GitHub PR |
| Resume after a crash | Job-level | Per-agent + per-run checkpoints |
Where Adaptive Swarm stands today
The Swarm engine — the full Assembly → Planning → Build → QA → E2E → Sign-off life cycle, the Involvement dial, budget rails, contract agents, and checkpoint-resume — ships in the current Open Beta release behind a feature flag while it hardens. The collaboration modes (isolated, on-demand, and the open-floor collaborative room) are complete and gated behind their own flag. We would rather be specific about maturity than overstate it.
Prices, defaults, and gate behavior may change before general availability.
Give a goal. Get a project.
Adaptive Swarm runs entirely on your self-hosted daemon — your code, your repo, your machine. Install Snippbot and it is a radio button away on any Project.