The Agentic
Commerce Stack

For twenty-five years, the machine-readable version of a business was a marketing asset. It existed so that a search engine, a marketplace, or a comparison site could index it and send a human back to the website, where the actual commerce happened.

That assumption is quietly breaking. When the visitor is an agent acting for a buyer, the website is no longer the destination. It is one possible, and frankly rather awkward, interface among several. The agent does not want to look at your hero image. It wants to know what you sell, whether it is in stock, what it costs delivered to a specific address by a specific date, whether the item satisfies a constraint it was given, whether it is permitted to spend the money, and how to prove afterwards that it did what it was told.

Each of those questions is becoming a protocol. Not one protocol — a stack of them, being built in parallel by companies that do not entirely agree with each other, at a pace that makes the term "emerging standard" feel generous.

This guide maps that stack. It is a sister volume to The Agent-Operable Enterprise, which asked whether your internal workflows can be operated by an agent. This one asks the outward-facing version of the same question: can your commercial surface be operated by someone else's agent, safely, and on terms you control?

auxfirst calls the wider discipline Agentic Experience Design. Most of that practice concerns the relationship between a person and a system that remembers, adapts and acts. Commerce is where that relationship acquires a price tag — and where the trust problems stop being philosophical and start being chargebacks.

A maintenance manager at a food processing plant in Poznań has a problem. A conveyor drive on line three is failing, the replacement is on eight weeks' lead time, and she has been asked to find an alternative. She types one sentence into an assistant.

This is not an exotic request. It is a Tuesday. A competent human buyer would spend two days on it, and every step of those two days is an act of translation between systems that were never designed to talk to each other.

Now watch an agent try. The sentence contains six constraints, and each one lands on a different layer of infrastructure:

Suppose the agent solves all six. It has found the part. Now the interesting problems begin.

It needs to place an order. That means it must know not just what you sell, but what it is allowed to do with your systems: whether a cart exists, whether shipping can be calculated before commitment, whether a quote is required for this account. It needs to prove that the human authorized a purchase of this kind, at this value, in this category — because "find me a battery" and "buy me a battery" are separated by an authorization boundary that no amount of model capability can cross on its own. It needs to be recognizable to your fraud systems as a legitimate buying agent rather than a scraper. And afterwards, someone in procurement will ask for evidence that the machine did what the human asked. Not a chat transcript. Evidence.

Every one of those problems is now a protocol

That is the fact this guide exists to communicate. Between 2025 and 2026, the questions above stopped being architecture problems for individual companies and started being standards problems for the industry. Google published a commerce protocol. OpenAI, Stripe and Meta published a different one. Google donated its payment authorization protocol to a standards body. Visa published an agent identity protocol. Cloudflare pushed cryptographic bot signing into IETF-track work. Coinbase revived an HTTP status code that had been reserved and unused since 1997. The European Commission started building a registry of product passports.

None of these were coordinated. All of them are attempts to answer one part of the same question: what does a business have to expose for an autonomous buyer to transact with it safely?

Why this is not just another integration project

It is tempting to file this under "integrations" and give it to whoever owns the product feed. That underestimates it in three specific ways.

First, the surface is different. A feed is a description. A protocol is a set of promises about behavior. When you publish a capability document saying you support cart operations and shipping calculation, you are not describing your catalog — you are advertising an operational contract that an unfamiliar agent will attempt to execute against, at three in the morning, with no human present, and possibly at volume.

Second, the failure modes are different. A broken feed loses you impressions. A broken capability contract creates an abandoned cart at best, and a stuck order, an incorrect charge, or an unauthorized commitment at worst. The blast radius has moved from marketing to finance.

Third, the accountability is different. When an agent buys the wrong item, the question "who decided this?" has a genuinely new answer — one that involves the buyer's intent, the agent's interpretation, your capability description, and the payment credential that was presented. The protocols in the authorization and identity layers exist precisely because that question was unanswerable, and unanswerable questions eventually become someone's liability.

The three audiences for this guide

What follows is not a prediction about which protocol wins. Predictions age badly and this field moves in weeks. It is a map of the questions, an account of who is answering each one and how, and an argument about the architecture that remains sensible whichever way the contest resolves.

The single most common mistake in this field is treating the protocols as competitors when most of them are neighbours. UCP is not an alternative to MCP. AP2 is not an alternative to x402. A product feed is not an alternative to anything. They occupy different layers and answer different questions.

Here is the map, with the question each layer exists to answer:

Read it as one transaction, not eight products

The layers are easier to hold in mind if you follow a single purchase through them. Take a straightforward consumer case: a person tells an assistant to reorder the running shoes they bought last year, in the same size, if they are under £140 delivered by Friday.

Notice what is not in that sequence: a page view. There is no landing page, no product detail page, no cart page, no checkout funnel. Every classic conversion surface has been replaced by a structured exchange. Notice also that seven of the eight steps depend on something you publish or expose. Only the model's reasoning belongs to the agent vendor.

The dependency order matters

Layers are not independent. Investment in a higher layer is capped by the layer below it, in a way that will be familiar to anyone who has read the operability argument in the companion guide.

Concretely:

• Commerce depends on knowledge. A capability document advertising cart and checkout is useless if the agent cannot determine which variant satisfies the buyer's constraint. It will either not buy, or buy wrongly.
• Authorization depends on commerce. A mandate that says "up to €200 of office supplies" can only be evaluated if the transaction carries a category, a total and a merchant identity in structured form.
• Payment depends on authorization. Anyone can present a card number. The question that determines liability is whether a human authorized this specific class of spend, and that is a different layer entirely.
• Everything depends on identity. If you cannot tell a buying agent from a scraper, your only safe posture is to block both — which is the position a great many merchants are in today, and the reason so much agent traffic currently fails at the edge rather than at the checkout.

Three families, not thirteen problems

If eight layers is still too many to hold, collapse them into three families. Every protocol in this guide belongs to one of them.

The rest of this guide walks the layers in a deliberate order: knowledge first because it is the foundation and the part you already partly own; commerce second because it is where the standards contest is loudest; then trust, because it is where the hard problems live and where most organizations have done nothing at all.

There is a strong instinct to treat agentic commerce as unprecedented. It is not. The industry has already run one full cycle of "make your products machine-readable or become invisible," and the results are instructive — not least because the infrastructure built in that cycle is still load-bearing.

The first machine-readable commerce layer

Between roughly 1999 and 2015, three separate movements taught commerce to describe itself to software.

1 · Marketplace and search feeds

Google's product data specification is the archetype: a defined set of attributes — identifier, title, description, GTIN, brand, variant attributes, price, availability and dozens more — submitted on a schedule so that a search engine could build a shopping index without crawling every product page.²⁶ Amazon, eBay, Idealo, Ceneo, Kelkoo and every affiliate network ran variations on the same idea. A generation of ecommerce managers learned that the feed, not the website, was what actually determined visibility.

2 · On-page structured data

Schema.org took the opposite approach: rather than shipping a separate file, publish the machine-readable version inside the page itself. Its Product and Offer types are considerably richer than most implementations use — covering SKU and GTIN identifiers, material, measurements, price and price validity, seller, shipping details and return policy.²⁷ Most merchants implement about a tenth of it, which is worth remembering when someone claims their site is "already structured."

3 · Global identity and industrial classification

Underneath both sits the identity layer that makes cross-system reconciliation possible at all. GS1 maintains the GTIN and related identifiers, and its Digital Link standard turns those identifiers into URIs that can resolve to different kinds of digital information about the product.²⁸ That last part is easy to skim past and important: it converts a barcode number into an addressable entry point.

