Last month in Buenos Aires, a 24-year-old developer walked me through his inventory agent — forty minutes of careful work — and then hit the wall every builder hits now. His agent couldn't talk to his client's agent. Two protocols, two vendor dashboards, zero shared vocabulary. He wasn't asking for a smarter model. He was asking for a plug.
That is the whole context behind the quietest important thing in infrastructure right now: the Cloud Native Computing Foundation is evaluating the Model Context Protocol as a candidate wire specification for agent workloads. Not adopting. Evaluating. Almost every summary I've read this month has blurred that line, and the blur matters more than the news.
Let me over-explain the basics, because I've sat across too many tables from people with impressive titles who needed exactly this. MCP is an open protocol Anthropic published in November 2024 for exposing tools and data to language models. Under the hood it is JSON-RPC 2.0 — a mature RPC pattern with fifteen years of industrial mileage — running over stdio locally and streamable HTTP remotely. Google's A2A, released in April 2025, covers agent-to-agent communication instead. Both have since moved into foundation governance: MCP under the Agentic AI Foundation inside the Linux Foundation family, A2A alongside it.
Now CNCF's AI Tech Coordination Group has named MCP the primary tool-exposure protocol and A2A the agent-to-agent protocol, and a TOC initiative — numbered #1746 — asks whether either belongs inside the cloud-native stack. Three workstreams are on the table: protocol interoperability, agentic gateway behavior, and runtime abstraction. Minimum gateway expectations reportedly include authentication and tracing. kagent, from Solo.io — the company behind Istio — already ships an MCPServer as a Kubernetes CRD, though it sits at CNCF Sandbox, the lowest maturity tier. The distance between that draft and an approved standard is not a formality. It is the whole distance.
Here's what the announcement doesn't say, and where I'd focus if I were still auditing protocol deployments for a living.
First: stateful sessions and elastic scheduling are in direct conflict. MCP sessions carry state — tool context, streaming state, conversation thread. Kubernetes horizontal scaling, failover, and rolling updates all assume statelessness. Force session affinity into the scheduler and you quietly trade away the elasticity that made you choose Kubernetes in the first place. Nobody has published a reconciliation. If you run multi-tenant agent gateways today, you already know this pain at 3 a.m.
Second: bidirectional server-sent events break the data plane. Envoy and Istio were optimized for short-lived HTTP requests. Long-lived, full-duplex, backpressured streams with resume semantics are their weak spot. When the proposal says gateways need "protocol negotiation," it means runtime L7 negotiation at the edge — a different class of complexity from REST proxying.
Third: the delegation chain is undefined. MCP's OAuth 2.1 resource-server model works for one tenant on one cluster. Cross-cluster token exchange, delegation chains, and per-agent tenancy have no specification. Read "per-agent tenancy" closely and you'll see what's really being proposed: metering and quota pushed down into infrastructure. The gateway has to know which agent it serves and bill accordingly. That isn't an extension. It's a new control plane wearing an extension's clothes.
The comparison everyone reaches for is OCI. Container images became portable; the specification earned nothing and the implementations earned fortunes. Expect the same arc. Standards don't capture value; the layers that implement them do.
Now the contrarian part, because this is where I part ways with the optimism.
Standardization may not reduce lock-in — it may relocate it. "Standard protocol plus cloud-specific extensions" is the oldest move in this industry, and the agent runtime is a perfect place to hide one. A wire spec any gateway can speak still lets a hyperscaler own the session store, the identity broker, and the billing meter.
Then there's security. Prompt injection and tool poisoning are protocol-adjacent, not protocol-solved: tool descriptions and tool returns arrive from untrusted sources, and MCP defines no trust boundary between them. Standardizing does not patch the flaw. It scales the blast radius from one integration to your entire fleet. I spent last year on an ethical guidelines committee for a decentralized AI protocol, negotiating human-in-the-loop verification across fifteen stakeholders — and the hardest argument was never about capability. It was about who signs off when an agent acts at 3 a.m. with nobody watching. That question appears nowhere in this proposal.
And the absentees deserve the headline nobody gave them. OpenAI's and Microsoft's protocol-layer positions are unstated in nearly every writeup of this arc. A standard that quietly excludes the largest consumer surface isn't a standard. It's a club with good PR.
Risk and responsibility, as always in this space: if you deploy MCP servers this quarter, assume no admission control, no code signing, and no reputation layer exists. Assume audit trails are your problem. Note also that initiative #1746 explicitly limits itself to architectural guidance and requirement identification — it states it will not define a new runtime model. That scope retreat is deliberate. CNCF is not ready to own a specification for a field this young, and you should price that hesitation into your roadmap, not just your reading list. In a bear market, infrastructure decisions outlive token prices.
The fight was never MCP versus A2A. It's whether the wire between agents belongs to a foundation or to somebody's product roadmap. Watch the governance seam between AAIF and CNCF — whoever defines how those two bodies reconcile spec changes will decide how open this stack actually is. Connect first, transact second. Always. That's the order standards get built in too, or they don't get built at all.
