AI agent swarm: what it is, and how anyone checks what it did.

What an AI agent swarm is

A single AI agent works in a line: think, call a tool, read the result, call the next tool. A swarm replaces the line with a crowd. One agent, often called the coordinator or orchestrator, breaks a job into sub-tasks and hands them out. Worker agents execute those sub-tasks in parallel, each with its own tools and context. Some workers spawn helpers of their own. When the pieces come back, a merge step combines them into the final answer.

People build swarms for three reasons. Speed: parallel workers finish in minutes what a sequential agent needs hours for. Coverage: a hundred sources can be read at once instead of one at a time. Specialization: different workers can carry different instructions, tools, or models, each fitted to its piece of the job.

The trade is accountability. The properties that make a swarm fast, many actors, parallel branches, results blended at the end, are exactly the properties that make its output hard to check after the fact.

Why verification breaks at swarm scale

• The record multiplies. One run is no longer twenty tool calls. It is thousands, spread across agents that started and stopped at different times. No human reads that raw, and no single agent's log covers the whole run.
• Partial failure is the normal case. At swarm scale some worker always times out, errors, or returns nothing. The coordinator merges what arrived and reports the job done. The missing piece leaves no mark in the summary, so a partial result reads exactly like a complete one.
• "Done" gets said a hundred times. Every worker reports success in its own words. Those claims are narration, not evidence, and they blend together at the merge. When the final answer is wrong, the summary cannot attribute the error to the worker that introduced it.
• Substitution is invisible. If one branch's result is swapped, regenerated, or quietly dropped and replaced with a plausible paragraph, nothing in a merged narrative changes shape. The blend hides the edit.

The common thread: a swarm's own account of itself is the only record, and it is written by the system being checked. Verification needs records the swarm cannot rewrite after the fact, one per step, bound together so the set itself can be tested.

The answer: receipts per step, one close over the set

AER-1, an IETF Internet-Draft (draft-zambo-aer1-23), defines a verifiable execution receipt: a record of one tool call whose canonical bytes are committed under a SHA-256 hash at execution time. Applied to a swarm, the pattern has two halves.

1. Every step gets a receipt. Each worker's call is recorded as it happens: the tool, the inputs it received, the output that came back, bound by a commitment anyone can recompute later. The claim stays narrow on purpose: the receipt proves the saved result was not changed since it was saved.
2. The run closes over the whole set. When the run ends, a workflow close produces a summary receipt that lists the step receipts and commits to them as an ordered set. Its Merkle root is built per Section 8.1 of the draft: each leaf is the SHA-256 hash of one step receipt's identifier, taken in order, paired and hashed up to a single root.

That root is what makes a swarm checkable. A verifier recomputes each step receipt's commitments, then rebuilds the root from the step identifiers and compares. A step that was dropped, added, reordered, or substituted produces a different root, so the closed record either matches the work step by step or it visibly does not match at all. The coordinator's summary stops being the evidence. It becomes a claim standing next to evidence anyone can test.

Declaring what did not happen: the negative record

A swarm run has a second kind of truth that summaries bury: the work that never happened. A branch that was planned and never dispatched. A check the coordinator skipped. A worker that never reported back. AER-1 receipts can carry a negative record, a producer-asserted declaration of what was not run and what was not checked.

Across a swarm that declaration does real work. It turns silent partial failure into a stated gap: this source was not read, this branch did not run, this verification was not performed. A reviewer reading the closed run sees the holes listed next to the evidence instead of discovering them later, or never. The negative record is a declaration by the producer, not a proof, and the format keeps it in that lane. It exists because at swarm scale the honest sentence is often "here is what the swarm did, and here is what it did not do."

Check a swarm-grade receipt yourself

• The verifier walkthrough: how to verify an AER-1 receipt runs the checks against a real public receipt, hashes included, so the swarm pattern can be tested on its smallest unit.
• The format: AER-1 is an open IETF Internet-Draft, draft-zambo-aer1-23, a draft and not a finished standard. The conformance kit and test corpus are on GitLab, so any implementation of swarm receipts can be checked against the same vectors.
• See one minted: the one-click demo runs a real call and hands you the receipt, no signup. Every agent in a swarm mints the same object, once per step.
• Keep a swarm run permanently: a Day Pass ($0.99) seals a closed workflow so its page, verify badge, and PDF pack stay put after the free viewing window.