Builders need to plan for the 2026 changes to MCP and A2A
Agents reach tools through the Model Context Protocol (MCP) and reach other agents through the Agent2Agent protocol (A2A), and both changed substantially in 2026. The pace is already a problem for the people who build on them, and in the 2026 Connectivity Benchmark, 68% of IT leaders said they find it hard to keep up with emerging agent standards and protocols.1
Where each change lands
MCP standardizes how agents reach tools and data,2 and A2A standardizes how agents collaborate.3 Both are now projects of the Agentic AI Foundation, hosted by the Linux Foundation.2,3 A third protocol, for agent payments, is moving the same way.
| Protocol | What changed in 2026 | Where it lands |
|---|---|---|
| A2A | Version 1.0, the first stable release, arrived in March 2026 with version negotiation, multi-tenancy and signed agent cards that let one agent verify another’s identity3 | Any agent that accepts work from another agent |
| MCP | The July 2026 revision made the protocol stateless, removing sessions and the initialization handshake, and requires headers that name the method and tool on every HTTP request2 | Every MCP server that held session state, and every gateway that reads MCP traffic |
| AP2 | Google contributed its Agent Payments Protocol to the FIDO Alliance in April 2026, where new working groups are developing standards for agent authentication and agent-initiated payments4 | Any agent that can start a payment |
The MCP revision did more than remove state. It documents how OpenTelemetry trace context travels with each call, tightens authorization checks and deprecates several features with a minimum 12-month window.2 That window is the deadline for any tool that still relies on a deprecated feature. Agent payments are at an earlier stage, and until the new standards are settled, AP2 is best treated as pre-standard.
For MCP, statelessness means every request carries what the server needs, and no server keeps a session between calls. A server can then run behind an ordinary load balancer, since no request depends on an earlier one. For A2A, an agent card is the description an agent publishes of itself, and a signature lets another agent check who published it before it trusts the work on offer.
The cost of each change depends on how agent traffic is wired. Where every agent connects to every tool on its own, each team re-implements each change in its own code and on its own schedule, and the slowest team sets the pace for everyone. A control plane absorbs much of that work in one place. Its registry can check signed agent cards before one agent trusts another, and its gateway can apply policy to MCP’s standard headers and join every call to its trace, so a change to the protocol becomes a change to one policy, and the same traces show which tools still call a deprecated feature as the window closes.
What to do next
- Developer. List every MCP server you run, and check which ones still hold session state or leave out the method and tool headers, starting with the servers your production agents call most.
- AI Engineer. Require a signed agent card before an agent accepts work from another agent, and give no privilege to roles an agent asserts about itself.
- Developer and AI Engineer. Track the MCP deprecations against their 12-month window, and keep any payment flow built on AP2 behind a person’s approval while the standards work continues.
Go deeper
Section 4 of The AI Control Plane Handbook places the protocols inside a control plane’s routing, context engineering and delegation. Slide 13 of the executive deck sets the protocols beside context engineering and capability discovery.
Found this useful? Follow me on LinkedIn for the next one.
Working on this? Connect and tell me what you are seeing.
Read the full handbook and the executive deck online.