Six Competing Agent Protocols Now Have a Clear Architecture

The acronym soup of agent protocols has been a running joke for two years. MCP, A2A, UCP, AP2, A2UI, AG-UI — each solving a real problem, none of them interchangeable. Google's new Developer's Guide to AI Agent Protocols, published March 18 on the Google Developers Blog, is significant not because it invents new standards but because it draws a map. Six protocols, six distinct layers of the stack, all demonstrated working together in a single restaurant supply chain agent built with the Agent Development Kit (ADK).

The guide walks through connecting a bare LLM — one that hallucinates everything — to real inventory databases, remote supplier agents, checkout flows, payment authorization, and streaming dashboards. Each stage of that journey adds a different protocol for a different job.

The protocol layer cake

Here's the architecture Google is sketching out:

MCP (Model Context Protocol) handles tools and data. It's the connection between an agent and everything it can touch — Postgres databases, Notion pages, email providers. MCP servers advertise their capabilities; the agent discovers them automatically. No custom API code per integration. Google's guide uses this to connect the kitchen manager agent to a real PostgreSQL inventory database via the MCP Toolbox for Databases, pull recipes from Notion, and fire emails through Mailgun.

A2A (Agent2Agent Protocol) handles agents talking to other agents. Your kitchen manager can check inventory, but it doesn't know today's salmon price or supplier quality grades. That knowledge lives with different remote agents, potentially built by different teams on different frameworks. A2A's solution: every agent publishes an Agent Card at a well-known URL (/.well-known/agent-card.json) describing what it can do. Adding a new supplier agent means adding a URL, not rewriting integration code.

UCP (Universal Commerce Protocol) handles checkout. Once you know what you want and who sells it, UCP provides a typed checkout request pattern that works across any transport — REST, MCP, A2A, or Embedded Protocols for browser flows. The supplier's catalog and checkout sessions both live at well-known URLs, following the same discovery pattern as A2A Agent Cards.

AP2 (Agent Payments Protocol) handles authorization. UCP places the order; AP2 proves who approved it and provides a non-repudiable audit trail. The guide shows a restaurant owner setting configurable guardrails — approved merchants, spending limits, auto-approval thresholds — and the agent generating a PaymentMandate bound to a specific cart and amount. AP2 is explicitly v0.1 in the guide. The types ship as a separate package, not built into ADK core. This is early-stage infrastructure.

A2UI (Agent-to-User Interface Protocol) handles rendering. When a plain text response isn't enough — an inventory dashboard, an order form, a supplier comparison — A2UI lets the agent compose interfaces from 18 declarative primitives (Card, Column, TextField, Button, etc.). The renderer (Lit, Flutter, Angular) turns the JSON into native UI. The agent sends structure and data separately; update the data, the UI reflects it without resending components.

AG-UI (Agent-User Interaction Protocol) handles streaming. Agents stream text incrementally, call tools mid-response, sometimes pause for human input. AG-UI acts as middleware that translates raw framework events into a standardized SSE stream. Typed events — TEXT_MESSAGE_CONTENT, TOOL_CALL_START, RUN_FINISHED — arrive at the frontend without the client needing to parse ADK-specific output.

Adoption, not announcements

What makes this worth writing about isn't the concepts — the protocol space has been iterating on these ideas for over a year. What's changed is the adoption curve.

MCP crossed 97 million monthly SDK downloads (Python and TypeScript combined) as of early 2026, with 5,800+ servers in public registries. It has native support in Claude Desktop, VS Code, Cursor, Windsurf, Zed, and JetBrains IDEs. The "write once, use everywhere" promise — a Postgres MCP server that works across every major AI client — is materializing. Anthropic created MCP; in December 2025, they donated it to the Linux Foundation's Agentic AI Foundation (AAIF).

A2A has a shorter but faster trajectory. Google created it in April 2025, donated it to the Linux Foundation in June 2025. IBM's Agent Communication Protocol (ACP) merged into A2A in August 2025, bringing enterprise adoption momentum. In December 2025, the Linux Foundation launched the Agentic AI Foundation (AAIF) — co-founded by OpenAI, Anthropic, Google, Microsoft, AWS, and Block — as the permanent home for both A2A and MCP. By February 2026, over 100 enterprises had joined as supporters.

The AAIF is the key structural fact. This isn't Google writing specs in a vacuum. It's the major labs and cloud providers collectively backing a neutral home for protocol governance.

The security surface

The guide doesn't dwell on this, but combining agent discovery, autonomous transactions, and payment mandates in a single workflow creates a non-trivial attack surface. Security analyses from researchers at Blueinfy have flagged architectural tensions in non-MCP agent protocols around authentication and capability negotiation between agents operating across organizational boundaries. When an agent can discover a remote agent via Agent Card, query it, place an order, and execute a payment — all without human review for orders under a configured threshold — the authorization boundaries matter enormously. AP2's typed mandates and guardrails are designed to address this, but AP2 is v0.1. The threat model for multi-agent production systems is still being written.

What Google is actually doing

The guide is a marketing document for ADK, Google's agent development framework. But the signal underneath it is real: Google is positioning ADK as the neutral playground where all six protocol layers work together, regardless of which company originated which standard. MCP came from Anthropic. A2A came from Google. UCP and AP2 are from different maintainers. A2UI and AG-UI come from external communities.

Google's bet isn't that its protocol wins. It's that its tooling becomes the path of least resistance for anyone who wants to use whichever protocol actually wins — or all of them simultaneously. ADK's first-class support for MCP via McpToolset and its RemoteA2aAgent routing are concrete examples of this. The guide demonstrates mixing all six in a single agent; that's the product pitch.

The honest uncertainty

Six protocols in a single developer guide is also a warning sign. The fragmentation itself is a cost — tooling that only works with one format, registries that can't talk to each other, teams needing to reason about six specifications instead of two. Thomas Scola wrote recently on Medium that A2A's Agent Card, ACP's Agent Manifest, and related agent description formats need to converge on a common schema core. He's right that the differences are smaller than they appear and the cost of fragmentation is large.

AP2 being v0.1 is worth noting clearly. Google's guide shows it in a full production flow — intent mandate, payment mandate, receipt — but the types ship as a separate package. Teams evaluating this stack for real commerce workflows should treat AP2 as experimental.

The protocol layer for agent interoperability is real and moving fast. The AAIF provides a governance structure that didn't exist six months ago. The adoption numbers on MCP are material. The security questions are live. Whether the layer cake holds together in production enterprise deployments — where discovery, commerce, and payments cross organizational boundaries — is the open question the guide doesn't answer.

That's the right place to leave it. The plumbing is being built. Whether it holds under pressure is what matters next.