In technical and industrial sectors, classification went much further than retail ever needed. ETIM is an international classification standard for technical products, defining classes, properties, values and units so that product data can be exchanged unambiguously between manufacturers, wholesalers and specifiers.²⁹ ECLASS does something comparable across a broader range of products and services, positioning itself explicitly as a machine-readable reference data standard.³⁰ And to move catalogs built on those classifications, the sector has used BMEcat — an XML standard for exchanging multimedia product catalogs — for well over two decades.³¹

The topology is nearly identical. What changed is the consumer at the end of the chain, and what that consumer is permitted to do once it has read the data. The old chain ended in an index. The new one ends in an actor.

Four lessons that transfer

Lesson 1 · The feed becomes the product

In the marketplace era, merchants who treated the feed as an export job lost to merchants who treated it as a product with an owner, a quality bar and a release process. Titles were rewritten for the feed. Attributes were completed because a missing gtin suppressed the listing. The website and the feed diverged, and the feed won on revenue.

The same dynamic is arriving, with a harsher grading curve. A search index tolerates a vague description because a human will make the final judgment on the product page. An agent making a comparison against six constraints has no such fallback. Ambiguity is not penalized with a lower ranking; it is penalized with exclusion, because the agent cannot verify that your item satisfies the constraint.

Lesson 2 · Whoever owns the identifier owns the reconciliation

Every organization that has tried to merge two product catalogs knows this pain. The manufacturer calls it one thing, the distributor another, the ERP a third, the webshop a fourth. Without a shared identifier, matching is fuzzy, expensive and permanently slightly wrong.

Agents multiply this. When an agent is comparing your item against three competitors and a marketplace listing of your own product sold by someone else, identity collisions produce visible errors: duplicate recommendations, wrong compatibility claims, price comparisons between different variants. GTIN discipline stops being a compliance chore and becomes a precondition for being compared correctly.

Lesson 3 · Classification beats prose for anything technical

Retail got away with unstructured description because purchase decisions were largely aesthetic and low-stakes. Industrial sectors could not, which is why ETIM and ECLASS exist. An agent evaluating technical compatibility behaves much more like an industrial buyer than a fashion shopper: it wants properties, values and units, not adjectives.

This is the single most under-appreciated point in the whole field. Brands with mature classification data — building materials, electrical, industrial, automotive parts, medical devices — are far closer to agent-readiness than their digital maturity scores suggest. Brands with beautiful websites and thin attribute data are further away than they think.

Lesson 4 · Standards proliferate, then adapters win

The XML era did not resolve into one format. It resolved into a canonical internal catalog plus a shelf of adapters — one per marketplace, per region, per partner. Companies that built that architecture added channels cheaply. Companies that maintained a separate hand-tuned export per channel spent the next decade paying for it.

We will return to this in Chapter 13, because it is the central architectural recommendation of this guide, and the evidence that the same resolution is arriving is already visible in the specifications themselves.

Of everything in this stack, the OpenAI Product Feed Spec is the piece that will feel most familiar. It is the closest direct descendant of the classic XML product feed — and the clearest signal of how the knowledge layer is going to work.

What it actually is

The merchant supplies OpenAI with a structured catalog that ChatGPT can ingest and index, so that it knows current products, prices, availability and seller information. OpenAI provides for both file-based feeds and an API for managing feeds, products and promotions.¹

The distinction that matters is the direction of the arrow. This is not:

It is:

That difference has consequences. A crawl produces an inference about your catalog; a feed produces an assertion. When the two disagree — and they will, because a rendered page and a pricing system are rarely in perfect sync — the feed is what the platform treats as authoritative. You have moved from being interpreted to being quoted.

OpenAI positions the Product Feed explicitly as the first step of integrating with the Agentic Commerce Protocol.² That framing is worth holding on to: the catalog is not a marketing artifact in this model, it is the on-ramp to a transaction interface. Chapter 5 covers the other end.

What goes in it

The significant data types include product and variant identifiers, title and description, URL, media, price, availability, seller, fulfillment, and additional data that can improve relevance and trust. OpenAI recommends refreshing data regularly; the current flow describes snapshots and updates through the API.³

Read that list again with a merchandiser's eye rather than an engineer's. It contains a quiet instruction: additional data that can improve relevance and trust. The feed is not a fixed compliance checklist where more attributes are politely ignored. It is a competitive surface where completeness affects whether your product is selected.

// illustrative shape of a feed record — not a spec extract
{
  "id":            "SKU-44821-BLK-42",
  "item_group_id":  "SKU-44821",
  "gtin":          "5901234123457",
  "title":         "Trail Runner GTX — Men's, Black, EU 42",
  "description":   "Waterproof trail running shoe, 8 mm drop...",
  "link":          "https://example.com/p/trail-runner-gtx?v=blk-42",
  "image_link":    "https://cdn.example.com/44821/blk-1200.jpg",
  "price":         { "amount": 13900, "currency": "GBP" },
  "availability":  "in_stock",
  "seller":        { "name": "Example Outdoor", "url": "..." },
  "fulfillment":   { "ships_to": ["GB","IE"], "handling_days": 1 },
  // the discretionary part — where relevance is won
  "attributes": {
    "waterproof_membrane": "GORE-TEX",
    "heel_toe_drop_mm":    8,
    "outsole_compound":    "Vibram Megagrip",
    "weight_g":            310,
    "intended_terrain":    ["trail","mixed"]
  },
  "returns":       { "window_days": 60, "condition": "unworn" }
}

The detail that changes the strategic picture

Here is the development that matters more than any individual field. OpenAI has also begun supporting Google-compatible product feeds. Where a feed qualifies for that path, existing Google Product Data columns can be mapped into the OpenAI model without rewriting them.⁴

The temptation, watching this field, is to assume a future that looks like this:

That would be a miserable future, and the Google-compatibility path is evidence against it. What it suggests instead is:

This is the same resolution the XML era reached, arriving faster because the participants have all lived through the previous cycle. It does not guarantee convergence — but it does mean that the correct architectural bet is not "pick a winner." It is "own a canonical layer good enough to feed several." Chapter 13 develops this into an operating architecture.

Feed quality is now a merchandising decision

An underrated consequence: in an agent-mediated purchase, your attribute data is your merchandising. The photograph does not persuade. The copy does not persuade. What determines selection is whether the agent can verify that your item satisfies the buyer's stated constraints — and it can only verify what is asserted in a form it can compare.

Consider two listings for the same physical product:

Merchant A is not being outranked. Merchant A is being excluded, silently, with no impression data to explain it. This is a materially different failure mode from search, and it is the reason feed completeness deserves a budget line rather than a backlog ticket.

Freshness becomes a trust signal

Because the platform treats your feed as authoritative, staleness is not a quality problem — it is a breach. An agent that promises a price and finds a different one at checkout has failed its user, and the platform that recommended you has failed its user. OpenAI's guidance on regular refresh and API-based updates³ should be read as the beginning of an expectation, not a preference. Plan for near-real-time price and availability, particularly if you run promotions, dynamic pricing or thin inventory.

If the product feed tells an agent what you sell, the Universal Commerce Protocol tells it what it can do about it. That is a much bigger surface, and a much bigger commitment.

What it is

Google describes UCP as an open standard for agentic commerce covering the journey from discovery through checkout and into post-purchase. It currently integrates with surfaces including Google Search AI Mode and Gemini, and the merchant remains Merchant of Record, retaining the customer relationship.⁵

That last clause deserves emphasis, because it is the commercial question every merchant asks first and every protocol document answers in a subordinate clause. The design intent is not disintermediation. You keep the order, the customer data, the payment relationship and the liability. What you give up is control of the interface.

The simplest way to hold the distinction:

The capability set

The current model already covers capabilities spanning catalog search and lookup, cart, identity linking, checkout and order management.⁶

Read as a list, that looks like an API surface. Read as a sequence, it is the entire commercial relationship, unbundled into operations that a stranger's software can perform:

