TL;DR
AI agent swarms split one goal across three roles: a planner that breaks the work into tasks, workers that build those tasks in parallel inside isolated workspaces, and verifiers that test every change before it counts. The planner and verifier get your strongest model; the workers get cheaper, faster ones. The pattern fails when workers share files, verifiers rubber-stamp, or nobody caps the spend.
Why AI agent swarms are back in the news
Google made Gemini 4 Carbon generally available and previewed /swarm in Google Antigravity, which turns a single prompt into a coordinated team of agents. In Google’s words, Carbon takes “architectural design, coordination, and auditing,” paired with “faster, lighter models across parallel isolated workspaces and adversarial verifiers that test every change.”
That sentence describes a pattern you can run with models you already have. This guide covers the three roles, why the money goes to planning and verifying, where swarms break, and how to run one on a shared board. If you already run several coding agents, Sharkly gives each one a Task, a run log and a review step, which is most of what a swarm needs.
What is an AI agent swarm?
An AI agent swarm is a group of AI agents that split one goal into independent tasks and work on them at the same time. One agent plans and assigns the work, several agents execute it in parallel, and one or more agents check each result before it merges. Each role has a narrow job and a clear handoff.
Anthropic described the same shape in 2024 as the orchestrator-workers pattern: a central model breaks down a task, delegates pieces and combines the results. The verifier is the newer addition, and the role most teams skip.
A swarm is not “many agents doing the same work.” Five agents with the same prompt on the same repository is a race condition, not a team. The roles are what make it a swarm. For the wider picture of how agents get coordinated, see what AI agent orchestration is.
The three roles: planner, workers and verifiers
Each role answers a different question, and each one needs different context.
| Role | Question it answers | Typical model | Reads | Writes |
|---|---|---|---|---|
| Planner | What are the pieces, and who does each? | Strongest available | The goal, the codebase map | Task list, acceptance criteria |
| Worker | How do I build this one piece? | Cheaper, faster | One task, its files | A diff in its own workspace |
| Verifier | Does this change do what the task said? | Strongest available | The task, the diff, test output | Pass, or a rejection with a reason |
What does the planner do?
The planner turns a vague goal into tasks that don’t overlap. A good plan names the files each task may touch, the test that proves it’s finished, and the order when one task depends on another. If two tasks need the same file, the planner merges them into one or runs them in sequence.
What do the workers do?
Workers build one task each, in parallel, and nothing else. Each worker gets its own workspace, usually a git worktree: a separate checkout of the same repository on its own branch. That isolation is what lets three workers edit code at once without overwriting each other. More on that in parallel agents in isolated worktrees.
What do the verifiers do?
Verifiers try to prove a change wrong. Google’s word is “adversarial,” and it fits: the verifier runs the tests, reads the diff against the task, and looks for the shortcut a worker might have taken. A verifier that only asks “do the tests pass?” will miss a worker that edited the tests to pass.
Why the expensive model plans and audits
Planning and verifying are short reads with high stakes. Building is long output with low stakes per line. That asymmetry decides where each model goes.
A planner writes a few hundred lines of task descriptions. A verifier writes a verdict. Neither produces much output, so a premium price per token costs little in total. Workers produce most of the tokens, so cheap models there save the most.
Mistakes scale differently too. A bad plan misdirects every worker, and a lazy verifier passes every bad change. A weak worker produces one bad diff, which the verifier catches. Put your judgement where an error multiplies.
Google’s own positioning backs this split. It says Gemini 4 Argon “remains the ideal choice for the majority of software engineering and knowledge work,” while Carbon uses more tokens “to explore thoroughly, reason deeply, and run extended verification loops.” Carbon costs $2 per million input tokens and $10 per million output until November 30, 2026, then $4 and $20. For the model details, read Gemini 4 Carbon for coding agents and Gemini 4 Argon for coding agents. The same reasoning applies to any pair of models; see mixed-model Crews with cheap workers and an expensive reviewer.
Where AI agent swarms fail
Most swarm failures come from three gaps: shared state, weak checks and no budget.
Why do agents overwrite each other?
Two workers touch the same file because the plan didn’t say they couldn’t. Without isolated workspaces, the second write wins and the first worker’s change vanishes. With isolation, both changes survive until merge, where they conflict. The fix lives in the plan: assign file ownership per task, and serialize the tasks that share files.
Why do verifiers rubber-stamp?
A verifier that reads the worker’s summary instead of the diff is grading a claim, not the work. It sees “all tests pass” and agrees. Give the verifier the raw diff and the test output, never the worker’s self-report. Run it on a different model from the workers too, so it doesn’t share their blind spots. AI code review agents covers what a reviewing agent can and can’t confirm.
How do swarm costs blow up?
Every rejection triggers another build and another review, so a task that fails three times costs four of each. Ten workers in a reject loop overnight can burn a week of budget. Cap retries per task (two is a sane default), cap concurrent workers, and send a task to a person after the last retry fails.
A fourth failure hides under the others: if the plan, runs and verdicts live in one context window, nobody can audit the result. Someone outside the swarm still has to watch it.
How to run an AI agent swarm on a shared board
You don’t need a dedicated swarm tool to run a swarm. You need tasks, isolated workspaces and a gate. A shared board gives you all three, and it keeps the record where people can read it.
- Create one parent task for the goal. The planner reads it and writes the plan as subtasks, each with its files and its acceptance test.
- Give each worker exactly one task. One task, one agent, one branch. If two subtasks share a file, merge them before anyone starts.
- Run each task in its own directory. A worktree per run keeps parallel edits apart.
- Add a Review status before Done. No task moves to Done on the worker’s word.
- Assign the review to a verifier agent on a stronger model. It reads the diff and the test output, then passes the task or sends it back with a reason.
- Put a person at the last step. The verifier shortens the list; a human accepts the result.
Here is how that maps to Sharkly. A Crew is a reusable group of People and Agents coordinated by one leader Agent. Assign the parent Task to the Crew and the leader starts first: it reads the Task, then involves member Agents for specific pieces and combines their results. That leader-first order means no worker starts before the plan exists.
Agents in Temporary working-directory mode get an isolated directory per Task, and repository-backed runs can prepare a fresh worktree, so parallel workers don’t share files. Each Agent runs on the Runtime you configure, which is how the leader and the reviewer end up on a stronger model than the workers.
The review gate is a status in your Task workflow. An Agent can leave a Task waiting for human review, and that hand-off shows up in the Task Chats module in the main sidebar, as the Agent task execution docs describe. Failed or blocked runs still reach the Inbox. Agents research, execute, test and report. People set direction, grant authority and accept the result. Sharkly is free to start: connect one Computer, create two Agents, and assign a Crew something small. For more on the human side, read designing review for parallel agents.
When you don’t need an AI agent swarm
Skip the swarm when the work doesn’t split. A single bug fix, a one-file refactor or one long chain of reasoning goes faster with one strong agent and one reviewer. Below three independent tasks, coordination usually costs more than the parallelism returns.
Use a swarm when the goal breaks into pieces that touch different files: a multi-package migration, a test backfill across modules, or one API change applied to ten services. Google names “multi-package migrations” and “cross-subsystem root-cause investigations” as the work Carbon handles well in multi-agent setups.
Conclusion
An AI agent swarm is three jobs, not one big prompt: plan, build, verify. Spend your best model on the plan and the verdict, cheap models on the build, and keep every result where a person can read it. Start with one parent task, three workers and a verifier. To run that shape on agents you already have, connect a Computer to Sharkly and assign your first Crew.
FAQ
What is the difference between an agent swarm and multi-agent orchestration?
Orchestration is the general practice of coordinating several agents. A swarm is one orchestration pattern with fixed roles: a planner, parallel workers and verifiers. Every swarm is orchestrated; not every orchestration is a swarm.
How many agents should an AI agent swarm have?
Start with one planner, three workers and one verifier. Add workers only when tasks stay independent and your review queue keeps up. More workers than reviewable results only moves the bottleneck to the verifier.
Can the planner and the verifier be the same agent?
They can share a model, but keep them separate runs with separate context. A planner reviewing its own plan’s output tends to approve it. A fresh verifier reads the diff without the planner’s assumptions.
Do I need Google Antigravity to run an agent swarm?
No. /swarm is a preview inside Antigravity, but the pattern only needs task splitting, isolated workspaces and a review step. You can build it with git worktrees and a board, using whichever coding agents you already run.
What stops swarm workers from editing the same file?
The plan assigns file ownership so tasks don’t overlap, and isolated workspaces keep each worker’s edits on its own branch until merge. A CODEOWNERS rule adds a check at review time.
