What Is an Agent Swarm?
An agent swarm is an arrangement in which many peer agents work on parts of one task with no central planner allocating the parts. Each member decides for itself what to take next, ordinarily by claiming an item from a shared medium — a queue, a board, a table of pending work — so coordination is a property of the medium rather than of any member. The word is used loosely in practice, and what it reliably denotes is the absence of the planner rather than any particular scale or shape.
What the shared medium has to settle
Claiming comes first. If two members read the same pending item they will both do it, so the medium has to make a claim exclusive and visible: a status field written under a condition that fails for the second writer, a queue that hands an item to exactly one reader, a lease with an expiry. The lease is the usual choice, because members stop, and an item held by a member that has stopped has to become available again. That expiry is also the reason a swarm can never fully rule out duplicate work: a member that is merely slow is indistinguishable from one that is gone.
Termination comes second and is the one most often left unanswered. No member holds the whole task, so no member is in a position to declare it finished. What ends a run is a property of the medium — nothing pending and nothing leased — and it has to be evaluated by something that can see both at once. A member concluding it is done because its own read came back empty has concluded nothing: another member may be one step away from writing three more items.
Merging comes last and is where a swarm's output is decided. Results arrive in the order members happened to finish, which carries no meaning, so any order the deliverable requires has to be recorded on the items themselves rather than inferred from arrival. And where two members produce overlapping results, something has to choose between them. A swarm without that rule does not fail loudly; it assembles a document containing both, and the duplication reads as thoroughness.
| Requirement | Failure in its absence |
|---|---|
| Exclusive claim | Two members take the same item, and both results are written. |
| Lease expiry | An item held by a stopped member is never completed, and the run never ends. |
| Order recorded on the item | The output is assembled in the order members finished, which is not an order anyone chose. |
| A conflict rule | Overlapping results are both retained, and the merge contains each of them. |
| A quiescence check | Members stop one by one as their reads come back empty, while work is still being added. |
| A budget held by the medium | Members that create work for one another have no bound, since each is individually behaving correctly. |
The last row is the failure with no local symptom. Every member is doing what it was told, every item it created is legitimate, and the only place the situation is visible is a total nobody is keeping. Bounds in a swarm belong to the medium, because a bound held by a member bounds one member.
What the arrangement buys, and where the word means something else
What it buys is throughput on work that genuinely decomposes into independent items: many documents to read, many files to change, many records to check. Members can be added or removed while the run continues, and a member that dies costs one item's progress rather than the run's. Those are the properties of a work queue with workers, and that is the honest description of most of what is built under this name — which is not a criticism, since a work queue is a well-understood thing to build and its failure modes are known.
What it does not buy is anything that would follow from members observing one another. In the usual arrangement peers do not read each other's reasoning; they read the medium. So there is no mechanism by which one member corrects another's mistake, and a wrong result written to the medium is an ordinary input to whichever member picks up the item that depends on it, indistinguishable from a right one. Redundancy of members is not review. Getting review requires a member whose item is to check another member's output, which is a role, and a swarm that has roles has a planner in it somewhere.
The vocabulary is worth pinning because two different shapes carry the name. One is the parallel arrangement above. The other is a handoff arrangement, in which a small number of agents pass a single task between them, each transferring control outright rather than working alongside the others. In the second there is one task in flight, so claiming and merging never arise, and the live question is instead whether anything is still responsible for the request after a transfer. Both get called swarms. Where the distinction matters, the question that separates them is whether members work at the same time on different items or one at a time on the same one.
How the Registry classifies a peer-coordinated task
Running a pool of peer agents over a shared task queue and merging their outputs into one ordered result is filed as information retrieval in this registry's classification. The classification reads what is produced and not how many components produced it: the deliverable is assembled from material the members located, and the parallelism decides how quickly rather than what kind.
The Registry's canonical brief for this entry is filed as:
Run a pool of peer agents over a shared task queue and merge their outputs into one ordered result.
Submitted for assessment it is
classified as Information retrieval, and its wording is hashed once — to
6468125b92d86f86…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/retrieval.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about agent swarm
How many members a task warrants, whether a given decomposition is sound, and whether a merged result is coherent are properties of a deployment, and the canonical brief above fixes none of them. This registry operates no members, holds no queue, and has merged no output.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about agent swarm
- What is an agent swarm?
- An agent swarm is a set of peer agents working on parts of one task without a central planner assigning the parts. Members take work from a shared medium and write results back to it, so the coordination rules live in that medium rather than in any member.
- How is a swarm different from a supervisor with workers?
- A supervisor decides who does what and receives the results, which makes allocation explicit and the supervisor a single point of failure. A swarm has members allocating to themselves, which removes the bottleneck and moves every coordination question — claiming, ordering, conflict, termination — into the shared medium, where it has to be answered explicitly or it is answered by accident.
- How do swarm members avoid doing the same work twice?
- By claiming exclusively: a conditional write, a single-reader queue, or a lease. Leases expire so that work held by a stopped member returns to the pool, and that expiry is why duplicate execution can be made rare but not impossible — a slow member and a dead one look the same from outside.
- How does a swarm know when it has finished?
- When the medium holds nothing pending and nothing leased, evaluated by something that can see both. An individual member’s empty read proves only that there was nothing to take at that moment, which is a different statement and a common source of runs that end early.
- Does adding more members make a swarm faster?
- Only while the items remain genuinely independent. Beyond that, members contend for the same medium, wait on the same dependencies and generate work for one another. Where the useful number stops for a particular task is a measurement taken on that task, and this registry has taken none.
- Do the members communicate with each other?
- In the arrangement the word usually denotes, not directly: they read and write the shared medium, and everything one member learns from another it learns as a written record. That is what keeps the arrangement simple to reason about, and it is also why a swarm has no built-in way for one member to catch another’s error.
Related entries
Order an assessment for information retrieval tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.