Agent2Agent (A2A) and MCP: What the Handover Means

What happened

Google announced A2A in April 2025 as an open protocol for agents built by different vendors to discover each other, exchange tasks and return results. In June 2025 it donated the specification to the Linux Foundation, with Microsoft, Amazon, Salesforce and others named as supporters. That is the same move Google made with Kubernetes in 2014: give the interface away under neutral stewardship so that no single vendor owns it and adoption is not a bet on that vendor.

Anthropic's Model Context Protocol went the same way. Published in November 2024, adopted by OpenAI, Google, Microsoft and AWS through 2025, and now stewarded under the Linux Foundation's Agentic AI Foundation, of which Palma is a member. The result is that both halves of the agent stack are open standards nobody owns.

What A2A is, and what MCP is

They are complementary, not competing. A2A is the conversation between agents; MCP is the hands. The analogy the original version of this post reached for, that A2A is "the Kubernetes of AI", was a stretch; if either protocol has become plumbing in the way Kubernetes did, it is MCP, because that is the one every assistant vendor shipped.

What changes for an enterprise

Less than the 2025 coverage suggested, and in a more specific place.

• Vendor risk drops. A system exposed over MCP is reachable from ChatGPT, Claude, Copilot, Gemini and the coding agents alike. You are not choosing a vendor's interface; you are choosing which assistant to put in front of a standard one.
• The integration count changes shape. One MCP server per system, reachable from every assistant, instead of one integration per assistant per system. The arithmetic is in MCP vs API.
• Multi-agent work becomes possible without a single vendor's orchestration. That is what A2A is for. Most enterprises are not there yet, and do not need to be to get value from the first two points.

Which one you have to govern

Neither protocol decides which person may do what. MCP authenticates a client to a server and describes tools; an authorised client sees everything the server exposes to it. A2A describes agents; it does not decide whether the agent on the other end should be trusted with the task. Governance is a layer above both.

For an enterprise, the layer that matters first is the one on MCP, because MCP is where an agent touches a system of record. Whether the request came from a person in a chat window or from another agent over A2A, it becomes a tool call at that point, and that is where the security review asks its questions: who is allowed to use this tool, on which records, with what approval, and with what proof.

That is what Palma governs. Each person, or an agent acting for a person, gets one governed connector, assigned through the groups they already hold in the identity provider, carrying every tool and Skill they are entitled to into whichever assistant they use. Policy is evaluated on the actual arguments of a call; calls that need a human are held for approval; every call is logged with who, what, when and why. Palma does not govern agent-to-agent traffic itself today. Where an A2A-speaking agent reaches an enterprise system, it does so over MCP, and that is the point where the policy applies.

What to do about it

Nothing about A2A yet, unless you are already running agents from more than one vendor that need to hand work to each other. Get MCP governed first: one team, the two or three systems they use, entitlement by identity-provider group, reads open and writes behind approval, an audit trail at the end of the first week. When multi-agent work arrives, it will land on that same governed connector.

If you want to talk through where A2A fits in your own roadmap, book thirty minutes.