Capability discovery: the genuinely new idea

UCP is not simply a JSON format. It includes a mechanism for capability discovery. A merchant publishes a profile at a well-known location:

/.well-known/ucp

and that document describes, among other things, protocol version, services, capabilities, endpoints, payment configuration and public signing keys.⁷

The consequence is that an agent can ask a question no crawler has ever been able to ask:

— and receive a machine-readable answer before attempting anything. It can then choose an operation it knows is supported, rather than probing, guessing or scraping.

// illustrative sketch of what a capability profile expresses
{
  "protocol_version": "...",
  "merchant": { "name": "Example Outdoor", "id": "..." },
  "services": [
    { "name": "catalog",  "endpoint": "https://api.example.com/ucp/catalog" },
    { "name": "cart",     "endpoint": "https://api.example.com/ucp/cart" },
    { "name": "checkout", "endpoint": "https://api.example.com/ucp/checkout" },
    { "name": "orders",   "endpoint": "https://api.example.com/ucp/orders" }
  ],
  "capabilities": [
    "catalog.search", "catalog.lookup",
    "cart.create", "cart.update",
    "checkout.create", "checkout.complete",
    "orders.get", "orders.cancel"
  ],
  "payment": { /* accepted methods and handler configuration */ },
  "keys":    { /* public signing keys for verification */ }
}

This is a bigger conceptual shift than it looks. For thirty years the unit of web presence has been the page. A capability profile makes the unit of web presence the advertised operation.

And it changes what "being online" means organizationally. A page is a marketing asset; if it is wrong, someone edits it. An advertised capability is an operational promise; if it is wrong, an unfamiliar system fails in production while nobody is watching. Capability documents need owners, versioning, deprecation policy, monitoring and an on-call path — the disciplines of an API programme, applied to a surface that marketing has historically owned.

UCP may be much larger than retail

This is the part most commentary misses. Google is explicit about extending UCP beyond classic shopping. The roadmap already includes food and lodging, with further development of loyalty, member benefits, cross-sell and upsell, and broader post-purchase flows.⁸

Once you allow that, the shape of the thing changes. It stops looking like an ecommerce API and starts looking like a general transaction grammar:

Three different industries, three different back offices, one interaction pattern: discover a set of options, constrain them, assemble a commitment, authorize it, and manage it afterwards. If that pattern holds across food and lodging, there is little reason it stops there. Ticketing, rental, professional services with standard rate cards, B2B reordering against a contract, subscription changes, insurance renewal — all of them are the same shape.

What it means for you

Three practical implications, in order of how soon they bite.

Your commerce platform choice becomes a protocol choice. Most merchants will not implement UCP directly; they will wait for their platform to support it. That makes "what is your agentic commerce roadmap" a renewal question, not a curiosity. Chapter 14 supplies the list.

Contract and account-specific commerce is where B2B gets interesting. Identity linking is the capability that turns this from a consumer story into a B2B one. Negotiated pricing, credit terms, approved supplier lists, punchout catalogs — all of that presupposes the agent can establish which customer it is buying for. That is also where the authorization questions in Chapter 7 become urgent.

Post-purchase is the underestimated half. Order management, modification and returns are not glamorous, but an agent that can buy and cannot check status or cancel is an agent that generates support tickets. If you expose only the buying half of the loop, you have moved cost, not removed it.

The nearest direct counterpart to UCP is the Agentic Commerce Protocol. It comes from a different corner of the industry and takes a noticeably more checkout-centric approach — which tells you something about where its authors' problems live.

What it is

According to Stripe's current documentation, ACP is an open standard developed by Stripe, OpenAI and Meta. Its scope covers agentic checkout, cart and feed, delegated payment, delegated authentication, and orders and webhooks.

Where UCP starts from "how does an agent understand what this merchant can do," ACP starts from "how does an agent complete a purchase without the merchant losing control of the transaction." Both end up covering similar ground; the emphasis differs, and the emphasis reveals the design centre. UCP's centre of gravity is discovery and capability; ACP's is the checkout session and the payment credential.

The flow

Crucially, the merchant still calculates prices, taxes, inventory and fulfillment, and processes the payment through its own PSP. ACP currently defines REST endpoints for the checkout session — create, retrieve, update, complete and cancel.⁹

That division of labour is the entire commercial argument. The agent orchestrates; the merchant computes and charges. Nothing about the protocol requires you to hand over pricing logic, tax determination, promotion rules, fraud scoring or the payment relationship. The agent is a very capable remote control, not a new intermediary in your P&L.

The checkout session as a state machine

The most useful way to think about ACP is not as endpoints but as a lifecycle. A checkout session is a shared object that both sides mutate until it is either completed or abandoned:

// illustrative — the shape of the state, not the spec

create    → session opens; items proposed; merchant returns
              authoritative line items, totals, and what is still needed

update    → buyer address supplied
              merchant recalculates tax, returns real shipping options
              agent selects one; totals change again

update    → buyer information supplied
              merchant validates, flags anything missing

complete  → payment credential presented
              merchant charges through its own PSP, commits inventory,
              creates the order, returns confirmation

cancel    → session released; any soft-held inventory returned

Notice how much of that is merchant computation returning ground truth. Every step where the agent could plausibly guess — what shipping costs, what tax applies, whether the promotion stacks, whether the item is really available — is a step where the protocol forces a round trip to you. This is deliberate and it is protective. An agent that guesses at totals produces disputes; an agent that must ask produces accurate expectations.

Delegated payment and delegated authentication

These two capabilities in ACP's scope are where the protocol touches the trust layers covered later in this guide. "Delegated payment" is the mechanism by which a payment credential reaches the merchant without the agent handling raw card details in a way that would horrify a risk officer. "Delegated authentication" concerns proving the buyer is who the agent says they are, without a browser redirect and a password field.

Neither of these fully answers the authorization question — did the human sanction this specific spend? — which is why AP2 and Verifiable Intent exist as a separate layer. Chapter 7 takes that up.

Orders and webhooks

The presence of orders and webhooks in scope is a small detail with large operational consequences. It means the post-purchase relationship is expected to be event-driven: the merchant notifies rather than the agent polls. If your order management system cannot emit reliable events — shipped, delayed, partially fulfilled, refunded — you will discover that gap here rather than in a roadmap meeting.

Capability negotiation

ACP is also developing a mechanism for negotiating capabilities between the agent and the seller.¹⁰ This matters for the comparison in the next chapter: both protocols have concluded, independently, that a fixed uniform contract across all merchants is unworkable. Some merchants can hold inventory during a session and some cannot. Some support partial shipment; some support guest checkout; some require account linking for pricing. Negotiation is how a protocol survives contact with the actual diversity of commerce.

A worked comparison of the same purchase

To make the two protocols concrete, here is the same shoe purchase from Chapter 1, viewed through each lens.

The strong impression from that table is not difference. It is convergence with different starting points — which is exactly the argument of the next chapter.

Two ecosystems, two protocols, one obvious headline: format war. The headline is probably wrong, and acting on it is expensive. Here is a more careful reading.

The line-up

What they already agree on

Before cataloguing the differences, it is worth being precise about the shared ground, because it is unusually large for a contested space. Both are:

• Open — published specifications rather than proprietary partner integrations.
• Extensible — designed to grow rather than freeze.
• Built on ordinary web technology — HTTP, JSON, REST-shaped operations, well-understood auth primitives.
• Merchant-of-record preserving — the merchant keeps the customer relationship, the money and the obligations.
• Capability-negotiating — both have concluded that merchants differ and the protocol must adapt.^7,10
• Payment-handler separated — payment is a distinct concern with its own configuration rather than being welded into the commerce flow.
• Non-invasive by design — neither requires rewriting the commerce backend; both aim to sit in front of what exists.

