An agent swarm is a multi-agent pattern in which control passes directly from peer to peer: whichever agent currently holds the conversation works until a handoff condition fires, then transfers control — along with the accumulated context — to another agent. No central coordinator plans the route; the path emerges from the handoffs themselves.
Why the swarm pattern matters
Real interactions rarely follow a script. A support session opens as a billing question, turns into a refund negotiation, and ends needing a technical specialist. A central planner has to predict paths like that in advance — or route badly. A swarm sidesteps prediction: the agent handling the conversation recognizes when the work has moved beyond its own competence and passes control to a peer better suited to continue.
The payoff is coverage without bloat. Each specialist keeps a narrow prompt and a short tool list, yet the system as a whole handles a wide, unpredictable surface. The cost is that no agent holds a global plan, which makes a recorded trail of every transfer more important, not less.
How it works
- One agent is designated the entry point and receives the request along with the shared conversation context.
- The active agent works normally — reasoning, calling tools, replying — while the runtime evaluates declared handoff conditions against its output.
- When a condition fires — the agent mentions a defined phrase, emits an explicit transfer signal, or a rule over the conversation matches — control moves to that condition’s target agent.
- The receiving agent inherits the accumulated context and becomes the active agent. The cycle repeats until an agent finishes without triggering a handoff, and its answer becomes the result.
Note that the conditions are declared ahead of time even though the route is not. Durable multi-agent runtimes ship this as a first-class strategy: the developer lists the participating agents and a set of condition-to-target pairs, and the execution layer records each transfer as it happens.
Swarm vs. supervisor
Both patterns coordinate specialists; they differ in where control lives. A supervisor is a central coordinator that plans, delegates, and integrates — workers respond only to it and never to each other. In a swarm, control moves laterally: each transfer is decided by the currently active agent and the declared conditions, and there is no integration step — the agent holding control last produces the answer. The distinction mirrors orchestration vs. choreography in distributed systems: the supervisor is orchestration applied to agents, and the swarm is choreography.
In practice
A swarm’s flexibility is only safe when its transfers are visible. In a durable runtime the swarm is one of several coordination strategies — alongside the supervisor, routers, and sequential pipelines — and each handoff is checkpointed with the conversation state at the moment of transfer, so an emergent route through a multi-agent system remains fully reconstructable afterward. For the complete set of strategies, including condition-based swarm handoffs, see the multi-agent strategies documentation.