What is an agent swarm?

An agent swarm coordinates several coding agents toward shared work. The phrase gets used loosely, so the useful line is coordination. One agent finishing a task is a worker. Many agents doing separate jobs are a fleet. A swarm adds a shared task system: work is broken into items, dependencies are tracked, and results are checked before they join the product.

A request enters as a work item — a bug, a migration slice, a feature with a definition of done. An orchestrator assigns items to workers, records what each worker changed, and routes failures back into the queue. Review and release stay named human or policy decisions.

What a swarm adds beyond one agent

A shared work record. Steve Yegge's Gas Town and its successor Gas City are first-party experiments in exactly this: persistent work items, dependency graphs, and named worker roles that live outside any single agent session. Yegge is unusually candid about the costs — he reports that Gas Town failed under a later model and that these systems still need a person steering them. The mechanism is what matters, not the project names.

Orchestration. OpenAI's Symphony spec turns a Linear board into a state machine: each task becomes an isolated agent run with proof-of-work requirements and a protected landing path. The Symphony repository is the inspectable version of that design.

Backpressure and review at volume. Stripe's Minions run inside scoped context with internal checks, and every result still passes human review. In August 2026, Stripe president Will Gaybrick reported roughly 7,000 pull requests from Minions in one week — about 30 percent of that week's pull requests — a first-party figure, not an independent count.

Swarm, fleet, or one worker?

The distinction is what happens between workers, not how many exist.

• One agent can run a repeatable line: brief in, checked change out.
• A fleet is many agents doing separate jobs. Shared infrastructure helps, but no worker waits on another's result.
• A swarm adds coordination: a task graph, handoffs, and merge order matter. The hard parts are the seams — who reviews a worker's output, what happens when two workers touch the same file, and where a rejected result goes.

A Google Research taxonomy of agent behavior in software engineering underlines the same point from the worker side: as agents take collaborative roles, the organization has to specify behavior expectations that used to live in team habits.

Where the human decisions sit

Documented swarms keep people at named gates rather than "in the loop" generally: product choices and task acceptance, permissions, review of agent work, merge and release authority, and the decision to widen or shrink the swarm's scope. Notion's Token Town account describes the same pattern in its eval and self-verification work: the system earns autonomy task class by task class.

How to recognize a real swarm

Three tests separate a swarm from a demo of parallel agents. First, repeatability: another work item of the same kind can follow the documented path. Second, an inspectable work record: the team can see what each worker did, what checked it, and why it stopped or shipped. Third, named coordination: dependencies and merge order are explicit somewhere a person can audit, not implicit in one long session.

For the reported scale of these systems — concurrent workers, completed runs, and the limits beside each number — see Agent scale. For the system a swarm operates inside, see What is a software factory?.