That is a remarkable amount of agreement. It suggests the participants share a diagnosis even where they differ on the cure.

Where they actually differ

The differences are real, but they are differences of centre of gravity rather than of worldview.

The transport point in row three is the most strategically interesting. UCP is consciously positioned as an interoperability layer rather than a single wire format — able to travel over MCP or A2A, and declaring compatibility with MCP, A2A and AP2.⁵ That is a different kind of bet from "here are our endpoints." It is a bet that the commerce semantics outlive whatever transport is fashionable.

Why this is not obviously a war

Three reasons to resist the format-war framing.

The scopes only partially overlap. A protocol that describes how to discover a merchant's capabilities and a protocol that describes a checkout session lifecycle are not mutually exclusive statements about the world. Nothing in principle prevents a merchant from advertising capabilities one way and running sessions another.

The hard parts are being solved elsewhere. Payment authorization, agent identity and machine payment — the three genuinely unsolved problems — are being addressed in separate layers by separate parties, several of which are heading toward neutral governance. Whichever commerce protocol you use, you will be leaning on the same trust primitives.

Merchants will not tolerate exclusivity. The lesson of every previous channel expansion is that merchants publish to whoever brings demand. A merchant with meaningful volume from two ecosystems will support two ecosystems, and will demand that their platform vendor absorb the difference. The economics of the buy side generally beat the preferences of the standards side.

How to hedge without building twice

The practical question is not which to pick. It is how to stay cheap to adapt. Four moves, in order of value.

1 · Separate semantics from serialization

Model your commerce operations once, internally, in terms that are true regardless of protocol: find items, price a basket, quote fulfillment, reserve, authorize, capture, create order, notify, modify, refund. Every protocol in this space is a projection of some subset of those. If your internal model is protocol-shaped, every new protocol is a migration; if it is domain-shaped, every new protocol is an adapter.

2 · Make ground truth callable

The recurring demand in both protocols is the same: merchant, tell me the real number. Real price with tax for this address. Real shipping options with real dates. Real availability now, not at last night's snapshot. If those are callable services in your architecture, you can serve any protocol. If they are entangled in a checkout controller inside a monolithic storefront, you cannot serve any of them well.

3 · Treat the capability declaration as a governed artifact

Whether you publish a profile or negotiate dynamically, you need one internal source of truth for "what we actually support, per market, per brand, per customer class." Deriving your public declarations from that source is straightforward. Maintaining several public declarations by hand is how you end up advertising a capability in Germany that only exists in the UK.

4 · Instrument agent traffic separately from human traffic

You cannot make a rational protocol decision without evidence about which agents are actually transacting with you and where they fail. Most analytics stacks currently bucket all of this as "other" or discard it as bot traffic. Chapter 8 covers the identity signals that make the separation possible; the analytics work is worth starting before the protocol work.

This is the layer that keeps risk officers awake, and the one where the industry has least prior art. Everything above it assumes an answer to a question that no existing web standard was designed to answer.

The scenario

The agent goes away, evaluates, and returns with a machine at €1,899. It presents a payment credential. And now the merchant, the acquirer and the issuing bank all face the same question:

How does anyone know the agent was actually permitted to do that?

Note carefully what the question is not. It is not "is this card valid" — that is settled. It is not "is this the cardholder's device" — that is authentication, and it is also largely settled. It is a third thing: was this specific act, at this value, in this category, within the boundary the human set?

The web has an excellent answer to who are you. It has essentially no standardized answer to who authorized you to do what.

AP2 and the mandate

The Agent Payments Protocol addresses exactly this. Its central idea is cryptographic mandates:

The agent therefore carries proof: the user permitted me to perform a defined type of action within defined limits. Google describes AP2 as a payment authorization layer that works alongside UCP.¹¹

Why a mandate is not a permission scope

It is easy to mistake this for OAuth scopes with better branding. The difference matters:

The last row is the one with commercial consequences. A mandate is designed to be evidence. In a dispute — the buyer says they never wanted this, the merchant says the agent asked for it — someone needs an artifact that survives the conversation. That is a fundamentally different design goal from an access token.

Neutral governance and autonomous payments

Two developments changed the seriousness of this layer. On 28 April 2026, Google donated AP2 to the FIDO Alliance, so that the standard would have more neutral, industry-wide governance. AP2 v0.2 also introduced support for Human Not Present scenarios — autonomous payments executed on the basis of the user's prior authorization.¹²

Both parts matter, for different reasons.

The donation is a maturity signal. Payment authorization cannot be owned by a single platform and expect adoption by banks, networks and regulators. Handing it to a body already trusted for authentication standards is the move that makes it plausible as infrastructure rather than as a product feature.

Human Not Present is the commercially explosive part. Card economics have long distinguished between transactions where the cardholder is present and those where they are not, because the liability and fraud profiles differ. Agentic commerce introduces a third category that fits neither template: the human is absent at the moment of transaction but demonstrably authorized it earlier, in a bounded way. Standardizing that category is what makes the whole model financeable — and it is why this layer, more than the commerce protocols, will determine how fast agentic purchasing actually scales.

Verifiable Intent

Alongside AP2, a second concept is emerging with an unusually good name. Google and Mastercard are working on a standard for cryptographically recording what the human actually authorized the agent to do. Google announced in 2026 that Verifiable Intent is compatible with AP2 and also destined for the FIDO Alliance.¹²

Whether it ends as a distinct standard or as a component of AP2, the concept it names is likely to outlive any particular specification. Once agents act at scale, "prove the human meant this" becomes a primitive that dozens of systems need, well beyond payments: contract acceptance, consent capture, regulatory attestation, approval workflows inside enterprises. It is entirely possible that Verifiable Intent turns out to be the most consequential idea in this guide.

What a merchant should do about it

Very little of this layer is implemented by merchants directly — it lives with payment providers, networks and agent platforms. But three things are yours.

Decide your posture on unauthorized-intent risk. When an agent-initiated order is disputed on the grounds that the buyer never sanctioned it, what is your evidence, your refund policy and your escalation path? Answer this before it happens, because the first time it happens will be at a bad moment.

Record what you were shown. If an agent presents authorization evidence, retain it with the order. Evidence that is not stored is not evidence. This is a small data-model change now and an expensive retrofit later.

Set your own limits. Nothing prevents you from applying merchant-side ceilings to agent-initiated transactions: value thresholds above which a human confirmation step is required, categories excluded from autonomous purchase, velocity limits per buyer. This is the commerce equivalent of an action-heat control posture, and it is entirely within your gift.

Before any of the previous chapters can happen, a request has to get through your front door. Right now, for a great many merchants, it does not — because the front door cannot tell a customer's agent from an attacker's.

The problem, stated plainly

Your edge sees traffic:

GET  /product/123
GET  /cart
POST /checkout

Is that ChatGPT, or Gemini, or another legitimate agent acting for a real customer? Or is it a scraper, a fraud bot, a credential-stuffing run, or an inventory-hoarding script?

The traditional signals have collapsed. A user-agent string is self-declared — anyone can write User-Agent: ChatGPT. IP ranges are increasingly weak as an identifier, given cloud egress, residential proxies and the sheer churn of infrastructure. Behavioural heuristics, which is what most bot management actually relies on, are now being applied to software that behaves more like a fast, methodical human than like a crude script.

The result is a bad equilibrium. Merchants tighten bot defences; legitimate buying agents get blocked; the merchant never learns why conversion from AI surfaces is poor, because the failure happened at the edge and was logged as a mitigation, not as a lost sale.

Visa's Trusted Agent Protocol

