Knowledge · Agentic commerce
Commerce conducted by software acting for a buyer — and the eight layers of infrastructure that decide whether it can happen with you. A complete explainer of the protocols, the vocabulary, and the practical readiness test.
Agentic commerce is commerce in which an AI agent — acting on a person's or an organization's behalf — discovers products, evaluates them against stated constraints, and completes a transaction, without a human operating the interface at each step.
The term describes both the behaviour and the infrastructure it requires: machine-verifiable product data, callable commerce capabilities, recognizable agent identity, and cryptographic evidence that a human authorized the spend.
For thirty years, the machine-readable version of a business was a marketing asset. Feeds, structured data and sitemaps existed so that a search engine or marketplace could index a catalog and send a human back to the website, where the actual commerce happened. The machine was a librarian. The human was the buyer.
Agentic commerce inverts that. The machine becomes the buyer — or more precisely, the buyer's delegate. It reads the catalog not to index it but to decide with it, and then it acts. That single change breaks a set of assumptions that most commercial infrastructure quietly depends on: that a human will interpret an ambiguous description, that a session will carry identity, that a browser will render the checkout, and that whoever clicks "buy" is the person whose money it is.
Agentic commerce became a named category between 2025 and 2026 because three things converged.
Models became capable enough to be trusted with multi-step tasks. Comparing options against constraints, holding a goal across many steps, and calling tools reliably are all recent capabilities in production systems. Recommendation was possible earlier; execution was not.
Distribution arrived. Assistant surfaces reached a scale where merchants could see AI-referred demand in their own numbers. That turned an interesting research direction into a channel question with a revenue line attached.
The missing infrastructure became obvious to everyone at once. Every serious attempt to let an agent complete a purchase hit the same four walls: the agent could not verify the product satisfied the constraint, could not get a real total, could not prove it was authorized to spend, and could not be told apart from a scraper at the merchant's edge. Within roughly twelve months, separate parties published protocols for each of those walls.
The term is frequently used loosely. Four adjacent things it is often confused with:
| Concept | What it means | How agentic commerce differs |
|---|---|---|
| Conversational commerce | Buying through a chat interface — a human types instead of clicking, but still decides and confirms each step. | The human states an outcome, not a sequence. The agent decides among options and executes; the human supervises. |
| Headless commerce | Decoupling the storefront from the commerce backend so any front end can be built on it. | A prerequisite, not the thing itself. Headless makes capabilities callable; agentic commerce adds who may call them, on whose authority, and with what evidence. |
| AI visibility / answer optimization | Ensuring AI systems know, describe and recommend your brand accurately. | Concerns whether you are the answer. Agentic commerce concerns whether you can be the purchase. A brand can win the first completely and fail the second. |
| Automated purchasing / EDI | Rules-based reordering and structured document exchange between known trading partners. | Long-established and deterministic, with pre-agreed contracts. Agentic commerce involves counterparties with no prior relationship, judgment under ambiguity, and therefore a need for identity and authorization primitives EDI never required. |
The distinction that matters most commercially is the third one. It is entirely possible — and currently common — for a brand to be well understood and warmly recommended by AI systems while being structurally impossible to buy from. The demand arrives and cannot complete.
Agentic commerce is not one protocol. It is a stack, in which each layer answers a different question and depends on the ones beneath it. The layers were not designed together; they emerged from separate organizations solving separate problems.
| Layer | Question it answers | Standards |
|---|---|---|
| 01 · Product knowledge | What exists, and what is verifiably true about it? | OpenAI Product Feed Spec, Google Merchant product data, Schema.org, GS1 Digital Link, ETIM, ECLASS, Digital Product Passport |
| 02 · Commerce | How can I buy or order it? | UCP, ACP |
| 03 · Agent access | How does an agent reach the merchant's systems? | MCP |
| 04 · Agent collaboration | How do agents delegate to each other across company lines? | A2A |
| 05 · Payment authorization | Did a human actually sanction this spend? | AP2, Verifiable Intent |
| 06 · Machine payment | How does software pay software? | x402 |
| 07 · Agent identity | Who is making this request, and can it be trusted? | Visa Trusted Agent Protocol, Web Bot Auth, RFC 9421 |
| 08 · Interface | What does the buyer see when the agent renders the choice? | A2UI, AG-UI |
A useful simplification is to collapse the eight into three families:
The layers behave as a weakest-link system. Perfect checkout plumbing on top of ambiguous product data produces fast, confident, wrong purchases — which are worse than slow ones, because they arrive at scale and come back as returns.
A short definition of each standard commonly named in agentic commerce discussions.
UCP — Universal Commerce Protocol. Google's open standard spanning discovery through checkout and post-purchase, integrated with surfaces including Search AI Mode and Gemini. Its distinguishing feature is capability discovery: a merchant publishes a profile at a well-known location describing which operations it supports, its endpoints, payment configuration and public signing keys. Its roadmap extends beyond retail into food and lodging. The merchant remains merchant of record.
ACP — Agentic Commerce Protocol. An open standard developed by Stripe, OpenAI and Meta covering agentic checkout, cart and feed, delegated payment, delegated authentication, and orders and webhooks. Centred on the checkout session lifecycle — create, retrieve, update, complete, cancel — with the merchant calculating prices, taxes, inventory and fulfillment and charging through its own PSP.
OpenAI Product Feed Spec. A schema and delivery specification by which merchants supply an authoritative structured catalog — products, variants, price, availability, seller, fulfillment — via file-based feeds or an API. Positioned as the first step of ACP integration, and notable for supporting a Google-compatible path that maps existing Google Product Data columns rather than requiring a rewrite.
GS1 Digital Link. Turns identifiers such as GTIN, GLN, batch or serial number into URIs that resolve to different kinds of digital information about a product — converting a barcode number into an addressable entry point.
ETIM and ECLASS. Classification standards defining classes, properties, values and units for technical products (ETIM) and more broadly for products and services (ECLASS), enabling unambiguous exchange of specification data. Long-established in industrial supply chains, and unexpectedly well suited to agent evaluation.
Digital Product Passport. An EU regulatory instrument creating structured data on materials, origin, sustainability, repairability, safety, compliance and recycling. Not an AI protocol, but likely to become the richest machine-readable product record many European manufacturers publish.
AP2 — Agent Payments Protocol. Built on cryptographic mandates: an intent mandate expressing what the human permitted and within what bounds, a payment mandate binding a specific transaction to that intent, and a receipt as durable evidence. Donated by Google to the FIDO Alliance in April 2026; version 0.2 introduced support for Human Not Present transactions — autonomous payments made on the basis of prior authorization.
Verifiable Intent. A standard being developed by Google and Mastercard for cryptographically recording what a human actually authorized an agent to do; announced as compatible with AP2 and also destined for the FIDO Alliance.
Visa Trusted Agent Protocol. Lets a merchant cryptographically recognize a trusted agent, conveying agent intent, consumer recognition and payment information. Built on HTTP Message Signatures.
Web Bot Auth. Cloudflare's approach to cryptographically signing bot and agent traffic, allowing servers to verify request origin instead of trusting a self-declared user-agent string or an IP range. Built on RFC 9421 (HTTP Message Signatures).
x402. Revives the long-reserved HTTP 402 Payment Required status so software can buy access to a resource — an API call, dataset, inference or tool — without a checkout page, card form or signup flow.
MCP — Model Context Protocol. Standardizes how AI applications access resources, tools and capabilities, defining Host, Client and Server communication over JSON-RPC. Not a commerce protocol: it is the socket that commerce semantics can travel through. UCP has an MCP binding.
A2A — Agent2Agent Protocol. Communication between independent agents, originated at Google and contributed to the Linux Foundation. Agents publish an Agent Card describing identity, skills, capabilities, endpoints and authentication requirements. The basis for agent-to-agent procurement.
A2UI and AG-UI. A2UI describes how an agent transmits the structure of a dynamic interface — product cards, configurators, checkout components. AG-UI standardizes communication between an agent backend and a user-facing application, covering streaming, state, tool calls and interaction.
Protocol names are a poor way to assess readiness, because they change. A more durable test is to ask whether three things are callable services in your architecture, independent of your storefront checkout.
Resolve. Given an identifier, a description, or a set of constraints, can you return the authoritative record for the matching item — with enough structured detail that a constraint can be verified rather than assumed?
Quote. Given a basket, a destination, a customer context and a moment in time, can you return the real total — price, tax, promotion, fulfillment options and dates?
Commit. Given a quote and an authorization, can you create the order, reserve inventory, take payment and emit the events that follow?
Every commerce protocol in this stack is a particular grammar for those three verbs plus a post-purchase loop. If you can serve them cleanly, adopting a protocol is an adapter and a test suite. If you cannot, adopting a protocol is a project — and you will do it more than once.
Search taught a comfortable model of failure: rank lower, see it in a dashboard, act on it. Agentic commerce does not behave that way, and this is the single most important operational fact about it.
When a buyer states a constraint — fits model X, waterproof, under 12 kg, delivered before Friday, compliant with a specific regulation — an agent applies that filter only to products where the answer is machine-checkable. A product whose data cannot confirm the constraint is not ranked lower. It is dropped from consideration, with no impression, no click and no record anywhere in the merchant's analytics.
A second silent failure happens earlier still, at the edge. Bot management that cannot distinguish a customer's assistant from a scraper blocks both — and logs the event as a mitigation rather than a lost sale. The merchant concludes that AI-referred demand is small, when in fact it was refused at the door.
1. How much agent traffic reaches us, and how much of it are we currently challenging or blocking? Ask your CDN or bot-management vendor. Most teams have never looked.
2. Of the ten constraints buyers most often state in our category, how many are machine-checkable in our product data — by category, weighted by revenue?
"It disintermediates the merchant." Both major commerce protocols are explicitly designed to keep the merchant as merchant of record, calculating prices, taxes and inventory and charging through its own PSP. What changes is not ownership of the transaction; it is ownership of the interface.
"We should wait for a standards winner." The layer causing most current damage — product data an agent can verify, and an edge that can recognize an agent — is not contested by anyone. Waiting defers work that is required regardless of outcome.
"Our API means we are ready." An API that requires a session, cannot price for a specific customer, exposes no real delivery dates, and attributes every call to one integration account is not a commerce capability an outsider can operate. Callability, granular authorization and auditability are separate properties from having endpoints.
"This is an ecommerce problem." It spans five functions that rarely meet: merchandising owns product data, digital owns commerce capability, security owns edge policy, payments and legal own authorization, and brand owns how the product is represented when someone else renders it. That fragmentation, more than any technical gap, is why the work stalls.
"Beautiful product pages will carry us." In an agent-mediated comparison, the page may never be seen. What determines selection is whether stated constraints can be verified from structured data. Attribute quality becomes a merchandising asset; art direction does not disappear, but it stops being the deciding factor.
No. An assistant that recommends products and hands the buyer a link is still a recommendation surface — the human completes the purchase. Agentic commerce begins when the agent itself completes the transaction, which requires authorization, identity and commerce capabilities that recommendation does not.
Not necessarily, and choosing early is riskier than staying cheap to adapt. Both are open, extensible, built on ordinary web technology, keep the merchant as merchant of record, and support capability negotiation. Model your commerce operations once internally — resolve, quote, commit — and treat each protocol as a projection of that model.
Yes, and arguably more than to consumer retail. Identity linking for contract pricing, approved supplier lists, technical compatibility checking and compliance filtering are all natural agent tasks. Agent-to-agent procurement — a buyer's agent negotiating with a supplier's agent within bounds their humans set — is the larger and less discussed half of the field.
Authentication answers "who is calling" — the domain of agent identity protocols such as the Trusted Agent Protocol and Web Bot Auth. Authorization answers "what did a human sanction" — the domain of AP2 and Verifiable Intent. A signed request from a recognized operator does not tell you the purchase was permitted, and an intent mandate does not tell you the requester is who they claim. Both are required.
It was designed for regulators, not agents, but many real purchase constraints are compliance constraints. A DPP makes material, sustainability, repairability and conformity data structured and addressable — which is exactly what an agent needs to apply a compliance filter. European manufacturers are being compelled to build agent-readable product data and largely do not yet treat it as a commercial asset.
The two diagnostics that give an answer fastest are your edge traffic breakdown — how much agent traffic you receive and how much you block — and a constraint-verifiability check on your top categories by revenue. Both are cheap, and both tend to produce a surprise.
The trust layers are moving fastest and are the least settled, though the donation of AP2 to the FIDO Alliance and the use of the IETF's RFC 9421 for agent signing are both maturity signals. The product knowledge layer is very settled and under-invested. The pragmatic position is to build the canonical data and callable services now, and treat protocol adoption as an adapter you add when demand justifies it.