A2A, MCP and the Kubernetes Comparison, 15 Months On

What I wrote

The original post is the one this URL used to serve. Its argument was that Google open-sourcing Kubernetes under neutral stewardship in 2014 turned a vendor fight into an ecosystem, that donating A2A to the Linux Foundation was the same move for agent communication, and that A2A plus MCP would be "table stakes" for enterprise AI vendors within eighteen months. I said the firms that toyed with Kubernetes in 2016 owned the cloud-native wave by 2019, and the same clock had just started.

I was at Replex during the Kubernetes years, so I had reasons for the comparison. I also had a company to promote, and some of the post reads like it. Here is what held up.

Right: neutral governance was the point

The core claim was that the donation removed vendor risk, and that vendor risk was the thing holding enterprise adoption back. That was right, and it turned out to matter more for MCP than for A2A. Anthropic's Model Context Protocol went from one vendor's specification to a standard supported by OpenAI, Google, Microsoft and AWS, and then into the Linux Foundation's Agentic AI Foundation, where Palma is a member. The reason a CIO can now expose a system once and have it reachable from every assistant in the building is that no single vendor owns the interface. That is the Kubernetes lesson, and it applied.

Wrong: which protocol became plumbing

I put A2A and MCP on equal footing. In practice, the protocol enterprises have actually had to govern is MCP, because MCP is where an agent touches a system of record. That is the point at which someone in security asks who is allowed to do this, and that question has to be answered before anything ships. Agent-to-agent traffic sits above that point. Where an A2A-speaking agent reaches a database, it reaches it over MCP, and the governance decision is made there.

Palma does not govern A2A traffic today, and the original post implied we did. What we govern is the connector between a person, or an agent acting for a person, and the tools they are entitled to. That is narrower than "the enterprise AI gateway for standardised protocols", and it is what the security review actually asks about.

Wrong, and worth retracting: "without a human in the loop"

The original post painted a support bot and an engineering bot fixing and documenting a problem between themselves, "without a human in the loop", and called it "standardised AI done right". I would not write that sentence now. The single most useful control in an agent programme is the one that pauses a consequential call, routes it to a person, and records the approval. It is what turns an unapprovable pilot into a production system, and it is the first thing regulators reach for. Autonomy is not the goal. Work getting done, with someone accountable for the step that matters, is.

Right, but for a different reason: standards create the next five problems

I wrote that Kubernetes unified orchestration and then created security, observability, access control and upgrade headaches, and that A2A and MCP would do the same. They did, though again the weight fell on MCP. The problems are exactly the ones I listed, restated for agents:

• Who is allowed to see this tool at all?
• What may they do with it, on which records?
• What happens when the agent tries something risky?
• Where did the data go?
• Can you prove any of that afterwards?

The protocol answers none of them, by design. It authenticates a client to a server and describes tools; it does not decide which person may use which tool, or hold a call for a human. That gap is the whole reason Palma exists, and the 2025 post was right to predict it even if it dressed the answer up as "performance management" and "routing and throttling", which we do not do and which were never the point.

What the window turned out to be for

I told readers they did not need a production rollout in eighteen months but they did need a roadmap. What they actually needed was narrower and more useful: one governed way for the people they already employ to reach the systems they already run, from the assistant they already use. Not a multi-agent architecture. One connector per person, entitlement by the groups they already hold, policy on the actual arguments of a call, approval on the calls that need it, and a log that satisfies an auditor.

Companies that did that in the window are now adding systems and teams to something that works. Companies that spent it on agent-mesh diagrams are, in my experience, still at the review stage. The Kubernetes analogy holds here too: the winners in 2019 were not the ones with the most ambitious architecture in 2016. They were the ones who got one cluster into production with security signed off.

If you are starting now

You have not missed anything. Pick one team, the two or three systems they actually use, and the assistant they already have. Connect the identity provider so entitlement follows existing groups. Set reads open and writes behind approval. Take the audit trail to the security team before you scale. That is the whole roadmap, and it takes about a week to a first governed use case.

If you would like to argue with any of the above, book thirty minutes. I still think the Kubernetes comparison was right; I would just aim it at a different protocol.