Visa created the Trusted Agent Protocol, developed with partners including Cloudflare, to let a merchant cryptographically recognize a trusted agent.¹³ The protocol can convey information covering agent intent, consumer recognition and payment information.¹⁴ Technically it builds on HTTP Message Signatures, and Visa has stated an intention for it to work alongside ACP and x402.¹⁵

Those three information types map neatly onto three merchant questions that are usually answered by guesswork:

Web Bot Auth

Running parallel to this, Cloudflare has been developing Web Bot Auth as a way of cryptographically signing traffic generated by bots and agents.¹⁶ The agent signs the HTTP request cryptographically, and the server can verify its origin. Cloudflare now classifies signed agents separately, and has used Web Bot Auth with agent traffic including the ChatGPT agent.¹⁷

The foundation underneath is an IETF standard — RFC 9421, HTTP Message Signatures.¹⁸ This is a genuinely important detail. It means the identity layer is not a proprietary header invented by a vendor; it is a published standard for signing HTTP requests, with the ordinary properties of standards: multiple implementations, security review, and a path to becoming default infrastructure rather than a premium feature.

// conceptually, what a signed agent request establishes

request           → signed with the agent operator's private key
signature covers  → method, path, key headers, body digest, timestamp
your edge         → resolves the key, verifies the signature
you now know      → which operator sent this, verifiably
you still need    → whether the human authorized the purchase
                     (that is AP2 / Verifiable Intent, Chapter 07)

Three questions, three layers — do not confuse them

A great deal of muddled thinking in this field comes from collapsing these:

A signed request from a recognized operator tells you the traffic is legitimate. It does not tell you the purchase is sanctioned. An intent mandate tells you the purchase is sanctioned. It does not tell you the requester is who they claim. You need both, and they are being built by different people on different timelines.

Why this is the layer to work on first

Most merchants reading this guide will conclude, correctly, that the commerce protocols are a platform-vendor problem and the authorization protocols are a payments problem. The identity layer is different: it is largely a decision about your own edge configuration, and it is blocking everything else.

Three immediate actions:

1. Find out what you are currently blocking. Ask your CDN or bot-management vendor for a breakdown of AI and agent traffic, including what was challenged or mitigated. Most teams have never looked, and most are surprised.
2. Decide your policy deliberately, per path. Blocking scrapers on your entire estate is a blunt instrument. Product detail and search paths, cart and checkout paths, and account paths deserve different postures. A signed agent attempting checkout is a customer; an unsigned crawler taking your whole catalog hourly is a cost.
3. Start treating verified agent traffic as a reportable channel. If it is invisible in your analytics, nobody in your organization can make an argument for investing in any other layer of this stack.

x402 solves a different problem from everything else in this guide, and it is easy to dismiss on first reading. Do not. It describes an economy that does not exist yet and probably will.

Not shoes. API calls.

The commerce protocols address an agent buying a product for a human. x402 addresses something else entirely:

There is no human waiting. There is no basket. There is no shipping address. The transaction needs to complete in the time it takes to make an HTTP request, and the overhead of a conventional checkout — an account, a card form, a signup flow, a subscription — costs vastly more than the thing being purchased.

The status code that waited thirty years

HTTP has long carried a reserved status:

402 Payment Required

It was defined and then left largely unused for decades, because nobody had a payment mechanism that fit inside a request cycle. x402 builds a working payment flow around it.

Coinbase describes x402 as a mechanism that lets a human or a machine buy access to a resource without a checkout page, a card form or a signup flow.¹⁹ Notably, x402 is developing transport beyond plain HTTP — including over MCP and A2A.²⁰

That last point is the one that connects it to the rest of the stack. If an agent can discover a tool through MCP and pay for that tool's use in the same interaction, then metered capability becomes composable in a way it has never been. A tool no longer needs a business development conversation and a contract to be usable; it needs a price and an endpoint.

What becomes purchasable

Follow that through and the list of things an agent might buy, unattended, gets long:

Why a commerce leader should care

Three reasons, none of them speculative.

You may be a seller in this economy sooner than you think. Any organization sitting on proprietary data has, in principle, something an agent would pay for per-call: product compatibility data, availability, pricing for a specific configuration, technical specification lookups, certification status. Today that is either free and scraped, or locked behind an enterprise agreement with a six-week sales cycle. A per-call price is a third option that has never been practical before.

Consider the industrial example from the introduction. A manufacturer that publishes compatibility data freely gets scraped and gains nothing measurable. A manufacturer that hides it behind a portal is excluded from agent-mediated selection entirely. A manufacturer that exposes it as a metered, signed, machine-payable service is present in the decision and gets paid for the data — while learning exactly which compatibility questions the market is asking.

Your costs may change shape. If your own agents can buy capability per call, a category of build-versus-buy decisions gets much cheaper to test. The failure mode is equally new: an autonomous system with a spending capability and a badly bounded loop. Which returns us, immediately, to the authorization layer.

It changes what "free" means on your site. The current bargain — free content in exchange for an eventual human visit — assumes a human eventually visits. Where that assumption fails, the alternatives are to block, to accept the loss, or to charge. x402 is the first credible mechanism for the third option at a price point that makes sense.

Neither of these is a commerce protocol. Both belong in this guide, because commerce protocols increasingly ride on them — and because confusing them with commerce protocols is the most common category error in the field.

MCP: how an agent reaches capabilities

The Model Context Protocol standardizes how AI applications access resources, tools and prompts or capabilities. The current specification defines communication between Host, Client and Server, based on JSON-RPC.²¹

In a commerce context, an MCP server exposed by a merchant looks something like this:

The division of responsibility with the commerce protocols is clean once you see it:

These are not competing ideas, and the specifications say so: UCP has an MCP binding.⁵ You can think of MCP as the socket and UCP or ACP as the appliance standard that says what a commerce plug is shaped like.

Why the distinction has practical consequences

Because an MCP server is easy to build, many organizations will build one before deciding what commerce semantics it should follow. That produces a familiar outcome: a bespoke tool surface, unique to your company, which every agent must learn individually and which nobody can compose with anything else.

It is the API sprawl problem, arriving again, one abstraction level higher. The discipline is the same as it was for APIs: a tool catalogue with owners, versioning, authorization mode, rate limits, and a documented action class per tool. A tool description is not a permission model, and an MCP server with an unbounded create_order() tool is a liability regardless of how elegantly it is specified.

A2A: how agents reach each other

One level above sits the Agent2Agent Protocol. It originated at Google but was contributed to the Linux Foundation and is developed as a vendor-neutral open protocol.²²

A2A addresses agent → agent, not agent → tool. An agent can publish an Agent Card describing its identity, skills, capabilities, endpoints and authentication requirements. The current specification covers discovery, task management, streaming and the exchange of structured data between independent agents.²³

The B2B picture this enables

Consumer agentic commerce gets the attention. The B2B version is larger and less discussed:

Read that chain carefully, because it is a description of procurement without a portal. No punchout catalog. No supplier login. No PDF quote emailed at 4pm. Two organizations' software negotiating within bounds their humans set, leaving evidence at each step.

That is either an efficiency story or a governance nightmare, depending entirely on whether the authorization and identity layers hold. Which is the argument of this entire guide, compressed into one diagram.

The Agent Card and the trust question

The Agent Card deserves particular attention from anyone thinking about supplier relationships. It is a published, machine-readable declaration of what an agent is and what it can do — and the obvious next question is who vouches for it. A supplier agent claiming a capability it does not have, or an identity it is not entitled to, is a fraud vector that has no precise equivalent in existing B2B commerce.

This is the same problem the identity layer solves for HTTP traffic, restated for autonomous counterparties, and it is why work like the Trusted Agent Protocol and Web Bot Auth matters well beyond retail checkout.

The interface layer is the least discussed and, for brand and marketing leaders, quite possibly the most consequential. When the agent renders your product, somebody decides what that looks like. It is no longer obviously you.

A2UI

A2UI describes how an agent can transmit the structure of a dynamic interface — product cards, configurators, forms, checkout components. The current production line of A2UI uses streaming JSON to create and update the interface.²⁴

The significance for commerce: the moment of choice — the comparison, the configuration, the confirmation — is generated by the agent, from data you supplied, inside a surface you do not own.

AG-UI

AG-UI standardizes communication between an agent backend and a user-facing application, including streaming, state, tool calls and user interaction.²⁵ Where A2UI concerns what the interface is, AG-UI concerns how the running conversation between the agent and the surface stays coherent.

Google's own framing of the stack

Google presents the whole set roughly as follows:¹¹

What this does to brand and merchandising

This is where the strategic conversation gets uncomfortable, and where marketing leadership needs to be in the room rather than briefed afterwards.

Your creative assets become inputs, not outputs

For twenty years, digital brand work culminated in a controlled surface: your PDP, your art direction, your copy, your layout. In an agent-rendered comparison, that surface may never be seen. What the buyer sees is a card assembled by the agent, in the agent's design system, containing the fields the agent considered relevant.

You still control something important — what is available to be shown — but you no longer control the composition. The practical implication is that structured attributes, clear differentiators and machine-verifiable claims start doing work that used to be done by design.

Comparison becomes the default context

A product page is a monologue. An agent-generated card is almost always presented alongside alternatives. Any claim that only survives in isolation — vague superlatives, unquantified benefits, differentiation that requires a paragraph of explanation — will lose to a competitor whose advantage is expressible as a comparable value.

This is uncomfortable for categories that have historically competed on brand feeling rather than specification. It is a considerable opportunity for brands whose products genuinely are better on measurable dimensions and who have never been able to get that across in a banner.

Confirmation is a trust moment you can influence

Before an agent commits money, a well-designed flow shows the human what is about to happen. That confirmation is assembled from what you exposed: total, delivery date, return window, cancellation terms, what happens if it is out of stock. A merchant that exposes clear, unambiguous terms gets a confirmation card that builds confidence. A merchant that exposes gaps gets a confirmation card with gaps in it — and hesitation at exactly the wrong moment.

There is a large new body of structured product data arriving in Europe that was designed for regulators, not for agents. It will be read by agents anyway — and for some categories it will be the richest machine-readable asset a manufacturer has ever published.

The Digital Product Passport

The EU Digital Product Passport is not an AI protocol. It is a regulatory instrument. But it creates an enormous new layer of structured data about:

The Commission launched a DPP Registry in July 2026, and the DPP is to be progressively required across successive product groups.³²

Why an agent cares about a compliance artifact

Because a great many real purchase constraints are compliance constraints wearing commercial clothing. "Must be REACH compliant." "Must have a valid declaration of conformity." "Must be recyclable in this market." "Cannot contain this substance." "Must be repairable for the depreciation period." These are not sustainability aspirations; they are procurement filters, and until now they have been resolved by a human emailing a supplier and waiting.

An agent evaluating options can only apply a filter it can read. If your compliance data is a PDF in a document library and your competitor's is structured and addressable, the agent applies the filter to your competitor and quietly drops you — the same silent exclusion described in Chapter 3, now with regulatory data as the deciding attribute.

The technical layers underneath

The DPP does not stand alone. It sits on top of the identity and classification infrastructure from Chapter 2, and the combination is what makes it useful to software.

The query, revisited

Return to the sentence from the introduction and watch it decompose across the stack:

That is not a thought experiment. It is the emerging infrastructure of agentic commerce, and every element of it is either published, in specification, or in regulatory rollout today.

The European advantage nobody is claiming

There is a strategic observation here that is worth stating directly, because it runs against the usual narrative about European regulation as a drag on digital competitiveness.

Regulation is currently forcing European manufacturers to produce structured, verified, machine-readable data about their products at a level of rigour that no marketing department would have funded voluntarily. That data was mandated for enforcement purposes. It happens to be exactly what an autonomous buyer needs in order to select a product with confidence.

A European industrial manufacturer with ETIM classification, GS1 identity and DPP compliance data has, without intending it, assembled a better agent-readable product record than most consumer brands with far larger digital budgets. The gap is not in the data. It is in the recognition that the data is now a commercial asset and should be exposed as one — through feeds, through capability endpoints, through addressable resolution rather than a PDF download.

Thirteen standards, two contested layers, and a release cadence measured in weeks. The natural response is paralysis. The correct response is an architecture that makes the contest irrelevant to you.

The failure mode to avoid

It looks like this, and it is already happening:

Eight surfaces, six owners, no reconciliation. Every new channel adds a maintenance stream and a new opportunity for divergence. Within a year you have contradictory claims in public, and no reliable way to find out which is wrong.

This is not a hypothetical risk. It is what happened during the marketplace era, and the remedy was well understood by 2015. What is new is the cost of divergence: a search engine showing a stale price produces a mildly annoyed shopper; an agent transacting on a stale price produces a failed order and a broken promise made on your behalf.

The architecture that survives

The claim is not that this is novel. It is that the same architecture that made channel expansion cheap in the marketplace era makes protocol expansion cheap now — and that the evidence for convergence is already in the specifications. OpenAI's support for mapping Google-compatible feed columns rather than requiring a rewrite⁴ is precisely the behaviour of an ecosystem that expects merchants to have a canonical layer and does not want to be the reason they build a thirteenth export.

What "canonical" has to mean

Most companies believe they have this and do not, because they have a PIM. A PIM is a place to put attributes. Canonical product knowledge is a stronger claim. It requires ten properties:

That last property is the one that separates this from a data-quality programme. A nightly export cannot answer "what does this cost, delivered to this postcode, for this customer, today." A canonical layer that cannot be called is a canonical layer that cannot participate in a transaction.

The three services every adapter needs

Underneath the adapters, almost every protocol in this guide ends up asking for the same three things. Build them once.

Resolve, quote, commit. Every commerce protocol in this guide is, at bottom, a particular grammar for those three verbs plus a post-purchase loop. If you can serve them cleanly, adding a protocol is an adapter and a test suite. If you cannot, adding a protocol is a project.

Worked example: a mid-size industrial distributor

To make this concrete, here is how the architecture plays out for an organization that is neither a startup nor a global enterprise: a distributor with 60,000 SKUs across 400 manufacturers, selling to trade customers in five European markets, with negotiated pricing and a legacy ERP.

What they have

• A PIM containing manufacturer-supplied data of wildly varying quality, and no per-category completeness measurement.
• ETIM classification for roughly a third of the catalog, concentrated in the categories where manufacturers supplied it.
• Pricing in the ERP, customer-specific, calculated at quote time.
• Stock in a warehouse system that the webshop reads every four hours.
• Compliance documents in a shared drive, organized by manufacturer.

What breaks when an agent arrives

• Resolve fails on two thirds of the catalog, because unclassified items cannot be checked against a technical constraint. The distributor is invisible for exactly the queries where their expertise is worth most.
• Quote fails structurally, because price depends on a customer identity the agent has not established, and there is no path to establish it without a browser login.
• Commit is impossible, because nothing exposes order creation outside the webshop's session-bound checkout.
• Compliance filters exclude them, because the documents exist but are not attached to product records in any addressable form.

The sequence that fixes it

Note what is not first. Not the protocol. Not the MCP server. Not the AI project.

1. Measure classification coverage by category and by revenue. Fix the top decile by revenue, not the easiest decile by effort. This is a purchasing conversation with 400 manufacturers as much as a data project — and the ones who cannot supply classified data are telling you something about their own agent-readiness.
2. Make price and availability callable. A service that answers "price for this item, this customer, this quantity, today" and "available in this market now" is worth more than any protocol adoption, and is required by all of them.
3. Solve identity linking. Trade pricing without customer identity is impossible. This is the specific capability that turns a B2B distributor from a catalog into a transactable supplier.
4. Attach compliance documents to product records with structured metadata: what it certifies, which regulation, validity dates, which markets.
5. Only then choose a protocol — and expect to publish to more than one, from the same core, at low marginal cost.

A field guide that ends in analysis has failed. This chapter is the sequenced work — ordered so that each quarter produces something useful even if the next one is delayed, and so that nothing depends on guessing which protocol prevails.

Quarter one — see the traffic, measure the data

The theme is evidence. You cannot make an investment case for any of this without knowing what is already happening to you.

Identity and traffic

• Obtain a breakdown of AI and agent traffic from your CDN or bot-management vendor, including what was challenged, mitigated or blocked.
• Establish whether any of it is signed, and whether your edge can distinguish signed agents at all.
• Decide a deliberate policy per path: catalog and search, cart and checkout, account, documents. Blanket blocking is a decision — make it consciously rather than by default.
• Create a reportable channel for verified agent traffic. Until it appears in a dashboard someone reviews, it does not exist organizationally.

Catalog

• Measure attribute completeness by category, weighted by revenue.
• List the ten constraints buyers state most often in your categories and check each is machine-checkable.
• Measure the lag between a price change and its appearance in every outbound surface. Write down the worst case.
• Name an owner for product data as a product.

Quarter two — make ground truth callable

The theme is services. This is the quarter that determines whether protocol adoption later is an adapter or a rebuild.

• Expose resolve: authoritative item lookup and constraint-checkable search, independent of the storefront.
• Expose quote: real price with tax for a destination and customer context, plus real fulfillment options and dates.
• Expose availability with meaningful freshness rather than a nightly snapshot.
• Attach compliance and certification data to product records with structured metadata.
• Put the capability declaration under governance: one internal source of truth for what you support, per market, brand and customer class.

Quarter three — transact, narrowly

The theme is a bounded first delegation. Pick one category, one market, one customer class. Resist the urge to launch everything.

• Implement commit: order creation, inventory reservation, payment capture and event emission, callable outside the storefront session.
• Adopt whichever commerce protocol your platform supports first, in the narrow scope, as a projection of the services you built in quarter two.
• Set merchant-side limits on agent-initiated transactions: value ceilings requiring confirmation, excluded categories, velocity limits.
• Retain authorization evidence with the order record. Decide the retention period now.
• Define the dispute path for "the buyer says they never authorized this" before you need it.

Quarter four — widen and industrialize

• Extend to a second protocol or ecosystem and measure the marginal cost. If it is high, your canonical layer is not yet canonical — fix that rather than adding a third.
• Close the post-purchase loop: status, modification, cancellation, returns, exposed to the same channel that bought.
• Review the agent traffic and conversion data you have been collecting since quarter one, and reallocate on evidence rather than narrative.
• Fold the vendor questions below into every renewal that comes up.

Who owns what

The last row is the one most organizations get wrong. Every layer of this stack lives in a different function, and none of the functions can deliver alone. Product data sits with merchandising or supply chain. Commerce capability sits with digital. Identity sits with security. Authorization sits with payments and legal. Presentation sits with brand. In most companies these five groups do not have a shared meeting, a shared vocabulary, or a shared metric.

There is a popular version of this story that says the web is moving from HTML to Markdown — that agents prefer plain text, and the work ahead is mostly about publishing cleaner documents. That version is not wrong so much as it is a description of one layer, mistaken for the whole.

Markdown, llms.txt and clean structured text matter a great deal for knowledge consumption. When an agent needs to understand your positioning, your policies, your documentation or your reasoning, well-formed text is the right vehicle, and most organizations publish it badly.

But commerce demonstrates the limit of that framing. When an agent has to act — to commit money, to reserve inventory, to create an obligation — text stops being sufficient. No amount of beautifully formatted prose tells a machine what operations you support, what a price will be for this buyer in this market, whether the human authorized the spend, or how to prove afterwards that everything was in order.

What an acting agent needs is a chain, and every link in it is a different kind of artifact:

What this means for everything you have already published

It does not become worthless. It becomes a layer with a narrower job. Your website continues to serve humans, to carry brand, to persuade, to rank. What changes is that it is no longer the whole of your commercial surface — and for an increasing share of transactions, it is not the part that matters.

The organizations that handle this well will be the ones that stop treating "our digital presence" as a single thing. There are now at least three surfaces with different audiences and different quality bars:

Most organizations have invested heavily in the first, minimally in the second, and not at all in the third. The stack described in this guide is, in effect, the specification for that third surface — being written in public, at speed, by companies with strong incentives and imperfect coordination.

The advantage is not in picking correctly

It is tempting to read thirteen protocols and conclude that the winning move is to identify the survivors early. It is not. Most of these will change materially within a year; several will merge; some will be absorbed into others; at least one will become infrastructure so boring that nobody discusses it.

The durable advantage belongs to organizations that can answer, for any given protocol, a single question: how long would it take us to support this? If the answer is measured in weeks, the contest is genuinely not your problem. If it is measured in quarters, you will spend the next several years reacting to other people's release notes.

That answer is not determined by protocol expertise. It is determined by whether your product knowledge is canonical, whether your commerce core is callable, whether your edge can recognize an agent, and whether anyone owns the whole thing.

48 items across five sections. Score them for one brand, in one market — not for the group. Readiness is not an enterprise property; it varies enormously by category, region and channel, and averaging hides exactly the gap you need to find.

A2A — Agent2Agent Protocol

An open protocol for communication between independent agents, originated at Google and contributed to the Linux Foundation. Covers discovery, task management, streaming and structured data exchange. Distinct from MCP: A2A is agent-to-agent, MCP is agent-to-tool.

A2UI

A specification for how an agent transmits the structure of a dynamic user interface — cards, configurators, forms, checkout components — with the current production line using streaming JSON to create and update it.

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, with the merchant computing prices, taxes and inventory and charging through its own PSP.

AG-UI

A standard for communication between an agent backend and a user-facing application, covering streaming, state, tool calls and user interaction.

Agent Card

In A2A, a published description of an agent's identity, skills, capabilities, endpoints and authentication requirements — the artifact that makes agent-to-agent discovery possible.

AP2 — Agent Payments Protocol

A payment authorization protocol built around cryptographic mandates: an intent mandate expressing what the human permitted, a payment mandate binding a specific transaction to it, and a receipt as durable evidence. Donated by Google to the FIDO Alliance in April 2026; v0.2 added support for Human Not Present scenarios.

BMEcat

An XML standard for exchanging multimedia product catalogs, long used to transmit ETIM-classified catalog data between manufacturers, distributors and platforms. The direct ancestor of everything in the knowledge layer.

Canonical product knowledge

A single authoritative internal representation of what you sell — identity, classification, attributes, price, availability, fulfillment, compliance and relationships — from which every external surface is derived rather than separately maintained. Distinguished from a PIM by requiring authority, freshness, scope, provenance and real-time callability.

Capability discovery

The mechanism by which an agent learns what operations a merchant supports before attempting any of them. In UCP, a profile published at a well-known location describing protocol version, services, capabilities, endpoints, payment configuration and public signing keys.

Capability negotiation

The mechanism by which an agent and a seller agree on which operations are available for a particular interaction — present in both ACP and UCP, and an acknowledgement that merchants differ too much for a fixed uniform contract.

Delegated authentication

Establishing that the buyer is who the agent says they are, without a browser redirect and a password field. Distinct from authorization, which concerns what that buyer sanctioned.

Delegated payment

Presenting a payment credential to the merchant through an agent without the agent handling raw payment details in an unacceptable way.

DPP — Digital Product Passport

