The agentic AI protocol stack has four layers, and each one answers a different question. The Model Context Protocol connects an agent to tools and data. Agent2Agent lets separate agents hand off work. The Universal Commerce Protocol covers shopping and checkout. The Agent Payments Protocol handles authorization and payment.
What each agentic AI protocol actually does
The agentic AI protocols cover four separate jobs: MCP connects an agent to tools and data, A2A lets separate agents delegate work, UCP standardizes agent-driven commerce, and AP2 authorizes payment with signed mandates. Only MCP and A2A are openly governed standards today, and AP2's status has changed since late 2025.
This article started from a video transcript, so every product name and version below was rechecked against the primary source rather than the spoken description. Where the transcript and the current documentation disagree, the documentation decides and the transcript version is dated.
The four layers build on a simple progression. A large language model reasons about text but cannot act. Retrieval-augmented generation gives it facts to look up. An agent adds the ability to plan and call tools. Protocols are what let that agent act outside its own process, on other systems, other agents, and other people's money.
| Protocol | Layer | Question it answers | Announced |
|---|---|---|---|
| MCP | Tools and data | What may the agent read or invoke? | November 2024 |
| A2A | Agent delegation | Which agents may act on the task? | June 2025, Linux Foundation |
| UCP | Commerce | What does the merchant expose? | January 2026 |
| AP2 | Payment | What money may move, and under whose authority? | September 2025 |
MCP connects an agent to tools and data
The Model Context Protocol (MCP) is an open standard from Anthropic that lets an AI application reach external tools, resources and prompts through one interface instead of a custom integration per system. Anthropic announced it in November 2024, and the specification is now maintained at modelcontextprotocol.io under the Linux Foundation umbrella.
The architectural point that survives from the transcript is the reduction of integration count. The transcript calls this the N times M problem: N AI applications, each needing to talk to M enterprise systems such as a CRM, a database or GitHub. Before MCP, every pairing needed its own integration. With MCP, each application implements one MCP client and each tool exposes one MCP server, turning the N times M grid into N plus M pieces.
The specification defines three primitives: tools, resources and prompts. The transcript's USB-C analogy is close enough to be useful. A single connector type replaces a drawer of adapters, though a USB-C cable still has to be plugged into something trustworthy.
The transcript's savings figures are the weakest part of it. It claims 50 to 75% development-time savings and a 98.7% token reduction at Block with no source shown on screen. It also claims customer support teams deflecting up to 50% more tickets. All of these are speaker-reported in the video, are not reproduced in any primary source here, and should be treated as unverified claims rather than benchmark results.
MCP is genuinely open: the specification, schemas and reference SDKs are published publicly. That says nothing about whether any particular MCP server is trustworthy, which is a separate security question the protocol does not answer for you.
A2A handles delegation between independent agents
Agent2Agent (A2A) is an open protocol, originally developed by Google and donated to the Linux Foundation in June 2025, that lets agents built by different vendors discover each other, exchange tasks and return results. Its discovery mechanism is the Agent Card, a JSON document describing an agent's capabilities and endpoint.
The split between MCP and A2A is orientation. MCP wires an agent into tools and data it does not control; A2A wires one agent to another agent that may belong to a different organization. The transcript describes MCP as vertical integration and A2A as horizontal collaboration, which is a fair summary. A2A is supported by the specification published at a2a-protocol.org rather than by a single product.
One correction to the transcript's framing: the Agent Card describes skills, capabilities and connection details, and A2A supports enterprise authentication schemes, but the transcript's description of a card holding a cryptographic public key as its defining feature is not how the specification presents it. Treat the card as a capability and discovery document first.
A2A does not make agents interchangeable. Two agents can speak A2A and still disagree about task semantics, cost or liability. The protocol moves the message; it does not settle who is accountable when a delegated task goes wrong.
UCP, ACP and the messy state of agentic commerce
The Universal Commerce Protocol (UCP) is an open-source, Google-led project, announced in January 2026, that gives merchants a machine-readable manifest so an agent can discover products, build a cart and complete checkout programmatically. Shopify, Etsy, Wayfair and Target were named as launch partners.
A competing approach exists. OpenAI's Agentic Commerce Protocol, which powers checkout inside ChatGPT, was introduced in September 2025 with Stripe co-author. It routes the purchase through the platform rather than the merchant's own storefront, which is why the two are often described as a philosophical split rather than a format war.
The choice between them is a choice about who owns the customer. Under UCP the retailer stays merchant of record and keeps control of pricing and the customer relationship. Under ACP the platform mediates the interaction. The transcript frames this as the reason the industry leans toward UCP, but that is the speaker's read, not a measured market share.
The speculative parts of the transcript need marking as such. The claim that the industry is heavily converging on UCP, the claim that ACP charges a transaction fee, and the 80% cart abandonment statistic have no primary citation behind them. Cart abandonment is real and widely studied, but attaching a precise figure to agentic commerce specifically is not supported here.
If you are choosing, the practical test is where the customer relationship lives. UCP keeps the merchant as record holder; ACP keeps the platform as the interaction surface. Most retailers will be asked to support both rather than pick one.
AP2 and the authorization question for agent payments
The Agent Payments Protocol (AP2) is a Google-initiated extension that wraps a payment in cryptographically signed mandates, so an agent can prove it had permission to spend and prove what it was permitted to buy. Google announced it in September 2025 with more than 60 payments and technology partners.
The mandate model is the useful idea. An intent mandate records the user's authorization up front, and a cart mandate binds that authorization to specific items and prices at checkout. The transcript's example is a user signing an intent mandate allowing up to $1,000 on office supplies for the month, then a cart mandate locking in the exact products and prices once the agent finds them. Card details never reach the model, and the signature chain gives the merchant and the payment network something to verify.
The protocol targets three properties the transcript names explicitly: authorization (proving permission), authenticity (reflecting user intent) and accountability (determining responsibility). A supporting paper on the protocol is available as an arXiv preprint.
The status has moved since launch. As of the current project documentation, AP2 is described as a Google-initiated protocol expected to move to a neutral foundation, with the repository maintained under Google's AP2 GitHub organization. It is not, as some write-ups imply, a finished cross-industry rail backed by every card network.
Watch for overreach here. A signed mandate establishes authorization, not suitability or compliance. Whether an autonomous purchase satisfies your organization's procurement controls, spending limits and audit requirements is still an application decision.
The consumer checkout case is the easy one to picture. The transcript points at harder ones: an agent scaling and paying for cloud servers based on real-time traffic, or a supply chain agent that spots a failing grid component, sources a replacement and pays for it with no human in the loop.
How the four protocols combine in one purchase
A single purchase can exercise all four protocols in order. The transcript's laptop example, where an agent buys hardware under a fixed budget, is a reasonable illustration of the sequence even though every named product is illustrative rather than a live integration.
The sequence looks like this:
- The assistant calls an internal policy tool over MCP to confirm that the purchase is allowed and what the limit is. In the transcript's version, an enterprise GitHub Copilot checks corporate spending policy before anything else happens.
- It delegates research and shipping checks to specialist agents over A2A, then collects the results. The transcript splits this into a market analysis agent comparing reviews and a logistics agent checking shipping times.
- It reads a merchant's UCP manifest to find a qualifying item and build the cart.
- It presents a signed intent and cart mandate under AP2 so the payment can be authorized without exposing card data to the model.
Each step is a separate trust boundary. MCP governs what the agent may read or invoke, A2A governs which agents may act on the task, UCP governs what the merchant exposes, and AP2 governs what money may move. Collapsing them into one claim of a "fully autonomous agent" hides exactly the controls that matter.
Gustavo dev doido, whose coverage of the agentic AI stack follows the same four-part split, has made a similar point: the protocols are complementary layers, and glossing them as one thing loses the reason each exists.
Where the protocols fall short today
None of the four protocols is a complete answer to running an agent in a regulated or high-stakes environment. The specifications define message formats and authorization primitives; they do not provide tenant isolation, audit guarantees, liability allocation or regulatory clearance for your deployment.
Three gaps are worth naming. A2A and UCP both depend on trust in the counterparty's published metadata, which means discovery is only as good as the registry. Payments under AP2 still depend on the underlying card network and acquirer supporting the mandate format. And MCP servers are code you run or connect to, so the security posture of each server is a separate review.
The market forecasts are the easiest claim to over-read. The transcript cites a Morgan Stanley projection of $190 billion to $385 billion in US e-commerce by 2030 from the autonomous protocol stack. That figure comes from the speaker, not from a report linked on screen, and a projection is not a measurement. Treat it as an order of magnitude, not a target.
Build for the current state. Support MCP for tool access, treat A2A as your delegation layer, ask whether your commerce platform exposes UCP or ACP, and treat AP2 as the emerging authorization model to design against rather than a settled one.
FAQ
Is MCP owned by Anthropic? MCP was created and announced by Anthropic November 2024. The specification and reference implementations are openly published, and governance has broadened under the Linux Foundation. Anthropic remains its originator, not its sole arbiter.
What is the difference between MCP and A2A? MCP connects one agent to tools, data and prompts it needs to act. A2A connects one agent to another agent, possibly built by a different vendor, so a task can be delegated and the result returned.
Is AP2 production-ready? Not as a universal rail. Google published AP2 in September 2025 with payment partners, and its documentation describes an expected move to a neutral foundation. Card-network support and acquirer readiness vary, so treat it as a design target.
Does UCP replace OpenAI's ACP? No. UCP is a merchant-centric, Google-led open project, and ACP is OpenAI's platform-mediated checkout protocol. Retailers may need to support both rather than choose one.
Do these protocols make an agent safe to spend money? They make spending traceable and authorized within defined limits. Security, compliance and procurement controls remain the responsibility of the application and the organization deploying the agent.
Turn a video walkthrough into a written reference
The protocol stack above only stays useful if someone keeps it current, and a spoken walkthrough ages faster than a document you can edit. A video that explains four protocols in eight minutes leaves the citations, the ownership questions and the status changes to be filled in afterward.
If you have recorded that kind of explanation, whether it is an interview, a teardown or a conference talk, Skalablog turns the YouTube video into a draft article: paste the URL, transcribe the audio, and generate a structured piece you can correct against primary sources before publishing. That workflow is how a clear transcript becomes a reference page someone can cite.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits