MCP. A2A. AG-UI. A2UI. UCP. AP2. ACP. x402. And as of this week, Poppy.

If your head spins every time a new agent protocol drops, you're not alone. Even the acronyms collide: "ACP" now means at least two different things depending on who you ask.

Here's the good news. These protocols are not competing with each other. They are layers, like the network stack. Once you see the layers, the whole thing clicks.

This guide gives you the map, what's new as of November 2026, a real end-to-end example, and an honest answer to "which ones do I actually need?"

TL;DR: one question picks the protocol

Ask yourself: what is my agent talking to?

My agent is talking to... Use this In one line
Tools and data MCP Plug the agent into APIs, databases and files
Another agent A2A Hand off work to an agent someone else built
A user's screen AG-UI / A2UI Show the user what the agent is doing, live
A store or business UCP Search, cart, checkout and orders in one standard
A payment AP2 Prove the user really approved the purchase

Keep this table handy. Everything below just adds detail.

The stack at a glance 

+---------------------------------------------------+ | USER AG-UI (live events) / A2UI (UI) | +---------------------------------------------------+ | PAYMENTS AP2 (signed mandates), x402 | +---------------------------------------------------+ | COMMERCE UCP (catalog, cart, checkout) | +---------------------------------------------------+ | AGENTS A2A (agent to agent) | +---------------------------------------------------+ | TOOLS MCP (agent to tools and data) | +---------------------------------------------------+

One agent can use all five layers in a single task. We'll walk through exactly that later.

Layer 1: MCP, the agent's hands

Model Context Protocol (MCP) connects an agent to tools and data: your database, GitHub, Slack, a weather API, anything. Build an MCP server once, and any MCP-compatible agent can use it.

What's new: the current spec is 2026-07-28, and it's the biggest change yet. MCP moved from a stateful, session-based protocol to a stateless request and response protocol.

What that means in practice:

  • No more sessions. The session handshake is gone, so any request can go to any server instance. Great news for anyone running MCP servers behind a load balancer.
  • A new discovery call. Clients can ask a server what it supports before sending other requests.
  • Some features are deprecated. Roots, Sampling and Logging are now deprecated, and Tasks moved out of the core into an official extension.
  • Old transport is on the way out. If your server still uses HTTP+SSE, the spec tells you to migrate to Streamable HTTP.

If you built an MCP server last year, read the changelog before your next upgrade.

Use it when: your agent needs to read or do something in another system.

Layer 2: A2A, agents talking to agents

Agent2Agent (A2A) lets agents built by different teams, vendors or companies work together. Each agent publishes an "Agent Card" describing what it can do, and other agents discover it and delegate tasks.

MCP vs A2A in one line: MCP is for tools you control. A2A is for agents you don't own, which have their own brains and make their own decisions.

What's new:

  • v1.0 shipped on March 12, 2026, the first stable version, with JSON-RPC, gRPC and HTTP+JSON bindings. The v1.0.1 patch followed in May.
  • v1.1 is in the works. A release candidate tagged in late October adds two-way streaming while a task runs.
  • It moved in with MCP. A2A joined MCP in the Agentic AI Foundation (under the Linux Foundation) in August 2026.
  • Big vendors are on board. Microsoft Copilot Studio now lets you expose an agent as a remote MCP server or an A2A agent.

Use it when: you need a specialist agent from another team or company, like a travel policy agent, a fraud check agent or a partner's booking agent.

Layer 3: AG-UI and A2UI, the agent's face

Agents that work silently in the background feel broken to users. These two protocols fix that, and they solve different halves of the problem:

  • AG-UI (Agent-User Interaction Protocol) is the live wire. It streams events from the agent to your app in real time: "searching hotels...", "found 12 options...", "waiting for your approval." It's event-based and runs over HTTP and Server-Sent Events.
  • A2UI is about what to show. The agent describes UI (cards, forms, approval buttons) in a declarative format, and your app renders it with its own components. No arbitrary code from the agent runs in your app.

Simple way to remember it: A2UI describes the screen, AG-UI delivers it live.

There are a few more in this layer worth knowing about:

  • MCP Apps is MCP's own extension for showing UI from tools.
  • Agent Client Protocol connects coding agents to code editors. (Yes, this is one of the two "ACPs.")

Use it when: a human watches the agent work or needs to approve something.

Layer 4 and 5: agentic commerce (the most exciting part)

This is where agents stop just answering questions and start spending money. It's also where trust matters most, so two protocols split the job.

UCP: the shopping standard

Universal Commerce Protocol (UCP) gives agents one standard way to work with any business, from discovery to checkout and after.

Its core capabilities:

  • Catalog: search and browse products
  • Cart: build multi-item carts
  • Identity linking: connect the user's account using OAuth 2.0, without sharing passwords
  • Checkout: taxes, shipping, discounts, the whole messy reality
  • Order: confirmation, tracking and returns through webhooks

What's new: UCP has grown beyond shopping. The spec site now shows three tracks: shopping, lodging and food. Hotel booking and food ordering specs are still drafts, so expect changes.

Who's behind it: the co-developer list reads like a who's who of commerce: Google, Shopify, Etsy, Wayfair, Target, Walmart, Amazon, Microsoft, Meta, Salesforce and Stripe, plus travel players like Booking.com, Expedia Group, Hilton and Marriott, and food players like DoorDash and Uber Eats.

