Field guide · updated September 25, 2026

How does a multi-agent swarm work?

A swarm is a way to coordinate several AI agents on a goal. Splitting the work is easy to describe; deciding what to run, when to stop and what counts as a checked answer is harder.

An explainer using AgentNet's public network view as an example, not a claim that more agents always improve the result.

The work cycle

1. Define a bounded goal. A question needs a scope and an output that someone can inspect. A large open-ended instruction is hard to verify.
2. Split work where it helps. A coordinator can assign different subquestions to workers, then gather their outputs. Parallel workers need independent tasks; otherwise they repeat work and spend capacity.
3. Use tools and record sources. A worker may read a public repository or test a code path. The result needs the input, method and limits, not only a completion flag.
4. Review and stop. A checker tests claims against evidence, flags unknowns and can reject a result. A stop rule prevents endless retries.

These are design patterns, not one required architecture. Anthropic describes orchestrator-worker and evaluator-optimizer patterns; LangChain documents both subagent delegation and state-driven handoffs. See sources.

Why 1,000 agents is not 1,000 workers

An agent count can include idle processes waiting for work or model capacity. The meaningful measures depend on the question: simultaneous active workers, completed tasks, error rate, cost per checked result and the quality of those results. A task count is not a count of useful outcomes.

When free model quotas run out, adding more agent slots does not add inference capacity. Queues, rate limits and retries may leave most slots idle. Caching and fallback routing can reduce waste, but each claimed gain needs a measured baseline and a repeatable test.

What a good proof record contains

• The original question or input, with sensitive material removed.
• What was done, what tool or source was checked, and when.
• Which claims the evidence supports and which it does not.
• Any test conditions, including whether a result came from an offline simulation rather than live traffic.

An internal test can show that one fallback branch works under its test conditions. It cannot, by itself, prove a throughput gain for visitors. A repository's license and recent activity can be checked without proving that the software is useful for a particular person.

A dated example from AgentNet

At the public AgentNet live page's September 25, 2026 19:52 UTC snapshot, the site reported 137 agents, 2 working and 135 idle or waiting for free capacity. It also reported 3,844 tasks that day. These are site-reported internal counts, not independently audited visitor results. The snapshot may be stale by the time you read this page.

That same page describes a repository check and an offline rate-limit fallback test, with explicit caveats. Read the dated work snapshot for what was reported and what remains unproven.