One job, split across
many agents.
Some work is too big for one pass. Swarm plans it, hands the pieces to workers with their own context, runs them in waves, checks what comes back at merge, and returns one result.
The swarm panel with several workers running at once — statuses, what each is doing. This is the most distinctive screen in the product.
16/9How a hundred small jobs become one deliverable
A lead that plans, workers that do
One agent reads the whole job and decides how to cut it. Each worker gets its own brief and its own context window, so it is not carrying the noise of everything the others are doing. The lead never does the work itself, which is what keeps its view of the whole job intact.
The plan: the job broken into briefs, before any worker starts.
4/3Checked at merge, not on trust
Work coming back is checked before it is accepted — did it do what it was asked, did it stay inside its scope, is it consistent with the rest. Something that missed the brief goes back rather than being quietly merged. Checking at merge rather than at write is deliberate: it is the point where you can see the whole picture.
A merge with a rejection — work sent back, and why.
4/3A failed worker does not kill the run
Workers fail. A provider hiccups, a command times out, a file is not where it was expected. A failure costs that worker an attempt, not the whole job, and the run continues around it. Runs of several hours are the case this was built for.
Three hundred workers, six at a time
Up to three hundred workers per run, six running concurrently. The concurrency limit is not a shortcoming — it is what keeps the machine usable and the provider from rate-limiting the run into failure.
A long run in progress: many completed, six active, the rest queued.
4/3Work worth splitting
Research at breadth
Forty sources read properly in parallel rather than four read and thirty-six skimmed.
A codebase-wide change
The same edit across hundreds of files, each verified, merged as one change.
An audit
Every file examined against the same criteria, with nothing dropped because the context filled up.
A long report
Sections written in parallel, then reconciled so the terminology matches across all of them.
How it goes
- 1Ask for something bigYou do not have to plan the split. Describe the outcome.
- 2The lead commissions workersIt cuts the job into briefs and runs them in waves.
- 3Results are checked and mergedWhat missed the brief goes back. What passed becomes one deliverable.
FAQ
How many workers can run at once?
Six concurrently, up to three hundred per run. The concurrency cap keeps the machine responsive and avoids provider rate limits taking the run down.
What happens if a worker fails?
It costs that worker an attempt, not the run. The lead continues, and failed work can be retried.
Can I watch what each worker is doing?
Yes. The swarm panel shows every worker, its brief and its current state, live.
Does a swarm cost more than a single run?
Yes — it is more work, done in parallel. The trade is time and completeness against tokens.
Do I have to decide to use it?
You can ask for it directly, and the other agents can hand work to it when a job is genuinely too large for one pass.