The detail businesses care about: the business stays the Merchant of Record and keeps the customer relationship. The agent doesn't take over the store.

AP2: proof that you said yes

Here's the problem AP2 solves. Every payment system today assumes a human clicked "buy." When an AI agent clicks it, three hard questions appear:

  1. Authorization: did the user really give the agent permission for this purchase?
  2. Authenticity: does the request match what the user actually wanted, or did the agent hallucinate?
  3. Accountability: if something goes wrong, who's responsible?

Agent Payments Protocol (AP2) answers these with mandates: tamper-evident, cryptographically signed records of what the user approved. There are two kinds:

  • Checkout Mandate: the items and purchase details agreed with the merchant. Shared with the merchant.
  • Payment Mandate: the approval to charge a specific payment method. Shared with the payment network and processors, not with everyone.

Each comes in two stages:

  • Open: your rules up front, like "any hotel under $250 a night, using my Visa." This lets the agent act on its own.
  • Closed: your approval for one specific, final purchase.

AP2 supports both human present (you approve in the moment) and human not present (the agent buys within your limits while you sleep).

What's new: AP2 v0.2 was released and donated to the FIDO Alliance, the group behind passkeys. Standardization continues in FIDO's working groups.

Roadmap worth watching: AP2 starts with cards. The roadmap adds e-wallets, push payments like UPI (India) and PIX (Brazil), and digital currencies. That matters for huge markets where cards aren't the main way people pay.

How UCP and AP2 fit together

UCP runs the shopping flow. AP2 secures the payment inside it. UCP has AP2 support built in, along with MCP and A2A support, so these aren't rival standards. They're designed as a set.

Other names you'll hear

  • ACP (Agentic Commerce Protocol): OpenAI and Stripe's commerce standard. Interestingly, Stripe also co-develops UCP. Watch this space.
  • x402: agent payments built on the old HTTP "402 Payment Required" status code, popular for crypto and pay-per-use APIs. The official AP2 samples include x402 flows.

Putting it all together: "Book me a hotel in Chicago"

Let's see every layer in one real task. You tell your assistant:

"Book me a hotel near the conference in Chicago, under $250 a night, for the three nights I'm there."

Here's what happens under the hood:

  1. MCP: the agent reads your calendar through an MCP server and finds your conference dates.
  2. A2A: it asks your company's travel policy agent (built by another team) whether you need approval for this trip.
  3. AP2 (open mandate): you've already signed an open mandate: hotels only, under $250 a night, company card.
  4. UCP: the agent searches hotel catalogs, builds the booking, and runs checkout with the hotel, which stays the Merchant of Record.
  5. A2UI + AG-UI: your screen shows three hotel cards live as the search runs, with a "Book this one" button.
  6. AP2 (closed mandate): you tap the button, and a signed, closed mandate locks in that exact booking and price.
  7. UCP (order): the confirmation and any later changes flow back through order webhooks.

Seven steps, five protocols, zero custom integrations. That's the whole promise of this stack.

Brand new this week: Poppy

On November 13, 2026, Sierra released Personal Agent Protocol 1.0, nicknamed Poppy. It defines how your personal AI agent connects to a business, through its website, its APIs or the business's own agent. It came out of a draft shared in October and developed with Meta.

It's two days old, so treat it as one to watch, not one to build on yet. But it points at where things are going: your agent talking to their agent.

What's still missing (the honest part)

The stack is real, but it isn't finished. Before you bet a product on it, know the gaps:

  • No shared memory standard. No foundation-backed protocol exists for agents to share one memory. Most teams expose memory through an MCP server and hope for the best.
  • No privacy signal. A recent academic audit found that neither MCP nor A2A carries a privacy field. If a user opts out of ad data sharing, that choice can't travel with a delegated task.
  • Identity is still open. "Which agent is this, and who does it work for?" doesn't have one standard answer yet.
  • Commerce and payments are early. Lodging and food specs in UCP are drafts, and AP2 is at v0.2. Build pilots, not your whole checkout.

There's movement here too. The IETF chartered an Agent Communication Protocols working group in October 2026, aiming for a shared base protocol that MCP and A2A could both carry.

Which ones do you actually need?

Start small. Add layers only when you hit a real need.

  1. Start with MCP. Almost every agent needs tools. This is the one to learn first.
  2. Add AG-UI or A2UI when a human watches the agent or needs to approve things.
  3. Add A2A only when you work with agents you don't own. If all your agents live in one codebase, you probably don't need it yet.
  4. Add UCP and AP2 if your agent shops, books or pays. Start with a pilot, and follow the specs closely, because they're moving fast.

Rule of thumb: MCP by default, A2A at the boundary, UCP and AP2 at the checkout.

For Google Cloud developers

Several of these protocols started at Google: A2A, UCP (with Shopify) and AP2, plus A2UI. Google's Agent Development Kit (ADK) works with MCP for tools and A2A for agent collaboration, and AP2's official guide pairs ADK, MCP, A2A and AP2 as one stack. If you already build on ADK, you're closer to this full stack than you think.

The protocols themselves are open and vendor-neutral, so nothing here locks you into one cloud.

Caveats

  • Everything here is as of November 15, 2026. These specs change monthly. Check the official sites before you build.
  • Some items are drafts or previews: A2A v1.1, UCP lodging and food, AP2 v0.2, and Poppy.
  • Adoption numbers vary by source. I've left out partner counts and download stats that I couldn't confirm from official pages.

Sources