Google I/O's Real Story: The Agent Protocol Stack

Every Google I/O has a visible story and a real story. The visible one involves polished demos where Gemini does something impressive on a big screen. The real one is messier, less photogenic, and considerably more consequential: Google has spent the past year trying to build the plumbing that makes AI agents actually function in the world—and it has six new protocol names to show for it.

Nate B. Jones, who runs the AI News & Strategy Daily channel, broke down all six ahead of today's I/O keynote, and his framing is worth sitting with. The question isn't which protocol is best. The question is which ones have actually become load-bearing infrastructure versus which ones are still in the "ambitious proposal" phase. His read: three of the six are real, three are contested.

Let's start with what "real" means here.

The Three That Are Actually Doing Work

The first is MCP—the Model Context Protocol—which has won the tool-integration layer by solving the most basic agent problem: a model that can only chat is not an agent. It's a very expensive autocomplete. The work lives in GitHub, in Slack, in Salesforce, in your internal Postgres database. Before MCP, connecting an agent to any of those systems meant writing custom glue code every single time—tool definitions, auth patterns, error handling, all from scratch. MCP standardized that handshake. A server exposes what it can do; an agent connects and gets a description it can reason against. There are now over 14,000 MCP servers. That's not a proposal—that's adoption.

The second is A2A (Agent-to-Agent protocol), which handles the coordination layer. No single agent can own every capability; a procurement agent needs a supplier agent, a finance agent needs a tax agent. A2A makes that delegation legible through what Jones calls the "agent card"—a published description of what an agent is, what it can do, which skills it exposes, and how to interact with it. Google launched A2A with more than 50 partner organizations including Atlassian, Box, MongoDB, and Workday. As I've covered looking at A2A vs MCP, these two protocols operate at different layers—one connects agents to tools, the other connects agents to each other—and the distinction matters enormously when you're actually designing a system.

The third is AG-UI, and this is where I think most teams are about to get an uncomfortable education. Jones describes it as "the human control layer," which sounds like UX polish but is actually much heavier than that. Traditional web apps are built for request-response. An agent doing a multi-step task that might take twenty minutes, discover new information mid-process, and touch external payment systems is not a request-response problem. It needs streaming, shared state, approval gates, interruption handling. AG-UI is the protocol candidate for all of that. Jones puts it bluntly: "An agent that can't show its work becomes supervision debt for humans." Teams will skip this layer, ship something, watch it do something unexpected, and then retrofit the oversight they should have built in from the start.

The Security Problem Nobody Wants to Talk About

Here's the thing about MCP that tends to get glossed over in the enthusiasm about 14,000 servers: it was built for a high-trust environment. The protocol's whole value proposition—that agents can invoke tools in arbitrary ways—is also its risk surface. Invariant Labs has already documented what they call "tool poisoning attacks": malicious instructions that hide inside tool descriptions, influencing an agent's behavior through the very metadata that's supposed to make the tool discoverable. The attack vector isn't the agent's reasoning. It's the configuration layer.

Jones is direct about what this means: "Tool access is not a feature toggle even though it's treated that way in a lot of user interfaces. Now it is a security boundary that you're crossing." Scopes, approval flows, audit trails—these aren't optional hardening for paranoid teams. They're the missing half of MCP's security model. There's a deeper look at exactly this problem in MCP's security architecture if your team is already shipping MCP servers.

The A2A protocol has its own version of this problem. Agent cards define what an agent can do and how to interact with it, but they don't yet enforce what the agent can't share, what requires human approval, or how a downstream result gets validated. Jones flags this gap explicitly: the agent card is a first attempt at an operating contract, but "it's still missing a control layer." That's precisely why AG-UI ends up in the core stack—it's the piece that tries to fill that gap.

The Three That Are Still Fighting

A2UI, AP2, and x402 are Google's other three offerings—and Jones is careful not to dismiss them, just to locate them accurately on the adoption curve.

A2UI solves a real problem: if a remote agent sends arbitrary HTML to render in your app, you've essentially opened an XSS attack surface with extra steps. A2UI instead sends structured, declarative UI representations that clients render using trusted components. Smart, correct direction. But it's narrower than what AG-UI is attempting—it handles rendering without establishing a full human control layer. Useful as a component; not yet the substrate most teams will build around.

AP2 is the agentic payments protocol, and it attracted 60-plus collaborators including American Express, Mastercard, PayPal, Coinbase, and Worldpay. The core mechanic is the "mandate"—a cryptographically signed proof of what a user authorized an agent to purchase. The fundamental question AP2 answers: how does any party in an agentic transaction know the agent was actually authorized to spend money? That's not a narrow question. But the payments space is also notoriously fragmented by geography, regulation, and consumer trust, and 60 collaborators in payments doesn't mean consensus—it means everyone wants a seat at a very valuable table.

x402 is Coinbase's play: HTTP-native payment settling for agent-to-agent resource purchases. An agent needs an API call, a data source, a benchmark run—it pays for it directly, no account setup, no subscription negotiation. Cloudflare has adopted it. It's genuinely interesting and genuinely narrow: it's about machine-to-machine micropayments, not commercial trust and user authorization, which is what AP2 is about. These are adjacent problems that need different solutions, and the protocol landscape for payments is only going to get more crowded. Mastercard has agentic tokens. Visa has intelligent commerce. American Express has a developer kit. The financial infrastructure for agents is being built by every financial institution simultaneously, which is either reassuring or a recipe for the kind of fragmentation that makes engineers age prematurely.

What This Means for People Actually Building Things

Jones offers a diagnostic framework worth borrowing: six questions to determine which protocols your agent product actually needs. What tools and data does the agent need? (MCP.) What specialists does it need to delegate to? (A2A.) Where does a human need to approve or interrupt? (AG-UI.) Does the workflow need structured rendered UI? (A2UI.) Does the agent need to authorize transactions? (AP2.) Does it need to autonomously pay for resources? (x402 or equivalent.)

The honest observation underneath all six questions is that most teams right now are, as Jones puts it, "overfocused on model selection and very underspecified on the operating surface around the model." They've picked their LLM. They haven't thought about which tools the agent can or should see. They have a prototype that can call APIs but no interaction model for user approval. They can imagine multiple agents coordinating; they can't enforce or validate it.

The protocol layer is where those gaps either get designed or discovered the hard way.

One thing Jones emphasizes that feels underappreciated: payment protocols in particular encode assumptions about customer geography and behavior. A short-lived authorization token might be a "friendly default" in a US-centric protocol that assumes frequent reauthorization is normal. For a customer in a different market, or simply a user who doesn't want to re-authenticate every thirty minutes, that default becomes friction becomes abandonment. The technical choice is the customer experience choice, and they're not separable.

The Actual Test

The Google I/O demos will be compelling. The question worth holding onto while watching them is the one Jones poses directly: does Google make this feel like a single operating model? Does Gemini Enterprise actually stitch A2A agents, MCP tools, A2UI interfaces, and AP2 payments into something coherent that a builder can work against? Or does today produce another two or three acronyms and the implicit promise that integration is someone else's problem?

The agent stack doesn't need more standards. It needs the existing ones to become genuinely buildable. Those are very different things.

---

Marcus Chen-Ramirez is a senior technology correspondent at Buzzrag.