An EU regulatory instrument creating structured data on materials, origin, sustainability, repairability, safety, compliance, recycling and lifecycle. A registry launched in July 2026, with requirements phasing in by product group. Not an AI protocol, but likely to be the richest machine-readable product record many manufacturers publish.

ECLASS

A data standard for products and services positioning itself as machine-readable reference data, broader in scope than ETIM.

ETIM

An international classification standard for technical products, defining classes, properties, values and units so product data can be exchanged unambiguously. Widely used in electrical, building and industrial supply chains.

GS1 Digital Link

A GS1 standard that turns identifiers such as GTIN, GLN, batch or serial number into URIs resolving to different kinds of digital information about a product — converting a barcode number into an addressable entry point.

Human Not Present

A transaction category in which the human is absent at the moment of purchase but demonstrably authorized it in advance, within limits. Introduced in AP2 v0.2. Distinct from both card-present and traditional card-not-present, and commercially significant because liability models depend on the distinction.

Intent mandate

A cryptographic record of what a human permitted an agent to do and within what bounds. Unlike an OAuth scope, it is designed to be understood by parties with no prior relationship to the agent — merchants, networks, issuers — and to survive as evidence.

MCP — Model Context Protocol

A standard for how AI applications access resources, tools and capabilities, defining Host, Client and Server communication over JSON-RPC. The socket that commerce protocols can travel through; UCP has an MCP binding.

Merchant of Record

The party legally selling to the customer, responsible for the transaction, tax, refunds and liability. Both UCP and ACP are designed to keep the merchant in this position rather than inserting a new intermediary.

Product Feed Spec (OpenAI)

A schema and delivery specification by which merchants supply OpenAI with an authoritative structured catalog — products, variants, price, availability, seller, fulfillment — via file-based feeds or an API. Positioned as the first step toward ACP integration, and supporting a Google-compatible path that maps existing Google Product Data columns.

RFC 9421 — HTTP Message Signatures

The IETF standard for cryptographically signing HTTP requests, underlying both Web Bot Auth and Visa's Trusted Agent Protocol. The reason agent identity is a standards question rather than a vendor feature.

Resolve, quote, commit

The three services every commerce protocol in this stack ultimately requires: return the authoritative record for an item, return the real total for a basket in context, and create the order. Building these as callable services makes protocol adoption an adapter rather than a project.

Signed agent

An agent whose HTTP requests carry a cryptographic signature the server can verify, allowing it to be distinguished from a self-declared user-agent string. Cloudflare classifies these separately as part of Web Bot Auth.

TAP — Trusted Agent Protocol (Visa)

A protocol for cryptographically recognizing a trusted agent at the merchant boundary, built on HTTP Message Signatures and able to convey agent intent, consumer recognition and payment information.

UCP — Universal Commerce Protocol

Google's open standard for agentic commerce spanning discovery through checkout and post-purchase, with capability discovery via a well-known profile, a roadmap extending beyond retail into food and lodging, and the merchant remaining Merchant of Record.

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.

Web Bot Auth

Cloudflare's approach to cryptographically signing bot and agent traffic, built on RFC 9421, allowing servers to verify request origin rather than trusting a user-agent string or IP range.

x402

A protocol reviving the HTTP 402 Payment Required status to let software buy access to a resource — an API call, dataset, inference or tool — without a checkout page, card form or signup flow. Developing transport over MCP and A2A as well as plain HTTP.

Every specification claim in this guide traces to one of the sources below. Protocol details change quickly; treat these as the authoritative reference and this guide as an interpretation of them. Code samples throughout are illustrative sketches, not extracts.

1. OpenAI — Product Feed Spec. Schema and delivery specification for merchant catalogs. developers.openai.com/commerce/specs/spec
2. OpenAI — Agentic Commerce, Get Started. Product Feed positioned as the first step of ACP integration. developers.openai.com/commerce/guides/get-started
3. OpenAI — Key concepts. Data types, refresh guidance, snapshots and API updates. developers.openai.com/commerce/guides/key-concepts
4. OpenAI — Products, file upload. Google-compatible product feeds and column mapping. developers.openai.com/commerce/specs/file-upload/products
5. Google — Universal Commerce Protocol guide. Scope, surfaces, Merchant of Record, and alignment with MCP, A2A and AP2. developers.google.com/merchant/ucp
6. UCP — Universal Commerce Protocol. Capability overview. ucp.dev
7. Google — UCP profile. The well-known capability document and its contents. developers.google.com/merchant/ucp/guides/ucp-profile
8. UCP — Roadmap. Extension beyond retail into food and lodging, loyalty, benefits and post-purchase. ucp.dev/documentation/roadmap
9. Agentic Commerce Protocol — Sellers. Checkout session endpoints and merchant responsibilities. agenticcommerce.dev/docs/getting-started/sellers
10. Agentic Commerce Protocol — Capability negotiation. agenticcommerce.dev/docs/concepts/capability-negotiation
11. Google Developers Blog — Developer's Guide to AI Agent Protocols. The MCP / A2A / UCP / AP2 / A2UI / AG-UI framing, and AP2 alongside UCP. developers.googleblog.com
12. Google — Agent Payments Protocol donated to the FIDO Alliance. 28 April 2026; AP2 v0.2 Human Not Present support; Verifiable Intent with Mastercard. blog.google
13. Visa — Trusted Agent Protocol for AI commerce. Announcement and collaboration with Cloudflare. corporate.visa.com
14. Visa Developer Center — Trusted Agent Protocol overview. Agent intent, consumer recognition, payment information. developer.visa.com
15. Visa — Trusted Agent Protocol, interoperability intent. Alignment with ACP and x402. corporate.visa.com
16. Cloudflare — Web Bot Auth. Using cryptography rather than IP addresses to verify bot and agent traffic. blog.cloudflare.com/web-bot-auth
17. Cloudflare — Signed agents. Cryptographically recognizing agent traffic. blog.cloudflare.com/signed-agents
18. IETF — RFC 9421, HTTP Message Signatures. datatracker.ietf.org/doc/rfc9421
19. Coinbase Developer Documentation — x402 overview. Buying resource access without a checkout page, card form or signup. docs.cdp.coinbase.com/x402/welcome
20. Coinbase Developer Documentation — Discover and pay over MCP. x402 transport beyond HTTP. docs.cdp.coinbase.com/x402/buyer/mcp-payments
21. Model Context Protocol — Specification. Host, Client, Server communication over JSON-RPC. modelcontextprotocol.io
22. Linux Foundation — Agent2Agent Protocol project launch. Vendor-neutral governance for A2A. linuxfoundation.org
23. A2A Protocol — Specification. Agent Card, discovery, task management, streaming, structured data. a2a-protocol.org
24. A2UI — Protocol specification. Streaming JSON for creating and updating agent-generated interfaces. a2ui.org
25. AG-UI — Agent User Interaction Protocol. Streaming, state, tool calls and user interaction between agent backend and application. docs.ag-ui.com
26. Google Merchant Center — Product data specification. The classic feed attribute model. support.google.com/merchants
27. Schema.org — Offer and Product types. On-page structured commerce data. schema.org/Offer
28. GS1 — Digital Link. Turning GTIN, GLN, batch and serial identifiers into resolvable URIs. gs1.org/standards/gs1-digital-link
29. ETIM International. The international classification standard for technical products. etim-international.com
30. ECLASS. Machine-readable reference data standard for products and services. eclass.eu
31. ETIM International — Guidelines. BMEcat as the XML exchange format for classified catalog data. etim-international.com
32. European Commission — Digital Product Passport. Registry launched July 2026; progressive rollout by product group. single-market-economy.ec.europa.eu
33. auxfirst — The Agent-Operable Enterprise. The companion field guide on internal agent operability: data shape, process design, trust and permissions. agentoperability.com