MCP and A2A are the plumbing. They’re foundational, general-purpose, and they don’t know what a shopping cart is. They don’t know what a checkout flow requires. And they definitely don’t know what stops an AI agent from spending $31 on eggs without asking first. That gap is now being filled by a new vertical layer — domain-specific protocols built for commerce (UCP) and payments (AP2), announced at the National Retail Federation conference in January 2026, backed by Google, Shopify, Target, Walmart, Etsy, and Wayfair.
The protocol alphabet — ANP, NLIP, A2UI, AG-UI, UCP, AP2 — can look like alphabet soup. This article maps each one by layer and maturity so that commerce and FinTech teams have a working frame for which to watch, which to build against, and what it means for your 2026 agent roadmap. For background on MCP as the foundation layer, see our MCP overview.
What is the difference between horizontal and vertical agent protocols?
Horizontal protocols operate across all domains. MCP standardises how any agent connects to any tool. A2A standardises how any agent delegates tasks to any other agent. Neither knows anything about shopping, payments, or checkout flows. They’re infrastructure, not applications.
Vertical protocols extend those horizontal foundations with domain-specific semantics. UCP adds commerce concepts on top of MCP and A2A bindings. AP2 adds payments governance on top of the same bindings.
Think of it this way: MCP and A2A are the operating system. UCP and AP2 are the domain-specific applications that run on that OS. They inherit transport and coordination primitives and add the business logic that general-purpose protocols deliberately leave out.
Without vertical protocols, every team building an MCP commerce agent has to invent their own shopping semantics. That creates fragmentation that stops agents from working across merchant systems. That’s the coordination problem UCP exists to solve.
To understand how MCP and A2A work at the protocol level, that’s where to start before adopting the vertical layer.
What is the Universal Commerce Protocol (UCP) and how does it extend MCP and A2A?
UCP is an open commerce protocol co-developed by Google and major retailers — Shopify, Etsy, Wayfair, Target, and Walmart — announced at the National Retail Federation event in January 2026. Adyen, Mastercard, Stripe, and Visa are also on board.
What UCP actually does is enable end-to-end agent-led commerce: product discovery, cart management, checkout, and post-purchase — all structured as protocol-level intents rather than retailer-specific API calls.
The MCP binding means UCP exposes merchant capabilities as MCP tools, so any MCP-compatible agent can call UCP-compliant merchants without a custom integration per retailer. The A2A binding handles multi-agent shopping workflows — a discovery agent hands off to a checkout agent, which hands off to a payment agent, all within the UCP frame. A2A’s governance backstory — its transition to Linux Foundation stewardship of A2A under the AAIF — is what gives UCP’s multi-agent layer the same vendor-neutral credibility as MCP itself.
Each UCP-compliant merchant publishes a Capability Manifest at /.well-known/ucp — think of it like robots.txt for agents. Agents fetch this manifest before initiating a transaction, then execute without scraping websites or needing custom API integrations. UCP will soon power checkout on eligible Google product listings in AI Mode, which is the first production deployment at consumer scale.
One emerging implication worth noting: Agent Engine Optimisation (AEO). Just as SEO structures content for search engines, AEO structures product data and UCP Capability Manifests so AI shopping agents can discover and transact without human intermediation. Merchants who don’t publish /.well-known/ucp will be invisible to agent-led commerce flows.
What is AP2 and why do AI agents need payment guardrails separate from MCP permissions?
UCP opens up agent-led commerce flows. AP2 makes sure those flows don’t go off the rails financially.
AP2 (Agent Payments Protocol) is Google’s protocol for delegated financial authority. It’s a tiered mandate system that constrains what an agent may purchase, for how much, and from which merchants. MCP permissions tell an agent which tools it can call — but they don’t know that calling a checkout tool involves spending real money. AP2 fills that gap.
There are three mandate tiers, in order of increasing agent autonomy:
- Cart Mandate: The agent may add items to a cart up to a defined value limit, but the user must sign off before any money moves.
- Intent Mandate: The user pre-authorises checkout initiation. The agent may start checkout but cannot complete payment autonomously.
- Payment Mandate: Full delegated payment authority within defined constraints — value caps, merchant whitelists, category restrictions.
Credential providers occupy the AP2 enforcement layer — financial entities that release a payment token only once the mandate is verified. OnePay (Walmart’s financial-services subsidiary) and Revolut are the two confirmed early AP2 credential providers. It’s a new role in the payments stack, distinct from card issuers and processors, built specifically for agent-delegated payment governance.
AP2 sits above card network tokenisation schemes like Visa VIC and Mastercard MAP — it’s the governance layer specifying authority constraints under which tokenised transactions may be authorised. For most merchants, AP2 compliance will be handled by payment processors at the infrastructure level.
The $31-eggs incident: what it reveals about the limits of horizontal protocol permissions
In early 2026, Washington Post journalist Geoffrey Fowler reported that OpenAI Operator had made an unauthorised $31 Instacart grocery purchase — autonomously completing an order without explicit user approval.
This isn’t primarily an OpenAI story. It’s the canonical demonstration that horizontal protocol permissions are insufficient governance for agents handling financial transactions. MCP tool permissions operate at the level of “this agent may call this tool.” They have no concept of spending limits or tiered authorisation. The OpenAI Operator had MCP-level permission to call shopping tools with nothing constraining that permission to browsing-only or cart-only operations.
AP2’s Cart Mandate tier is the direct architectural response. Under a Cart Mandate, the agent fills the cart — and stops. Payment cannot proceed without explicit user sign-off.
The eggs incident isn’t a bug to patch in a single agent. It’s a category of risk that emerges whenever agents receive general-purpose tool access without domain-specific spending governance. The decision for your team is where to implement guardrails: at the application layer, or at the protocol layer via AP2 and UCP.
How to read the protocol alphabet: ANP, NLIP, A2UI, AG-UI — where each fits
The characterisation of the protocol landscape as “alphabet soup” reflects genuine confusion. These are real protocols at very different maturity levels addressing very different layers. Here’s how they break down:
MCP (Agent-to-tool, production-ready): Connects agents to tools and data sources. The foundation everything else builds on.
A2A (Agent-to-agent, production-ready, 150+ organisations): Multi-agent coordination and task delegation. The base layer for UCP’s multi-agent commerce workflows.
UCP (Commerce vertical, spec-stable, early adoption): End-to-end agent-led commerce flows. Build against it now if your roadmap intersects with the Google ecosystem.
AP2 (Payments vertical, spec-stable, early adoption): Delegated agent payment governance. Same readiness as UCP.
ANP (Agent Network Protocol): Peer-to-peer agent communication using W3C Decentralised Identifiers — aims to be “the HTTP of the Agentic Web era.” More ambitious scope than A2A, significantly less mature. For most commerce teams in 2026, A2A is the relevant inter-agent protocol.
NLIP (Natural Language Interaction Protocol): Introduced by Ecma International for exchanging information between agents using natural language. Useful for legacy API surfaces not built to be agent-native. Early-stage, limited adoption.
A2UI (Agent-to-UI Protocol): Google’s front-end protocol governing how agents surface decisions and confirmations to users. In preview (v0.8) as of early 2026. Relevant for teams building Google-stack agents that need standardised human-in-the-loop confirmation flows.
AG-UI (Agent User Interaction Protocol): CopilotKit‘s complementary front-end protocol, standardising how agents stream messages and state updates to frontend applications. Same problem space as A2UI, framework-agnostic angle. CopilotKit has noted A2UI and AG-UI can be used together.
The maturity summary: MCP and A2A are production-ready. UCP and AP2 are spec-stable with early enterprise adoption — build against them if your commerce or payments roadmap intersects with the Google ecosystem. ANP, NLIP, A2UI, and AG-UI are in active development — worth monitoring, not yet ready for production.
What does the vertical protocol layer mean for commerce and FinTech teams building agents today?
The strategic question for 2026 isn’t “should we implement UCP?” It’s “which protocol platform bet do we make first, given our existing agent runtime and payment infrastructure?”
If your team is building on Google AI Mode or Google ADK: UCP and AP2 are the natural path. Google ADK works natively with MCP servers, so UCP-compliant merchant endpoints can be called from ADK agents without a custom integration layer.
If your team is building on OpenAI (ChatGPT, Operator): ACP (OpenAI/Stripe) is the competing protocol and the more natural path. Same commerce and payments problems, OpenAI-native angle. Already on Stripe? ACP is a faster adoption path.
If your team has its own agent infrastructure: UCP’s open-spec nature — MCP and A2A bindings, not Google-proprietary — means it can be implemented independently of Google’s stack. Evaluate based on the retail partnerships most relevant to your merchant base.
The “agents with credit cards” risk is a compliance and product liability concern regardless of protocol choice. Mandate-based authorisation should be on your 2026 architecture roadmap.
Practical sequencing: (1) verify MCP tooling is in place as the foundation; (2) assess agent runtime dependency — Google vs OpenAI — to determine UCP/AP2 vs ACP; (3) implement mandate-tier spending governance regardless of protocol, as the compliance risk exists at the application layer before protocol-level enforcement is in place; (4) monitor A2UI, AG-UI, and ANP as they mature.
For a comprehensive view of the MCP foundation layer, our MCP overview covers the architecture in depth.
FAQ
Is UCP available to use today, or is it still in development?
UCP was announced at NRF in January 2026 with a published specification and MCP and A2A bindings. Shopify Engineering published an authoritative technical reference at launch. Early adoption is live with the NRF launch partners. Treat the spec as v1.0 — stable enough to build against, but expect evolution as the coalition expands.
Does AP2 replace Stripe’s API for agent payments, or sit on top of it?
AP2 is a governance layer, not a payment rail. It specifies the mandate constraints under which an agent-initiated transaction is authorised, then passes it to existing payment infrastructure. Stripe’s API remains the payment execution layer for OpenAI/Stripe’s ACP stack — AP2 and Stripe serve different protocol ecosystems.
Is A2UI the same as AG-UI?
No. A2UI (Google) governs how an agent surfaces decisions and confirmations to a user. AG-UI (CopilotKit) governs how an agent generates and streams UI components to a frontend client. Both are early-stage and complementary — CopilotKit has explicitly noted they can be used together.
What is the difference between UCP and ACP?
UCP (Google/Shopify coalition) and ACP (OpenAI/Stripe) are competing open commerce protocols. UCP is backed by the Google agent stack and major US retailers. ACP is backed by OpenAI Operator and Stripe. The choice comes down primarily to which agent runtime your product depends on.
What are cart mandates, intent mandates, and payment mandates in AP2?
A Cart Mandate permits an agent to add items to a cart but not proceed to checkout — the user must sign off before payment. An Intent Mandate permits the agent to initiate checkout but not complete payment autonomously. A Payment Mandate grants full delegated payment authority within defined constraints: value caps, merchant whitelists, category restrictions. All tiers are enforced by the credential provider before any transaction reaches the payment rail.
Who are the credential providers in AP2 and what do they do?
Credential providers sit upstream of payment rails and enforce mandate constraints on agent-initiated transactions before they reach card networks. OnePay (Walmart’s financial-services subsidiary) and Revolut are the two confirmed early AP2 credential providers — a new role in the payments stack specifically designed for agent-delegated payment governance.
Can AI agents spend money without my permission under UCP and AP2?
Under a correctly implemented UCP/AP2 stack: no. AP2 mandates require explicit authorisation of each permission tier before an agent can act, with cryptographic mandates providing a tamper-proof record of what the user authorised. The $31 eggs incident occurred on an agent configuration with no equivalent mandate governance in place.
What is Agent Engine Optimisation (AEO) and should merchants care about it?
AEO is the practice of structuring product data and UCP Capability Manifests so AI shopping agents can discover and transact with a merchant without human intermediation. Merchants who publish a /.well-known/ucp manifest become discoverable to UCP-compliant agents. Those who don’t will be invisible to agent-led commerce flows — the SEO analogy is accurate.
Is ANP the same as A2A?
No. A2A is the standardised inter-agent coordination layer — production-ready, supported by 150+ organisations. ANP covers peer-to-peer agent communication using decentralised identifiers — a distinct, significantly less mature specification. For most teams building commerce agents in 2026, A2A is the relevant inter-agent protocol.
Will UCP or ACP become the dominant commerce protocol?
Too early to call. Both specs launched in early 2026. The most likely near-term outcome is platform-specific adoption — Google AI Mode defaults to UCP; ChatGPT defaults to ACP — rather than a single winner, with bridges emerging as both stabilise on shared MCP/A2A primitives.
