DEV Community: Benji Fisher

How the Personal Agent Protocol Works: A Real Agent, Step by Step

Benji Fisher — Thu, 15 Oct 2026 13:27:05 +0000

We gave a personal agent one sentence: "Move my delivery to Saturday and add a side of gyoza." Three model turns later the order at a noodle bar had changed. The agent never saw a password, and nothing changed until we approved the exact terms on screen. Then we asked it to check something with the restaurant's own AI agent, and the two agents sorted it out between them. The model's share of the bill was under a cent.

This post walks through that run screen by screen, to show how the Personal Agent Protocol (PAP, nicknamed "Poppy") works in practice. It's written for the people deciding whether their company should support it, such as product, digital and customer-experience leads, and for the developers who would build it. No code is needed to follow along.

How does the Personal Agent Protocol work?

The Personal Agent Protocol is a draft open standard for how a person's AI agent works with a company on their behalf. It works in five steps:

Find. The agent reads the company's poppy.json file to learn how it works with agents.
Start a session. The agent opens a session as a guest, so it can browse and search but can't see an account.
Sign in. When the task needs the person's account, the person signs in on the company's own page and chooses what the agent may do.
Propose and approve. The company turns the change into exact terms (price, items, a deadline), and the person approves them in their agent.
Confirm and record. The company makes the change, and both sides keep a record the person can see and revoke.

Along the way, the agent can use the company's API, its website or its own AI agent, all in the same session. The draft was published by Sierra and Meta on 9 October 2026 at version 0.1, and it may change before a stable version.

The setup: a test agent and a test restaurant

To show this end to end you need two sides: an agent, and a company that speaks the protocol. We used two free tools I built for exactly this:

PAP Playground is a personal agent you can give a task. It records every request and response, so you can see what the protocol actually does.
PAP Sandbox runs three test companies: a noodle bar, a flower shop and a holiday let. Each has a test customer with one open order and its own AI agent. Nothing is charged, nothing is cooked and nothing ships.

The company in this walkthrough is Kettle Street Noodles. The test customer has two tonkotsu ramen and a miso soup booked for delivery on Friday between 6:30 and 7:00pm: $39.49 with delivery.

Step 1: the agent finds out how the company works with agents

Every company that supports the protocol publishes a small file at /.well-known/poppy.json. It's the company's front door for agents. Here's Kettle Street Noodles' file, shortened:

{
  "protocol_version": "0.1",
  "organization": { "name": "Kettle Street Noodles", "domain": "food.papsandbox.com" },
  "auth": {
    "issuer": "https://food.papsandbox.com",
    "direct": { "scopes": ["poppy:read", "poppy:write"] },
    "device": { "scopes": ["poppy:read", "poppy:write"] },
    "mediated": { "endpoint": "https://food.papsandbox.com/poppy/sign-in" }
  },
  "apis": [
    { "type": "openapi", "url": "https://food.papsandbox.com/poppy/openapi.json" },
    { "type": "mcp", "url": "https://food.papsandbox.com/poppy/mcp" }
  ],
  "agent": { "protocols": [{ "type": "poppy", "endpoint": "https://food.papsandbox.com/poppy/conversations" }] },
  "web": { "browser_session_endpoint": "https://food.papsandbox.com/poppy/browser-session" },
  "extensions": { "operations": { "version": "1", "endpoint": "https://food.papsandbox.com/poppy/operations" } }
}

The file says:

who the company is and where its sign-in server lives
the three ways a customer can sign in
what the agent may ask for: poppy:read to see the account, poppy:write to change things
the routes the agent can use: the company's APIs, its own AI agent, and its website

Before it trusts any of that, the agent checks the file. PAP Playground ran 11 checks, each tied to a section of the draft. For example, it checks that the domain in the file matches the site it came from, and that the sign-in server really belongs to the company.

If any of these checks failed, the agent would stop here. You can run the same checks on any domain with PAP Checker.

Step 2: the agent starts as a guest, then needs the person

Next the agent opens a session. In the protocol, a session is one person's visit to one company through one agent, whether the agent uses the API, the website or the company's own agent. Every session starts signed out. The company knows which agent is calling, but not who the customer is.

That's enough to browse, and the agent did: it searched the menu for gyoza and looked up the delivery slots. Then it tried to read the customer's orders, and the company said no: 403 sign_in_required. That isn't a failure. It's the protocol doing its job, because orders belong to an account and the person hasn't signed in yet.

The agent pauses and asks the person to sign in. The right-hand side is the trace: every call the agent made, in order, with the section of the draft it belongs to.

Step 3: the person signs in on the company's own page

This is the step that matters most for trust. The person signs in on the company's page, not the agent's, and the agent never sees a password. The protocol offers three ways:

On the company's page (direct). The agent opens the company's sign-in page. You sign in there, the company sends the agent a one-time code, and the agent swaps it for its own access.
With a code on another device (device). The agent shows a short code, and you enter it on the company's site on your phone or laptop. This suits agents you talk to by voice or text.
Inside the agent (mediated). You sign in through a form the company defines, shown by the agent. The company decides whether to offer this at all.

Here's Kettle Street Noodles' page. It says which agent is asking, and lets the person choose what it may do:

"See your account" is poppy:read, and "Make changes" is poppy:write. The person can untick either one. Even with "Make changes" ticked, the page says it plainly: you still approve each change. This test restaurant has no passwords, so it signs in as the test customer. A real company would show its normal login here.

What if you sign in as someone else? A session belongs to one account, for good. While making this walkthrough we signed an agent out, then tried to sign the same session in as a different test customer. The company refused: "This Session was signed in to a different account, and a Session never switches accounts." The draft requires it (section 4.4), and it's a useful safeguard: an agent can't quietly carry one person's session over to another person's account. The right recovery is for the agent to start a fresh session and ask again.

Step 4: the company proposes exact terms, and the person approves them

Signed in, the agent read the order, picked the gyoza and asked the company to change the order. The company didn't change it. It sent back a proposal: the exact terms of the change, with a deadline to confirm.

This comes from the protocol's operations extension, and it's the core of the safety model:

The company writes the terms, not the agent. Price, items, date and total come from the company's own system.
The person approves those exact terms in their agent. The draft says the agent must show the company's name and summary, and must take the person's answer through its own screen. A message from the company can never count as the person's "yes".
Approval covers one version only. If the terms change (say, a different time slot), the company issues a new revision, and it needs a new approval.
Proposals expire. If nobody confirms by the deadline, nothing happens.

The draft also allows a standing permission for small things the person agreed to in advance, such as "move my delivery if it costs nothing extra". A company can turn that off for any change it wants approved every time.

The task never said which time on Saturday. The agent chose to keep the same evening slot. Because the terms spelled out "Sat 17 Oct, 6:30 to 7:00pm" before anything changed, the person could decline and ask for lunchtime instead. That's what approving the exact terms is for.

Step 5: the change is made, and both sides keep a record

We approved. The agent confirmed, the company made the change and reported the result: Saturday 17 October, 6:30 to 7:00pm, gyoza added, $47.49.

The whole task took 3 model turns, 7,916 tokens and $0.007 with Gemini 3.6 Flash. The protocol calls themselves are fast: most took between 200 and 300 milliseconds.

The company keeps its own record too. Here's the customer's account page at Kettle Street Noodles after the run:

The Connected agents panel matters for any company thinking about this. The customer can see every agent with access to their account, what it may do, and disconnect it at any time.

Step 6: your agent talks to the restaurant's agent

Many companies already run an AI customer-service agent. Under the protocol, your agent can talk to theirs directly, in the same session, instead of opening a chat window built for people. We gave our agent a follow-up: "Ask the restaurant's own agent whether the driver can leave the order with my building's concierge, and tell me what it says."

Our agent opened a conversation with Kettle Street Noodles' agent and asked. The restaurant's agent answered from the order itself: yes, the driver can leave it with the concierge, "because the order does not contain alcohol."

The restaurant's record of the same moment shows what happened on its side:

The second line is the important one. To answer, the restaurant's agent looked up the customer's order itself, inside the same signed-in session and within the access the customer had given. Three rules keep this safe:

Every message is labelled. It says whether the company's agent or a person wrote it, and whether it came from your agent or from you.
A company message is never your approval. If the restaurant's agent proposes a change in the conversation, it still arrives as terms your own agent must show you.
A person is always an option. Your agent can ask for a person at the company, and the conversation moves to their staff.

Who the agent is

Companies don't have to take an agent's word for who it is. Under the protocol, every agent has a public identity: a client_id that is a web address for a short document about the agent, and a public key. The company fetches both and checks every request the agent signs.

Two privacy details are built in:

A different user ID at every company. The ID an agent gives you is different at each one, so two companies can't use it to link you.
Tokens that are useless if stolen. Session tokens are short-lived and tied to a key the agent holds, so a copied token alone doesn't work.

Three routes in, one session

This walkthrough used two of the three routes the protocol defines. All three count as the same session:

The API. Kettle Street Noodles offers both a standard REST API (OpenAPI) and an MCP server, the format many AI agents already use. It's the fastest and most predictable route, and the agent used it for the order change.
The company's own agent. The agent used this route for the concierge question.
The website. The agent's own browser joins the signed-in session, so it can use pages built for people without ever typing your password.

A company doesn't need all three. One is enough to start.

What this means for your company

If you already run customer accounts with OAuth sign-in and have an API, most of the pieces exist. Supporting the protocol mainly means:

Publish a poppy.json. It says how agents can work with you. The guide explains every field, and the validator checks a draft before you publish it.
Show a clear consent page. Name the agent, and let customers choose read-only or change access.
Propose changes and don't just make them. Return terms with a deadline and let the customer approve them. This is where the operations extension earns its place.
Let your AI agent take calls from personal agents. If you already run one for customer service, it can answer them in the same session, with the same access rules.
Show customers their connected agents. Let them see and disconnect any agent, and decide what stays read-only: you set the ceiling, and the customer chooses within it.

Try it yourself

See it run. Give the agent a task at any of the three test companies in PAP Playground. The Inspector lets you send each call yourself, one step at a time, including messages to a company's agent, with no AI model on your side.
Build against a test company. PAP Sandbox is open to any agent that speaks the protocol.
Check a real company. PAP Checker reads any domain's poppy.json against draft 0.1, and the sites list shows who already publishes one.

What's still open

Version 0.1 is a draft, and the authors say any part can change before a stable release. The Path to 1.0 lists payments, push notifications and attachments as open topics. In this walkthrough nothing was charged: the change went to the card already on the order, and the test restaurant charges nothing. How an agent pays for something new is one of the things still being worked out.

FAQ

What is the Personal Agent Protocol in simple terms?

It's a draft open standard for how your AI agent works with a company for you. The company publishes a poppy.json file saying how agents can work with it. You sign in on the company's own page and choose what the agent may do, and the agent works through the company's API, website or AI agent within that access.

Does my AI agent see my password?

No. With direct and device sign-in you sign in on the company's own page, and the agent only receives its own access. With mediated sign-in you type your details into a form the agent shows, and the draft says the agent may send them only to the company's own sign-in address. After that it doesn't need them again. The company decides which ways it offers.

Can a personal agent change an order without asking me?

Not under the operations extension. The company sends exact terms, and the agent must get your approval for that version before confirming. The exception is a standing permission you gave in advance, which a company can refuse for any change it wants approved every time.

Can my AI agent talk to a company's AI agent?

Yes. If the company lists its own agent in poppy.json, your agent can open a conversation with it in the same session. The company's agent can look things up within the access you gave, and propose changes, which still come back to you as terms to approve. Your agent can also ask for a person.

What is poppy.json?

A small JSON file a company publishes at /.well-known/poppy.json. It tells personal agents who the company is, how customers sign in, what access an agent can ask for, and which routes it offers. See What is poppy.json? for every field.

Is the Personal Agent Protocol the same as UCP?

No. The Universal Commerce Protocol covers shopping: catalogues, carts and checkout. The Personal Agent Protocol covers the relationship between an agent and a company: who the agent acts for, signing in to the person's account, what it may see and change, and keeping one session across the API, the website and the company's own agent.

Who created the Personal Agent Protocol?

Sierra and Meta launched it on 6 October 2026 and published draft 0.1 on 9 October 2026. The Path to 1.0 lists 35 design partners.

Can I test the Personal Agent Protocol without building anything?

Yes. PAP Playground gives a ready-made agent a task at PAP Sandbox's test companies, and records every step. Both are free.

Sources

Personal Agent Protocol, draft 0.1 specification, sections 3 (discovery), 4 (sessions and sign-in), 5 (websites), 6 (APIs) and 7 (conversations), 9 October 2026
Personal Agent Protocol, Operations extension, sections 3 to 5
Personal Agent Protocol, Path to 1.0, 12 October 2026
Sierra, Introducing the Personal Agent Protocol, October 2026
Walkthrough run on PAP Playground at Kettle Street Noodles on PAP Sandbox, 15 October 2026

The Personal Agent Protocol is a draft at version 0.1 and may change. I maintain PAP Checker, PAP Playground and PAP Sandbox. They're independent and not affiliated with the protocol's authors. "Personal Agent Protocol" and "Poppy" are their names.

Building on the Personal Agent Protocol Before 1.0: What Changed on 12 October, and How to Send Feedback

Benji Fisher — Tue, 13 Oct 2026 14:43:50 +0000

The Personal Agent Protocol (PAP, nicknamed Poppy) site at personalagentprotocol.org now says "Updated Oct 12, 2026". If you've built against draft 0.1, the short answer is that nothing you built needs to change. The specification, the operations extension and the guides read the same as before, and the draft is still 0.1.

What changed is everything around the spec: how the protocol gets to 1.0, how to send feedback, and who is involved.

What's new

A Path to 1.0 page. Anyone can build against the draft. The authors are working through implementations with several design partners, and the spec will change based on what they learn. Until 1.0, a revision can break compatibility with earlier drafts.
Renamed pages. "Overview" is now Introduction, and "Open topics" is now a section of Path to 1.0. The old URLs redirect, but update your links.
A public partner list. Launch partners and design partners now sit in one list, grouped as personal agents (Instinct, Meta, OpenAI), companies and technology providers. No new names were added compared with the 9 October announcement.
Contribution terms. Code and spec contributions are under Apache 2.0. Read the feedback clause before you send anything (more on that below).

How to give feedback

There are two routes. Both end with an email to feedback-personal-agent-protocol@sierra.ai.

Inline comments. Turn on site commenting, select any text in the docs to comment on it, then export your comments from the "…" menu next to Comments.
An agent review. Download the "agent kit" from the Path to 1.0 page. It contains all the docs and an AGENTS.md that tells an agent how to write feedback in the form the authors want. Point your coding agent at it, review what it writes, and send it.

The authors say they most want feedback on:

privacy and security: weaknesses in sign-in, sessions, tokens, permissions or how user data is handled;
gaps: something you needed that the draft doesn't cover, or that doesn't work as written;
simplification: parts that could be simpler without losing what they make possible;
extensions many implementations need, "such as payments".

Read this before you send anything. Under the contribution terms, feedback you volunteer is licensed to "all other members and users of the protocol" on a "perpetual, irrevocable, nonexclusive, worldwide, royalty-free, sublicensable" basis, "without compensation". That's normal for a spec process. It means you shouldn't put anything in feedback that you want to keep for your own product.

What the draft still leaves out

The three open topics haven't changed:

Payments: how a personal agent pays "in a way that fits the protocol, including how that works with existing payment protocols";
Push notifications: how a company reaches the agent when no request is open;
Attachments: receipts, return labels, images and forms in company messages.

If your agent needs to buy something today, the checkout still happens outside PAP. Some early adopters are already declaring payment details through their own extensions, and the authors list payments as an extension they'd welcome.

Who is building against the draft

Four days after draft 0.1, a handful of sites already serve a /.well-known/poppy.json. On PAP Checker's directory on 13 October, 10 sites publish one. Most are builders' demos and test benches, which is what you'd expect this early. Three are real businesses: Tilopay (payments, Costa Rica), Emora Health and Rent Our Bins. Each is a first mover on a protocol that's four days old.

None of the launch or design partners publish a poppy.json yet. The authors say they're working through implementations with partners first, so expect the first big names to appear alongside the reference implementation Sierra says is coming "over the next month".

What to watch next

a public repository and named maintainers;
the reference implementation;
a JSON Schema or conformance suite;
the first launch or design partner to publish poppy.json;
a payments extension, and how it relates to existing payment protocols.

Disclosure: I maintain PAP Checker and UCP Checker. PAP Checker is an independent community checker, not affiliated with the protocol's authors. The draft is 0.1 and can change before 1.0.

What Is poppy.json? A Personal Agent Protocol Example, and How to Validate Yours

Benji Fisher — Sun, 11 Oct 2026 21:46:50 +0000

The Personal Agent Protocol (PAP, nicknamed Poppy) is a new open protocol, led by Sierra and Meta, for how a person's AI agent works with a company on their behalf: signing in as the user, using the company's APIs, joining a website session, or talking to the company's own agent. Draft 0.1 was published on 9 October 2026, with 35 design partners including OpenAI, Visa, Mastercard and PayPal.

Everything a personal agent does with a company starts by reading one file: /.well-known/poppy.json. This post explains what that file is, shows a complete example, and covers the checks an agent makes before trusting it.

Not to be confused with the poppy.json used by the Poppy robotics project (pypot). This one is the Personal Agent Protocol's discovery document.

Where poppy.json lives

At https://{your-domain}/.well-known/poppy.json, served over HTTPS as JSON. It may redirect (for example to a provider that hosts it), but every redirect must stay on HTTPS, and the document still speaks for the domain the agent asked for.

A poppy.json example

{
  "protocol_version": "0.1",
  "organization": { "name": "Example Company", "domain": "example.com" },
  "auth": {
    "issuer": "https://auth.example.com",
    "direct": { "scopes": ["poppy:read", "poppy:write", "addresses"] },
    "device": { "scopes": ["poppy:read", "poppy:write"] },
    "custom_scopes": { "addresses": "Manage saved shipping addresses" }
  },
  "agent": {
    "protocols": [{ "type": "poppy", "endpoint": "https://api.example.com/poppy/conversations" }]
  },
  "web": { "browser_session_endpoint": "https://example.com/poppy/browser-session" },
  "apis": [
    { "type": "openapi", "url": "https://api.example.com/openapi.json", "description": "Orders, returns, and exchanges" },
    { "type": "mcp", "url": "https://mcp.example.com/mcp", "description": "Product search and sizing" }
  ]
}

This is shortened from the example in the specification. A field-by-field version is on the What is poppy.json? guide.

What each field means

Field	Required	What it says
`protocol_version`	Yes	The version the document follows, as `major.minor`. Draft 0.1 is `"0.1"`. Agents must not use a document whose major version they don't support.
`organization`	Yes	Display name and domain. The domain must match the host the agent requested (ignoring a leading `www.`).
`auth`	When `agent`, `apis` or a browser session is listed	The OAuth issuer and the sign-in types the company supports (`direct`, `device`, `mediated`), each with the scopes it can grant. `custom_scopes` describes anything beyond `poppy:read` and `poppy:write`.
`agent`	One of `agent`, `apis`, `web`	The company's own agent: its conversation protocols, each with a type and an HTTPS endpoint.
`apis`	One of `agent`, `apis`, `web`	APIs the agent can call, each with a `type` (`openapi` or `mcp`), a `url` and a short `description`.
`web`	One of `agent`, `apis`, `web`	The website. The optional `browser_session_endpoint` lets the agent's browser join its session, so pages apply the user's sign-in.
`extensions`	No	Extensions the company supports, keyed by name, each with a version. `operations` is defined with the protocol; anyone else's start with a domain, such as `example.com/gift-wrap`.

The check agents make on your sign-in server

A valid-looking poppy.json isn't enough. Before using it, a personal agent fetches the OAuth server metadata of auth.issuer (RFC 8414, at /.well-known/oauth-authorization-server) and checks two things:

Its issuer matches auth.issuer exactly.
Its poppy_domains lists your domain. This field isn't part of the OAuth standard; PAP adds it to the metadata so the sign-in server can say which domains it works for.

Without that second check, a fake site could publish a poppy.json naming your real sign-in server, and agents would send users there. The metadata must also publish a token_endpoint and revocation_endpoint, plus authorization_endpoint for direct sign-in and device_authorization_endpoint for device sign-in.

Common poppy.json mistakes

organization.domain set to a parent brand or a different country domain. Several domains can share one issuer, but each names itself and each must appear in poppy_domains.
Custom scopes that start with poppy:. That prefix is reserved; only poppy:read and poppy:write are allowed.
An MCP server whose resource metadata doesn't list your issuer in authorization_servers, so MCP clients can't sign in.
A storefront that answers every path with its HTML page. Agents need JSON at the well-known URL, not a soft 404.

Who publishes poppy.json today?

Almost nobody, yet. On 11 October we checked the launch partners and design partners, including Shopify, Stripe, Walmart, Meta, Visa, Mastercard, PayPal, OpenAI and Cloudflare. None serve /.well-known/poppy.json so far. The only live files are developer demos. That's expected three days after a draft. It also means the first company to publish a correct file will be easy to spot.

The running list, with the day each domain was first seen, is at papchecker.com/sites.

How to validate your poppy.json

I built PAP Checker to check a domain against draft 0.1 from the outside, the same way a personal agent would. Enter a domain and it:

fetches /.well-known/poppy.json and follows redirects, as an agent would;
checks discovery (protocol_version, organization, the domain match);
fetches the issuer's OAuth metadata and checks sign-in (issuer match, poppy_domains, the required endpoints for each sign-in type);
checks scopes, routes (agent, APIs, website, all on HTTPS) and extensions;
ties every result to the section of the specification it comes from.

It only reads public documents. It never signs in, starts a session, or calls your APIs. It's free and needs no sign-up.

👉 Check your poppy.json at papchecker.com

Caveats

Draft 0.1 can still change in ways that break existing files, and Sierra has said a reference implementation is coming. The checker follows the published draft and will move with it. If you find a rule it gets wrong, tell me in the comments.

Disclosure: I maintain PAP Checker and UCP Checker, which does the same job for the Universal Commerce Protocol. PAP Checker isn't affiliated with the protocol's authors.

Is My Store WebMCP and UCP Ready? What Agent Checkout Actually Needs

Benji Fisher — Mon, 13 Jul 2026 08:41:34 +0000

The short answer: WebMCP is the part of agent commerce your customers' browser will handle — and UCP is the part that actually completes the sale. If you want to know whether your store is ready for the agents arriving through both, enter your domain here. It checks the commerce layer — the half that decides whether an agent can finish a checkout, not just start one.

The longer answer — what "WebMCP and UCP ready" actually means for a store, how the two fit together, and what to do about it — is what this post covers.

What "WebMCP-ready" actually means

WebMCP (the Web Model Context Protocol) is a W3C Community Group draft from Google and Microsoft engineers that landed in February 2026 and shipped as an early preview in Chrome 146. It adds a browser-native API — navigator.modelContext — that lets a web page hand an in-browser AI agent a set of structured, callable tools instead of forcing it to scrape the DOM.

In plain commerce terms: your search box, your filter panel, your add-to-cart button, and your checkout form stop being pixels an agent has to guess at, and become named tools the agent can call directly. There are two ways to expose them:

Declarative — add toolname and tooldescription attributes to the HTML forms you already have. A search form becomes a search_products tool with almost no code.
Imperative — register tools in JavaScript for the dynamic flows that aren't simple forms.

Crucially, WebMCP tools run inside the user's own authenticated browser session, with human-in-the-loop approval. The agent acts as the shopper, on the shopper's machine, with the shopper's login.

So "is my store WebMCP-ready?" is really two questions, and most merchants only think about the first:

Can an agent operate my page? (WebMCP — client side, in the browser)
Can an agent actually transact with my store? (UCP — server side, the commerce backend)

WebMCP exposes the tools. UCP closes the sale.

This is the part that gets lost in the WebMCP hype. WebMCP is a transport for intent — it lets the agent say "add this variant, apply this code, check out." It does not define what a product, a cart, a payment handler, or an order confirmation is. That's UCP's job.

The clearest way to see it: WebMCP can hand an agent a checkout tool, but if the agent calls it and your store can't return a structured cart, can't accept a delegated payment token, and can't confirm the order in a machine-readable way, the tool call fails. The agent had the button. The store couldn't honour the press.

The emerging consensus — including from people building this at the platform level — is that agent-ready commerce is a stack, not a single switch:

Structured data so the agent understands your catalog.
WebMCP so the agent can act on the page.
UCP so the action becomes a real, completed purchase.

WebMCP makes your store operable. UCP makes it transactable. A store that's WebMCP-ready but not UCP-ready is a storefront with working buttons and no cash register.

Why this matters for Shopify (and everyone downstream of it)

If you're on Shopify, most of the UCP layer is being handled for you — Shopify has been building UCP into the platform and shipped its own UCP CLI. That's the half WebMCP doesn't cover, already moving. The open question for a Shopify merchant isn't "will I get a manifest" — it's "is my specific store's manifest valid, complete, and not silently broken by a theme or app change."

For WooCommerce, BigCommerce, and Magento merchants, more of that backend is on you. WebMCP support will arrive through the browser regardless of your platform — but the UCP layer that turns an agent's checkout tool-call into an order is the part you have to get right yourself. Our platform monitoring data shows that's exactly where most stores fall down.

How to check the half that counts today

WebMCP is still a Chrome-preview standard, and the page-side tooling is shifting week to week. The commerce layer underneath it, though, is live right now — and that's checkable in about a second.

Step 1: Run the checker

Go to UCPChecker.com/check and enter your domain. It will:

Fetch /.well-known/ucp from your store
Validate the manifest against the current spec
Inventory your declared capabilities, transports, and payment handlers — the exact primitives a WebMCP checkout tool needs on the backend
Report every error and warning with specific codes

If your store can't complete an agent checkout, the failure almost always lives in one of those primitives — not in the page-side tooling everyone's talking about.

Step 2: Read the result

Verified — your commerce backend is valid and an agent that reaches your checkout tool can actually transact. Check the warnings for depth.

Invalid — the manifest exists but fails validation. Most invalid stores are one fix away — usually a missing required field.

Not Detected — no manifest. Your store is WebMCP-operable at best and un-transactable at worst. See the requirements.

Blocked — a robots.txt or firewall rule is hiding the manifest from agents.

Step 3: Test with real agents

Validation proves your manifest is correct. It can't prove an agent can complete a purchase end to end — for that you need UCP Playground, which runs real agent sessions against your store and shows you exactly where the flow breaks.

Step 4: Monitor

Your manifest is a live API. Theme updates, app installs, and CDN changes break it silently. UCP Alerts emails you the moment your status changes — before an agent's checkout tool call fails.

A WebMCP-readiness checklist for the page side

Client-side scanners now exist — Chrome extensions that score your page on tool detection, coverage, schema quality, and declarative-form setup. They're useful, and they answer the first of our two questions. What none of them check is whether a completed tool call can actually clear a purchase. So pair the page-side scan with this backend list:

Add toolname / tooldescription to your search, filter, and add-to-cart forms.
Name tools for intent, not for your UI ("find_products", not "header_search").
Keep a real human-approval step on anything that spends money.
Test in Chrome 146+ with the Model Context Tool Inspector.
Make sure every tool that ends in a purchase has a working UCP path behind it — or the tool is a dead end.

That last point is the whole argument: the page-side checklist is short and shipping. The backend it depends on is where readiness is actually won or lost.

What's next: WebMCP as a UCP transport

The line between "operate" and "transact" may not stay fixed. In its 2026-05-08 session, the UCP Technical Council reviewed a proposal to use WebMCP as a UCP transport — letting an agent drive visible page state through WebMCP tools instead of firing disparate backend API calls. The appeal is real: the shopper watches the cart fill and the checkout advance in their own browser, in real time.

The council didn't approve it on the spot, and the reason is the most interesting part for merchants: UI synchronization. If an agent's backend call updates the order, the storefront has to emit the matching events so the visible interface reflects the new state at the same moment — otherwise the agent and the page drift apart. A dedicated deep dive was scheduled to work through that architecture.

It's worth watching, because if WebMCP becomes a sanctioned UCP transport, the two halves of "ready" start to converge. But the dependency direction doesn't change: WebMCP would be how the agent talks to your store; UCP is still what it's saying. The backend has to be right either way.

Why this matters now

WebMCP went from proposal to Chrome preview in a single quarter. Browser support across Chrome and Edge is expected by late 2026, and once an agent can operate any page in the user's own session, the bottleneck stops being can the agent click and becomes can the store transact. That second half is UCP, it's live today, and across the stores in our growing directory it's still where most checkouts would fail.

Is my store WebMCP and UCP ready? The honest answer for most merchants is: the browser will make you operable for free — but only the commerce layer you control decides whether the sale actually closes. Check that half first.

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find — across Shopify, WooCommerce, BigCommerce, Magento and beyond — and run the cross-platform merchant directory, the UCP Score and live adoption stats. As WebMCP moves from preview to production, we track the commerce layer underneath it as it ships.

Check your store: ucpchecker.com/check
Grade it (UCP Score): ucpchecker.com/score
See cart, checkout & payment coverage: ucpchecker.com/capabilities
Browse the directory: ucpchecker.com/directory
Get notified when your status changes: ucpchecker.com/alerts

WebMCP will give every store a front door for agents. We measure whether the checkout behind it actually works.

Merchant and capability figures are live from the UCP Checker index and update every 24 hours; see the methodology.

Check your store now →

Understand the protocol stack: MCP vs UCP vs AP2. Platform-specific setup: Shopify · WooCommerce · BigCommerce. Monthly ecosystem data: State of Agentic Commerce.

KYC, KYB, KYA: The Identity Stack for Agentic Commerce

Benji Fisher — Sat, 11 Jul 2026 09:28:23 +0000

If you're shipping anything agentic in 2026 — an AI shopping agent, an autonomous procurement bot, a customer-service agent that can issue refunds — you're going to keep hearing the same three letters in compliance reviews: KYA. Know Your Agent.

It's framed as a new acronym, but the pattern is forty years old. Banking invented Know Your Customer to comply with anti-money-laundering law. Then the same pattern was bolted onto businesses (KYB), and now — because software agents can move money, place orders, and bind their operators to contracts — onto agents themselves.

Here's the framing we keep coming back to when developers ask us how all this stuff fits together:

KYC, KYB, and KYA aren't a comparison. They're a lineage. Each one applies the same risk-management primitive — verify identity, assess risk, apply controls, keep evidence — to a new class of actor as that actor becomes powerful enough to matter.

Agents are the new class. This post walks the lineage, explains what KYA actually proposes, and shows where it sits relative to UCP — because the two get conflated constantly and they're doing genuinely different jobs.

The lineage, in one diagram

┌──────────────────────────────────────────────┐
│                                              │
│   KYA   ← Know Your Agent                    │
│         (a software actor with its own       │
│          identity, reputation, audit trail)  │
│                                              │
├──────────────────────────────────────────────┤
│                                              │
│   KYB   ← Know Your Business                 │
│         (a corporate entity —                │
│          UBOs, sanctions, controllers,       │
│          source of funds)                    │
│                                              │
├──────────────────────────────────────────────┤
│                                              │
│   KYC   ← Know Your Customer                 │
│         (a verified human —                  │
│          government ID, address,             │
│          source of funds, sanctions)         │
│                                              │
└──────────────────────────────────────────────┘

Read it bottom-up. KYC verifies humans, KYB verifies the companies they hide behind, and KYA verifies the software agents now transacting on behalf of both. (There's also KYE — Know Your Employee — the internal-HR variant for humans inside regulated companies; it's the same primitive applied to another actor class, but it's a stitched-together HR/IAM/GRC discipline rather than a discrete vendor category, so we'll mostly leave it aside here.)

That's the whole shape. Now the detail.

KYC — Know Your Customer

The original. Born out of US anti-money-laundering legislation (the Bank Secrecy Act, expanded by the USA PATRIOT Act) and replicated globally through FATF guidance.

KYC answers: is this person who they claim to be, and are they allowed to transact? Verification means government-issued ID, proof of address, source of funds for larger transactions, and ongoing screening against sanctions and politically-exposed-persons lists.

It's mandatory for regulated financial services and most account-opening flows. Failure to do it properly costs banks billions in fines every year. The KYC vendor market — Onfido, Persona, Jumio, Trulioo, Veriff and others — exists because KYC is law, not best practice.

KYB — Know Your Business

The corporate extension. When a bank onboards a business account, or one regulated entity onboards another (a payment processor onboarding a merchant, a fintech onboarding a SaaS company), KYC isn't enough. You need to verify the entity itself.

KYB answers: does this company actually exist, who controls it, what does it do, is it sanctioned? Verification means company registry lookup, beneficial owner identification (UBOs — the humans behind the legal entity), industry classification, sanctions screening of both the entity and its controllers.

KYB is where things get expensive and fragmented — beneficial-owner data quality varies wildly by jurisdiction, and ultimate ownership often runs through three or four shell layers before you hit a human. Most KYB vendors layer KYC on top: verify the entity, then verify the humans who control it.

KYA — Know Your Agent

The new entry. The term consolidated around 2024–2025 as AI agents started showing up in transactional flows — placing orders, authorizing payments, filing tickets, binding their operators to commitments. Some vendors brand it KYAI; some just say "agent identity." KYA has won as the shorthand.

The crucial conceptual move, and the one that breaks everything that came before: agents need their own identity, not borrowed user credentials. An agent acting on behalf of a user isn't the user. It's a separate actor with its own developer, its own version, its own behavioural history, and — once it's been in production for a while — its own reputation.

Eric Broda's framing in the Agentic Mesh writeups puts it cleanly: KYA applies the same primitive as KYC and KYB — verify identity, assess risk, apply controls, keep evidence — to software agents that can take real actions inside business workflows. The Trulioo + PayOS reference model ("Digital Agent Passport") proposes five concrete steps:

Verify the agent developer. A real business behind it, KYB-style.
Lock the agent code. Only approved code can run under that identity.
Capture user permission. Proof of consent from whichever human is being represented.
Issue a passport. A tamper-proof credential the agent can present at runtime.
Continuous lookup. Revocation and behaviour monitoring in real time.

Vouched's variant (via Model Context Protocol – Identity, or MCP-I) adds reputation tracking and decentralised identifiers. Skyfire's version is a JWT-style agent credential — and their recent partnership with F5 makes the immediate commercial wedge clear: bot-management systems need a way to distinguish legitimate, revenue-generating agent traffic from malicious automation. "Don't block my AI shopping agent the way you'd block a scraper" is becoming the fastest commercial argument for KYA in the field.

Why agents broke the existing identity stack

The natural objection: can't an agent just use the human's OAuth token? We already have identity for the user — pass it down.

Three reasons that doesn't work, and they're the same three reasons KYA exists as a category at all.

1. Reputation belongs to the agent, not the user. If an agent built by Vendor X starts misbehaving across the ecosystem — abandoning carts, creating chargebacks, abusing returns — that signal needs to attach to the agent, not to every consumer who happens to use it. You could track reputation on (user_id, agent_id) pairs riding on borrowed user credentials, but it conflates two distinct accountability surfaces and misaligns liability. Agent-native identity keeps the two layers clean.

2. Revocation is per-agent, not per-user. When a vulnerability is found in a specific agent version, the response is "stop trusting this agent version everywhere, immediately" — not "log every user out." That needs a credential the issuer can revoke without nuking the user.

3. Audit trails need to attribute correctly. Regulators (and any sensible internal compliance function) will want to know which agent took which action. Did the user click the buy button, or did the agent autonomously decide to? OAuth alone collapses that distinction; KYA preserves it.

This is the philosophical wedge between KYA and "just bolt OAuth onto an agent." OAuth gives an agent the user's permission. KYA gives the agent its own accountable identity.

And there's a fourth reason that's about to matter more than the other three: regulators are arriving. KYC and KYB didn't become standard practice because banks volunteered them — they became standard because the Bank Secrecy Act, the USA PATRIOT Act, FATF guidance and successive AML directives across the EU made them mandatory. KYA is on the same trajectory. The EU AI Act already imposes obligations on operators of "high-risk" AI systems, including identification, logging and human-oversight requirements that map cleanly onto KYA primitives. Successive US executive orders on AI have pushed in the same direction, and FATF's emerging work on AI-driven financial flows is the next shoe to drop. The pattern with regulated identity has always been the same: voluntary best practice → industry standard → mandatory for regulated entities. KYA is mid-step-two right now, and the agents-touching-money use case is precisely where regulators tend to start.

The KYA landscape today

The vendor map is still being drawn — most of the work is happening in 2025 and 2026, and the category boundary keeps shifting. Here's a neutral roundup of the players and what each is actually shipping.

Trulioo + PayOS are pushing the Digital Agent Passport reference model — the five-step framework that's becoming the most-cited architectural definition of what a KYA system needs to do.
Skyfire is shipping the KYA token — a JWT-style agent credential — and pursuing the immediate commercial wedge through partnerships with bot-management vendors (notably F5). The story: let legitimate agent traffic through, block the rest.
Vouched is shipping MCP-I (Model Context Protocol – Identity), extending MCP with identity primitives and adding reputation tracking and decentralised identifiers on top.
Prove has positioned Verified Agent and KYAPay as the payment-flavoured framing — explicitly listing it alongside ACP, AP2, and UCP as a peer trust layer in their AI-native commerce framework.
Persona is bringing its established dynamic-IDV stack into the agent context, leaning on the same orchestration engine that powers their human-verification flows.

A few adjacent acronyms are circling the same conceptual space — Prove's KYAPay, Vouched's MCP-I, Skyfire's KYA token. These are largely vendor brandings on the same underlying problem: how does a merchant decide whether to trust the software agent on the other end of the connection?

And it's worth flagging the competitive frontier honestly. Visa's Intelligent Commerce protocol bakes KYA-style identity directly into the Visa network; Mastercard's Agent Pay does the same for its rails. Some vendors are pitching their identity layer as the layer — not a layer on top of UCP, MCP, or AP2. So you'll hear both composition rhetoric ("we work with UCP") and substitution rhetoric ("our identity protocol replaces what UCP gestures at") in the same vendor decks. Worth knowing which one you're hearing.

How KYA sits relative to UCP

This is where developers building on UCP get tripped up, so it's worth spelling out carefully. UCP already does some of what KYA does — and explicitly punts on the rest.

What UCP already encodes. Every UCP request carries a UCP-Agent header pointing to a /.well-known/ucp profile. That profile publishes signing keys, so RFC 9421 HTTP Message Signatures can authenticate the platform cryptographically. The same profile serves as both capability declaration and key resolution — and verifiers must ensure the authenticated identity is consistent with the UCP-Agent header. So at the transport layer, UCP gives you "this request demonstrably came from the entity that controls profile X."

That's the cryptographic half of agent identity. Necessary, but not sufficient.

UCP also defines an Identity Linking capability via OAuth 2.0 — but that's user-to-merchant account linking (loyalty, wishlists, authenticated checkout), not agent attestation. And AP2 Mandates provide cryptographic proof of user consent specifically for the payment moment.

Where KYA layers in. UCP says nothing authoritative about:

Who operates the entity behind a profile (the KYB-on-the-agent-owner question).
Whether the agent's code is what its operator claims it is.
The agent's behavioural reputation across merchants.
The verified-human-behind-the-session question, beyond an OAuth grant.
Revocation and continuous risk scoring.

So the clean composition story is this:

UCP is the protocol. KYA is the trust overlay. UCP gets the bytes from agent to merchant with provable origin. KYA tells the merchant whether to trust that origin — who's behind it, whether the user is real, whether this agent has misbehaved elsewhere.

The two are complementary, and the leading KYA vendors are largely pitching that way. The substitution rhetoric — "forget UCP, just use our identity protocol" — exists, but it tends to come from vendors whose protocols don't yet have the capability vocabulary UCP does. Compose the two; you get both halves.

Common questions

These are the exact questions we see most often when developers and compliance teams start mapping their agent-identity work.

What is the difference between KYC and KYA?

KYC verifies a human customer. KYA verifies a software agent. They operate at different layers and you increasingly need both.

KYC is the mandatory regulatory floor for onboarding a human into a financial relationship — government ID, address, sanctions screening. KYA is the equivalent pattern applied to the software agent acting on that human's behalf — verifying the developer, locking the code, capturing user consent, issuing an agent credential, monitoring behaviour over time. If your AI shopping agent represents a verified KYC'd user, you've covered the human; KYA covers the agent representing the human. Same regulatory logic, one abstraction level up.

What is the difference between KYB and KYA?

KYB verifies the company; KYA verifies the software the company built. KYA actually depends on KYB.

When a KYA framework "verifies the agent developer," it's running KYB on that developer's company — checking registration, controllers, sanctions. So KYB is the foundation: you can't trust an agent's passport unless you trust the entity that issued it. KYA then adds the agent-specific layer on top: which code is running, which user authorised it, what's the agent's behavioural track record.

Is AP2 a form of KYA?

AP2 is a narrow KYA primitive, not a KYA solution.

AP2 Mandates provide cryptographic proof that a specific user consented to a specific payment by a specific agent. That's one of the five things a full KYA framework does — the capture user permission step. AP2 doesn't verify the agent developer, doesn't lock the code, doesn't track reputation, doesn't handle revocation. A merchant integrating AP2 has solved consent-for-payment; they haven't solved Know Your Agent. Most production stacks will end up running AP2 inside a broader KYA framework, not instead of one.

Does UCP include KYA?

Partially. UCP provides cryptographic agent-identity proof at the transport layer — but not the operator verification, code attestation, or reputation tracking that complete KYA requires.

UCP's combination of /.well-known/ucp profiles, published signing keys, and RFC 9421 HTTP Message Signatures gives you cryptographic confirmation that a request came from the entity controlling a given profile. That's necessary infrastructure for KYA but it's not the whole stack — you still need to verify who that entity is (KYB), what code it's running (attestation), and whether you should trust its agent's behavioural history (reputation). UCP and KYA are designed to compose, not to substitute for each other.

Which should you actually adopt

Depends on what you're building.

If you're an agent or tooling developer, sign your requests properly — implement RFC 9421 Message Signatures, publish keys via your UCP profile, and start integrating with one of the KYA vendors (Trulioo, Skyfire, Vouched, Prove, Persona) so your agent can present a verifiable passport when merchants ask for one. The merchants that ask first will be the high-AOV ones.

If you're a merchant or platform, your first move is a clean UCP profile that establishes cryptographic agent identity at the transport layer — that's what a free check validates. Once that's in place, start tracking which KYA credentials the agents hitting your endpoint are presenting. You don't have to enforce KYA today, but you want visibility into what's coming through so you can move from passive logging to active policy when the standards mature.

If you're in risk or compliance, KYA is the bridge between your existing KYC/KYB programs and the new actor class your business is starting to transact with. Map your current KYC vendor's roadmap against KYA capabilities — Onfido, Trulioo, Persona, Jumio are all heading there, with very different positioning. Pick the vendor whose framing matches your buyer expectation: regulated-financial-services vendors will buy compliance-first language; commerce platforms will buy bot-management-first language.

If you're a payments company, AP2 is your immediate technical lane and KYA is your strategic envelope. AP2 Mandates fit inside a broader KYA story, and the payment networks (Visa Intelligent Commerce, Mastercard Agent Pay) are already pulling KYA-style identity into their rails. The question is whether to follow their identity layer, build your own, or partner with one of the dedicated KYA vendors.

The one-line summary

KYC verifies humans, KYB verifies the companies they hide behind, and KYA verifies the software agents now acting on behalf of both. The lineage is the same risk-management primitive — verify, assess, control, evidence — applied to each new class of actor as it becomes powerful enough to matter. KYA is mid-trajectory toward mandatory for regulated entities; cryptographic agent identity at the transport layer is shippable today.

UCP gives you cryptographic agent identity at the transport layer; the KYA category sits on top of it, adding operator verification, code attestation, consent capture, credential issuance, and behavioural monitoring. Together they're the trust stack for agentic commerce. Apart, each one only solves half the problem.

If you're getting started, the foundation is the same as every other piece of agent-readiness work: a valid, machine-readable UCP profile with proper signing keys.

Check your manifest: ucpchecker.com/check
Browse verified stores: ucpchecker.com/directory
Developer guide to /.well-known/ucp: ucpchecker.com/well-known-ucp
Related reading: MCP vs UCP vs AP2: What is the Difference?
Related reading: The UCP Technical Council Just Shipped Attribution into Core

Introducing the UCP Playground Extension: An AI Shopping Agent in Your Side Panel

Benji Fisher — Thu, 28 May 2026 10:01:33 +0000

Our first extension answered one question while you browse: is this store agent-ready? A green dot in your toolbar, fired by a single probe to /.well-known/ucp. It quietly became our biggest discovery engine.

Today we're shipping our second extension — and it answers the obvious follow-up: okay, so what actually happens when an agent shops here? — without making you leave the page.

Meet the UCP Playground — AI Shopping Agent extension. Open Chrome's side panel on any UCP-enabled store, pick a model, and an AI agent shops it live — right beside the page. It searches, compares, builds a cart, and reaches checkout, driving the store through its own published UCP tools. No screen-scraping, no separate tab.

Install it free from the Chrome Web Store →

From a green dot to a live agent

We've been building toward this in three steps.

The first extension is passive detection: one HTTP request per domain, a badge that tells you whether a store speaks the protocol. UCP Playground on the web is the runtime layer: it runs live agent shopping sessions against real stores and shows every JSON-RPC message flowing between agent and merchant — now across 16 frontier models and dozens of real stores.

The gap was the hop between them. You'd spot a UCP store while browsing, then go to a separate site to watch an agent try it. We even teased closing that gap in the first extension's write-up — "see the green dot, click Open in Playground, and you're watching Claude shop."

This extension closes it. Detection and action now live in the same tab.

What it does

A side panel, side by side. Click the toolbar icon and Playground opens in Chrome's native side panel, next to the storefront. You see the human page and the agent's run at the same time.
Chat with any UCP store. Type what you'd ask a shop assistant — "find a waterproof jacket under £100" — and the agent executes the store's UCP tools to answer.
The full tool-call timeline. Every step is visible: search, product lookup, cart, checkout — with raw responses, timing, product cards, cart state, and the final checkout URL. It's the same observability the web Playground is known for, docked beside the page.
Pick your model. Run any model exposed by your Playground account, so you can compare how different agents handle the same store.
Structured, not scraped. The extension drives the store through its published MCP tools — the exact path a real agent takes — so what you see is the protocol behaving, not a DOM hack that breaks on the next redesign.

The side panel drives the store's own UCP tools — get_product_details, update_cart, checkout — beside the page, with timing on every call.

Why a side panel

Side-by-side is the whole point. When you can see the store's own page and the agent's tool calls together, the gaps jump out: a product the agent can't resolve, an option that doesn't map, a checkout that stalls where the website sails through.

For builders, that's a debugging loop measured in seconds — validate product schemas, option resolution, and checkout flows against a live agent without wiring up anything. For merchants, it's the first time you can watch how an agent experiences your store the way a customer's assistant soon will — the same kind of run that produced the first fully autonomous UCP purchase.

Multi-item search and option resolution on Kylie Cosmetics, side by side with the store.

How it works

The first extension was pure client-side: one fetch() to /.well-known/ucp, a badge, done. This one is a thin client in front of the UCP Playground engine — your browser handles detection and display; the agent itself runs server-side. Four moving parts:

1. Detection. On navigation, the extension probes the current host's /.well-known/ucp — the same one-request check the first extension uses, with the host permission scoped to that exact path. It only ever reads the hostname to know where to look.

2. The side panel. Clicking the toolbar icon opens Chrome's native side panel (sidepanel.html) docked beside the page. The tabs permission lets the panel follow you as you move between stores, so it always knows which store to target — without touching anything on the page itself.

3. The agent runs on the Headless API — not in your browser. The extension doesn't run a model locally or scrape the DOM. It sends your message and the store's hostname to the UCP Playground Headless API, authenticated with your personal access token. Playground orchestrates the chosen model and executes the store's published MCP tools server-side — the same engine behind the web Playground and our evals — then streams the session back to the panel. That's why setup needs a free account and a token.

4. The timeline. Every step renders in order — search_catalog, get_product_details, update_cart, complete_checkout — each with its raw response, latency, product cards, cart state, and the final checkout URL. The same observability the web Playground is known for, docked beside the storefront.

Everything heavy — the model, the tool execution, the session record — lives in Playground. The extension is the lens.

What it reads — and what it doesn't

The first extension made a point of its ultra-narrow permissions; we hold the same line here, with one honest difference — a side panel that follows you across stores needs tabs to know which store you're on.

Here's the full ledger: storage (your token and settings), activeTab + tabs (the current store's hostname), sidePanel (the panel itself), and host access scoped to /.well-known/ucp plus ucpplayground.com. What it never requests: content-script access to store pages, your cookies, your history, or <all_urls>. It reads which store you're looking at, not what's on the page — and that hostname is the only thing about your browsing that ever leaves the browser.

Set up in under a minute

Install from the Chrome Web Store (Chrome, Edge, Brave — any Chromium browser).
Create a free account at ucpplayground.com.
Generate a personal access token in settings and paste it into the extension options.
Browse. It auto-detects UCP-enabled stores; click the icon to open the side panel and start shopping.

Where it fits in the stack

Each of our tools answers a different question, and now they chain cleanly from your toolbar:

Detect — the UCP Checker extension: is this store agent-ready?
Score — UCP Checker: how agent-ready is it?
Act & observe — this extension + UCP Playground: what happens when an agent actually shops it?
Monitor — UCP Alerts: did anything change?

The first extension turned passive browsing into a discovery map. This one turns it into a test bench — point an agent at any store on the web and watch the protocol work, live, beside the page.

Sources

UCP Playground — AI Shopping Agent — Chrome Web Store
Our analysis — How a browser extension became our biggest discovery engine and Why we built UCP Playground
UCP Playground at 1,000+ agent sessions — what 16 models and real stores reveal

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and — through UCP Playground — test how real AI agents behave against real stores.

Install the Playground extension: Chrome Web Store
Check your store: ucpchecker.com/check
Grade it (UCP Score): ucpchecker.com/score
Browse the directory: ucpchecker.com/directory
Get notified on changes: ucpchecker.com/alerts

Google Opened UCP for Lodging. We Already Tested What It Needs to Handle.

Benji Fisher — Tue, 26 May 2026 09:39:24 +0000

Google has opened the door to agentic hotel booking. A new developer page — UCP for Lodging — describes an open standard to "turn AI interactions into instant bookings for room reservations." But there is no spec to read yet: the page says plainly that detailed onboarding and specs are "coming soon," and points you to a waitlist rather than documentation. This is an announcement, not a release.

That makes now the moment to write the piece nobody else has. We have already run five frontier models against expiring travel inventory and documented exactly where agents break when an offer times out mid-session. So instead of paraphrasing a waitlist, here is the prescriptive read: what UCP for Lodging will have to specify for agentic hotel booking to actually work — and what hotels should test before they integrate. Our bias throughout: we saw it in the data first.

What Google actually published — and what it didn't

The page is short on detail by design. UCP for Lodging is positioned as an open standard for "direct, instant reservations" that reduces "friction and abandonment," compatible with AP2, A2A and MCP. (New to how those layers fit together? We break the stack down here.) Two things it does not contain: a published spec, and any named partners. The only call to action is a "Join the waitlist" button.

One organizational tell worth registering: the page lives at /hotels/ucp, not /merchant/ucp where the retail protocol sits. UCP for Lodging is being driven by Google's hotels team — the group behind hotel ads — not its general commerce team. Different stakeholders, different roadmap. The travel-distribution names from Google Marketing Live — Booking.com, Expedia, Hilton, Marriott, IHG, Accor, Choice Hotels, Trip.com, Wyndham and Amadeus — are the supply context, though none appear on this page.

We covered the demand side switching on across Google's surfaces in Google Universal Cart & UCP, and why travel is agentic commerce's hardest vertical in our travel analysis. Lodging is the hardest case inside the hardest vertical.

Lodging is harder than retail — and harder than flights

A retail SKU is a fixed thing with a fixed price. A hotel "offer" is generated on the fly from a property, a room type, a rate plan, a date range and an occupancy — wrapped in a pile of taxes and fees — and it changes by the second.

The offer is a combination, not a SKU. Property × room type × rate plan × dates × guests produces a vast, dynamic offer space. There is no stable identifier to drop in a cart and trust.
Length-of-stay pricing. Three nights is not three times the nightly rate; pricing varies by date and stay length.
Rate-plan semantics. Refundable vs non-refundable, prepaid vs pay-at-property, member rates, packages — each carries different money and different rules.
Cancellation and modification policies. Free-cancel deadlines and penalty schedules are part of the offer, and getting servicing wrong has real financial stakes.
All-in price transparency. Resort fees plus city and occupancy taxes mean the nightly rate an agent sees is not the price the guest pays. An agent quoting the wrong number is a broken booking.
Perishable availability. Rooms sell out mid-session; an offer from thirty seconds ago may be gone or repriced.

What we already know breaks: the data

The perishable-availability and repricing problems are not hypothetical — we measured them. We built a mock travel server that issued offers with explicit expiry windows and ran five frontier models against it. Not one checked an offer's time-to-live before booking; only one survived a three-second expiry window; none surfaced a price change unless asked. The agents treated time-boxed travel inventory exactly like a static retail SKU.

Apply that to lodging. An agent that does not re-validate will happily "confirm" a room that sold out two minutes ago, or quote a pre-tax nightly rate as the total. Those are not edge cases in hotel booking — they are the median path.

What UCP for Lodging will need to specify

From the gaps above, here is the shortlist the spec has to cover for agentic hotel booking to be safe. Concretely, a lodging offer needs to look more like this than a retail product:

{
  "offer_id": "marriott-LHR-deluxe-king-20260704",
  "room_type": "deluxe_king",
  "rate_plan": "non_refundable_prepaid",
  "stay": { "check_in": "2026-07-04", "nights": 3, "guests": 2 },
  "total_price": { "amount": 921.00, "currency": "USD", "includes_taxes_fees": true },
  "free_cancel_until": null,
  "ttl_seconds": 120,
  "revalidate_before_booking": true
}

A lodging offer object carrying room type, rate plan, stay dates, occupancy and an all-in total (taxes and fees included), with a TTL.
Machine-readable cancellation and modification policy — deadlines and penalties as structured data, not prose.
Mandatory re-validation before booking — confirm the room is still available at the quoted total before commit.
Servicing capabilities for modify, cancel and no-show, with full request context.
Identity, loyalty and payment timing — member rates, loyalty numbers, deposits and pay-at-property.

A retail offer carries none of these. The lodging extension lives or dies on them.

What hotels should test before integrating

You cannot test against a spec that is not published yet — but you can test the thing the spec will sit on top of: your booking engine and the agents that will drive it. Before you join the waitlist and integrate:

Does your offer carry a clock? Confirm your booking engine can expose a time-boxed offer with a validity window. Validate your endpoint →
Is your price all-in? Make sure an agent can read the total with taxes and fees, not just the nightly rate. Check your catalog →
Do you re-validate before commit? An agent must be able to confirm availability and price before it books.
Are your cancellation policies machine-readable? Deadlines and penalties an agent can parse, not a paragraph of terms.
Are you fast enough? Agents abandon after roughly two seconds; the verified retail median is 156ms. How we measure →
Watch an agent break. Run a frontier model through your booking flow and see what it does when an offer expires mid-session — because our data says it will not check.

Two waves: now, and when the spec drops

The spec is "coming soon," and the language suggests weeks, not months. This piece is the first wave — the prescriptive read from the announcement and the data. When the actual UCP for Lodging spec lands, we will publish the side-by-side: what we said it needed versus what Google shipped, with conformance checks against the first live lodging endpoints. If you want that the day it is ready, set up alerts.

What we're watching

Whether the published spec models offers as time-boxed objects with all-in pricing; which waitlist partners ship a live endpoint first; whether cancellation and servicing make the first cut or get deferred; and — the one we will keep testing — whether agents stop being blind to time. We track the ecosystem monthly in the State of Agentic Commerce census, and we will report what the data shows, not what the page promises.

Sources

Google for Developers — UCP for Lodging
Google blog — Shopping updates from Marketing Live
Our analysis — Agentic AI in Travel: Why UCP Isn't Travel-Ready Yet and Google Universal Cart & UCP
Our testing — We Tested 5 AI Models on Expiring Travel Inventory

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and test how real AI agents behave against real stores. We track spec and ecosystem events — retail today, travel and lodging as they arrive — as they ship.

Check your store or booking endpoint: ucpchecker.com/check
Grade it (UCP Score): ucpchecker.com/score
Validate your catalog: ucpchecker.com/catalog-validator
Browse the directory: ucpchecker.com/directory
Get the side-by-side when the spec drops: ucpchecker.com/alerts

Lodging is the hardest booking an agent will attempt. We will be measuring it.

Retail merchant figures are live from the UCP Checker index and update every 24 hours; agent-testing methodology is on our methodology page.

Agentic AI in Travel: Why UCP Isn't Travel-Ready Yet — and What We Measured

Benji Fisher — Fri, 22 May 2026 14:51:28 +0000

In a new post, Amadeus — the system of record behind roughly 3 billion flight searches a day, 400-plus airlines and 2 million hotel properties — laid out its read on agentic AI in travel. The headline from CTO Sylvain Roy: protocols, not chatbots, are what make agentic travel work, and the protocols that exist today are not ready. MCP, he argues, is "only a first step"; the Universal Commerce Protocol "could open large new distribution and conversion opportunities" but remains "largely retail-native and is still in the process of being adapted to handle the full complexity of travel."

He is right — and we can put data behind it. Before Amadeus weighed in, we built a mock travel server with expiring offers and pointed five frontier models at it. Not one checked an offer's time-to-live before booking. Only one survived a three-second expiry window. None flagged a price change unless explicitly asked. Travel's defining feature — perishable inventory priced in real time — is precisely where today's agents fall over.

So here is the state of play from the monitoring seat: travel's supply side just showed up to UCP, but the demand side cannot reliably transact on it yet, and the protocol needs travel-specific work before it can. This is the read on agentic commerce's hardest vertical. Our bias throughout: we saw it in the data first.

What just happened: travel's supply side standardized on UCP

Two signals landed in quick succession. At Google Marketing Live 2026, Google extended UCP into hotels and local food delivery, naming a launch roster that reads like the entire travel-distribution stack: Accor, Amadeus, Booking.com, Choice Hotels, Expedia Group, Hilton, IHG, Marriott, Trip.com and Wyndham. Booking a hotel "right from AI Mode in Search" is the demo. (We covered the full package — Universal Cart, multi-item checkout, BNPL and the rest — separately.)

Then Amadeus published its position. Notably, it is not an adoption announcement. Roy frames Amadeus as the "embedded and neutral execution layer for travel" and says it is ready to collaborate on travel-ready agentic protocols — but commits to no UCP timeline. The subtext is the honest one: the supply side is interested, the rails are forming, and nobody is claiming travel is solved.

Why travel is agentic commerce's hardest vertical

Retail is, relatively, simple: a product has a fixed SKU, a stable price and a quantity. Travel has none of those guarantees. Amadeus calls out five gaps, and each is a place a retail-native protocol strains.

Dynamic offers, not fixed SKUs. A flight or room is not a catalog entry — it is a dynamically generated Offer ID built from origin, destination, dates, fare family, ancillaries and disruption rules. There is no stable identifier for an agent to drop in a cart and trust.
Perishable inventory, real-time pricing. Availability and price change by the second, with no true SKU equivalent. An offer an agent saw thirty seconds ago may already be gone or repriced.
Complex servicing. Changes, cancellations and disruption handling demand full request context, and the stakes of getting it wrong are far higher than a returned T-shirt.
Identity, settlement and regulation. Multi-party fulfillment, traveler identity verification and compliance obligations ride on every booking.
Data quality and control. Personalization needs traveler context shared across parties while suppliers keep visibility and control of it.

UCP models the retail case well — fixed catalog, cart, checkout, payment handlers. (New to how UCP sits next to MCP and AP2? We break the stack down here.) Travel needs primitives the retail spec does not have yet.

The data: agents are blind to time

The perishable-inventory and real-time-pricing problems are not theoretical. They are measurable, and we measured them.

We built a mock travel server that issued offers with explicit expiry windows and ran five frontier models against it across 21 sessions. The results were stark: not one model checked an offer's TTL before attempting to book; only one survived a three-second expiry window; none surfaced a price change unless we asked. The agents treated time-sensitive travel inventory exactly like a static retail SKU — and that is the failure mode that turns a "confirmed" booking into a charge for an offer that no longer exists.

The same blindness shows up on the retail side. Across 33 sessions on a live store, only two of five models caught a stale price even when handed yesterday's number — and the deeper problem was structural: the merchant data layer did not expose temporal metadata at all. A model cannot reason about expiry if nothing in the stack tells it the offer expires.

That is Amadeus's "perishable inventory" and "live search at scale" challenges, observed in production. The protocol that wins travel has to carry time — TTLs, price-as-of timestamps, re-validation before commit — as a first-class signal, and agents have to be built to respect it. Neither is true today.

Retail-native, not travel-ready: what UCP still needs

The encouraging part is that UCP is extensible by design. The spec grows through capability extensions — the Technical Council has been adding cart, order, loyalty and identity primitives since launch. Travel is simply the next, harder extension surface. From the gaps above, the shortlist:

A dynamic-offer primitive — an offer object carrying a TTL and a price-validity window, replacing the assumption of a stable SKU.
Re-validation in the checkout flow — an agent must confirm the offer is still valid and still the quoted price before it commits.
Servicing capabilities for change, cancel and disruption, with enough context to handle them safely.
Identity and settlement extensions for multi-party, regulated fulfillment.

Concretely, the dynamic-offer primitive looks something like this — a travel offer that carries its own clock:

{
  "offer_id": "LHR-NRT-20260612-A1F2",
  "price": { "amount": 842.00, "currency": "USD" },
  "ttl_seconds": 3,
  "price_valid_until": "2026-06-12T19:30:03Z",
  "revalidate_before_checkout": true
}

A retail SKU carries none of those fields, and that is the whole problem: nothing tells an agent the offer it is holding has already expired. None of these are exotic. They are the difference between a protocol that can sell a tote bag and one that can sell a Tokyo itinerary. And the backers are aligned to build them: the companies behind UCP — Google, Shopify, Amazon, Microsoft, Meta, Stripe and Salesforce, the group whose Technical Council recently expanded — now have the travel-distribution establishment at the table.

What it means

For travel suppliers (airlines, hotels, OTAs, GDSs): being named at a keynote is not the same as being agent-ready. The supply side is forming the rails, but the offer, pricing and servicing semantics that make travel safe for agents are not in the published spec yet. The window to shape those primitives — rather than inherit retail's — is open now, and Amadeus is signalling it wants in.

For demand-side players (agents, assistants, AI shopping surfaces): do not ship autonomous travel booking on retail assumptions. Our data says agents will book expired offers and miss price changes unless both the protocol and the agent treat time as first-class. Until travel primitives land, keep a human on the commit step.

For the ecosystem (us): we do not yet monitor live travel UCP endpoints — there are not any in production to monitor. What we can measure today is the agent side, and we have shown the gap is real. As travel manifests go live, the same validation, scoring and monitoring we run across more than 6,500 retail merchants — tracked monthly in the State of Agentic Commerce census — will extend to them. The neutral measurement layer travel is asking for is the one we already operate.

What we're watching

Whether the Technical Council opens a travel working group or a dynamic-offer extension; which of the GML travel partners ships a live, parseable endpoint first; whether Amadeus moves from "ready to collaborate" to a concrete commitment; and — the one we will keep testing — whether the next generation of models stops being blind to time. We will report what the data shows, not what the slides promise.

Sources

Amadeus — Agentic AI in travel: why MCP and UCP standards matter (Sylvain Roy, CTO)
Google blog — Shopping updates from Marketing Live
Our testing — We Tested 5 AI Models on Expiring Travel Inventory

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and test how real AI agents behave against real stores. We track spec and ecosystem events — retail today, travel as it arrives — as they ship.

Check your store: ucpchecker.com/check
Grade it (UCP Score): ucpchecker.com/score
See capability coverage: ucpchecker.com/capabilities
Browse the directory: ucpchecker.com/directory
Get notified when an endpoint changes: ucpchecker.com/alerts

Travel is the hardest test agentic commerce has set itself. We will be measuring it.

Retail merchant figures are live from the UCP Checker index and update every 24 hours; agent-testing methodology is on our methodology page.

Shopify Just Shipped a UCP CLI. It Buys Anywhere — But Only Finds Shopify.

Benji Fisher — Thu, 21 May 2026 17:09:41 +0000

On May 18, 2026, Shopify published @shopify/ucp-cli to npm — a command-line tool and MCP server it describes as "a shopping skill for AI agents, powered by the Universal Commerce Protocol." Within days it's at v0.5.0, MIT-licensed, open on GitHub. The pitch, from Ilya Grigorik's launch post: millions of Shopify merchants natively speak UCP, billions of products are discoverable through a global catalog, and now any agent can learn to shop them with two commands:

npm install -g @shopify/ucp-cli
ucp skills add

The CLI shipping is not the interesting part. A reference client for a maturing protocol was always coming. The interesting part is that @shopify/ucp-cli is really two tools wearing one binary — and only one of them leaves Shopify. One layer is pure, platform-neutral UCP that will transact against any conformant merchant on any stack. The other is a discovery engine hardwired to Shopify's own catalog. Pull them apart and you get a clear read on where the protocol is genuinely open today, and where the gravity still pulls toward the platform with the biggest index.

What shipped

@shopify/ucp-cli is agent-first by design. Every command takes and returns structured JSON, so a model can compose payloads and parse results without scraping human-readable output. ucp skills add installs a bundled SKILL.md — the operating manual that teaches an agent when to search versus discover, how to render totals, how to surface required disclosures, and when to hand off to a human. The full command surface mirrors the UCP shopping service:

ucp catalog search / catalog lookup / catalog get_product — find products
ucp cart create | update | get | cancel — build a cart with confirmed pricing
ucp checkout create | update | complete | cancel — convert and pay
ucp order get — post-purchase status
ucp discover --business <url> — ask a store what it actually supports

Two design choices stand out. First, live introspection: ucp discover and --input-schema make real network calls to the merchant, not static doc lookups. The agent composes against whatever the merchant advertises right now — including extensions added since it last shopped there. Second, every response carries a cta — the CLI tracks where you are in the flow and returns the next-best commands as structured recommendations, so the agent doesn't have to memorize the operating model. There's also a configurable escalation hook (UCP_ON_ESCALATION) for the moments a merchant needs the human back in the loop.

It's a genuinely well-built piece of agent tooling. Which is exactly why the boundary inside it is worth tracing.

Two layers, two answers

The question that matters for everyone who isn't Shopify: does it work outside Shopify? The honest answer is that the CLI has two layers, and they answer differently.

The transaction layer is pure UCP

Cart, checkout, order, and per-merchant catalog operations route through the generic dev.ucp.shopping service. There is no Shopify branching in the dispatch path. When you pass --business https://store.example.com, the CLI fetches that store's /.well-known/ucp profile, negotiates a compatible protocol version and transport, and dispatches against the endpoint the merchant advertises — exactly as the spec describes. The capabilities it negotiates against are the neutral ones on ucp.dev:

dev.ucp.shopping.checkout   → ucp.dev/2026-04-08/schemas/shopping/checkout.json
dev.ucp.shopping.cart       → ucp.dev/2026-04-08/schemas/shopping/cart.json
dev.ucp.shopping.catalog.*  → ucp.dev/2026-04-08/schemas/shopping/catalog_*.json
dev.ucp.shopping.order      → ucp.dev/2026-04-08/schemas/shopping/order.json

That means a WooCommerce, Magento, BigCommerce, or fully custom store that publishes a valid UCP profile can be carted and checked out by this CLI today. The README says as much in plain language: build carts and complete checkouts "against any UCP-supporting merchant." The transaction layer is real, standards-based, and platform-neutral.

The discovery layer is Shopify

Now run ucp catalog search with no --business. Where does it go? Straight to a hardcoded default:

// package.json
"ucp": {
  "default_catalog_url": "https://catalog.shopify.com"
}

The "search across millions of merchants" headline resolves against catalog.shopify.com. And the catalog tools aren't even part of core UCP — they're surfaced through two Shopify-namespaced extensions, dev.shopify.catalog and dev.shopify.catalog.global, with schemas served from shopify.dev, not ucp.dev. The results name their sellers as *.myshopify.com domains. (The bundled skill even warns agents to check variants[*].seller.domain rather than trust the brand in a product title — a Keychron keyboard in the global catalog might be sold by a third-party Shopify reseller, not Keychron itself.)

So the asymmetry, stated plainly:

Layer	Scope	Backed by
Discovery (`catalog search`, no `--business`)	Shopify merchants only	`catalog.shopify.com`, `dev.shopify.catalog.global`
Transaction (`--business <url>`)	Any UCP merchant, any platform	generic `dev.ucp.shopping`, `ucp.dev` schemas

It can buy anywhere. It can only find Shopify. To transact with a non-Shopify store, an agent has to already know that store's URL — the CLI will happily check out there, but it will never surface the store in a search.

One smaller detail for implementers: the CLI negotiates a protocol range of 2026-01-23 to 2026-04-08 — the same dated releases — and it doesn't speak the working-draft "draft" version. Reference tooling is tracking published spec versions, not main.

Why discovery is the layer that's hard to open

This isn't a knock on Shopify, and it isn't an oversight. It's structural. A transaction is a one-to-one conversation; discovery is an index.

Standardizing a checkout means agreeing on a message shape between two parties who already found each other. UCP does that well, and the CLI proves it — point it at any conformant endpoint and it works. But standardizing discovery means someone has to build and host the index of who sells what, keep it fresh, and serve it at query time. That is expensive, and it accrues to whoever already has the catalog. Shopify has millions of merchants and their product data in one place, so a Shopify-backed global catalog is the path of least resistance — for Shopify.

The consequence is that as agent commerce matures, the transaction layer commoditizes while discovery concentrates. The protocol gives every merchant an equal ability to be transacted with. It does not, on its own, give every merchant an equal ability to be found. That gap isn't in the spec — it's in who builds the index on top of it.

What it means in practice

For Shopify merchants: you're discoverable by default. Your products sit in the global catalog an agent searches before it knows which store to visit, with no work on your part. That's a real distribution advantage, and it's the clearest argument in the launch.

For non-Shopify merchants (WooCommerce, Magento, BigCommerce, and custom stacks): your UCP endpoint works fine with this CLI — an agent that has your URL can cart and check out against you today. But you will not appear in the default catalog search. Conformance buys you transactability; it does not buy you discoverability inside a Shopify-owned index. If agent-driven discovery matters to your channel, you need to live in a catalog or directory that spans platforms — and you need your manifest to actually be valid, because an agent that can't parse your profile can't transact with you no matter how it arrived. (Run a check.)

For agent builders: treat the global catalog as a Shopify discovery surface, not a universal one. It's an excellent default for "find me X" with no merchant named. For cross-platform coverage you'll need to bring merchant URLs from elsewhere and lean on discover --business. The transaction primitives are solid and genuinely portable; the discovery primitive is platform-scoped. Plan your retrieval layer accordingly.

For evaluators (us): this sharpens why we run an independent, cross-platform directory. We index UCP merchants by verification — does this domain serve a valid, working manifest — not by membership in any one platform's catalog. The WooCommerce and Magento long tail that a Shopify global catalog structurally can't surface is exactly the part of the ecosystem we track. We measured the platform split in our readiness data and revisit it every month in the State of Agentic Commerce census; a Shopify-only discovery default is a meaningful shift in how that long tail gets found.

Where to read more

The package: @shopify/ucp-cli on npm
The source: github.com/Shopify/ucp-cli
The bundled agent skill: skills/ucp/SKILL.md
Shopify's global catalog extension: global-catalog-extension
How the three protocol layers fit together: MCP vs UCP vs AP2

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate, and grade every public UCP manifest we can find — across Shopify, WooCommerce, BigCommerce, Magento and beyond — and run the cross-platform merchant directory, the UCP Score, and the adoption stats.

If you want to know whether agents can actually transact with your store, on any platform: run a check. If you want to catch the moment your store's UCP support changes — a platform update, a spec bump, an endpoint breaking silently — set up UCP Alerts.

How to Test Your UCP Implementation with AI Agents

Benji Fisher — Fri, 15 May 2026 09:11:04 +0000

You ship a UCP manifest. The validator returns green. The schema parses cleanly. Every required field is present, every URL resolves, every transport responds. You declare the work done and move on.

Three weeks later, you find out your store has been quietly failing every agent shopping session. The cart endpoint accepts adds but rejects checkouts. A specific variant ID throws a 400 on update_cart. The agent reaches ready_for_complete and stalls because your payment handler doesn't recognise the token format. None of these issues showed up in static validation. All of them block real users on agent-mediated flows.

This post is about how to actually test your UCP implementation — not as a schema document, but as a runtime surface that real frontier agents have to operate against. The short version: schema validation is necessary but not sufficient. The long version is the rest of this post.

What validators catch and what they miss

A UCP validator (including ours, the validator at ucpchecker.com/ucp-validator) checks structural things:

Manifest is valid JSON
Required fields are present (spec, services, signing_keys, etc.)
Declared spec version is one we recognise
Transport endpoints return non-error responses
Schema URLs resolve
Capability namespaces match the spec catalogue

Those are the things you can verify without actually running an agent flow against the store. They're table-stakes, and the UCP Score bakes them into the structural-conformance dimension of its grade.

What static validation doesn't catch:

Whether update_cart rejects valid variant IDs intermittently
Whether the cart endpoint's success response contains the line items it claims to contain
Whether the checkout flow surfaces the buyer-specific payment instruments your customer can actually use
Whether your search_catalog returns more than 8 KB of HTML in a description field that crashes Claude's tool-calling layer
Whether two different models pick the same variant ID for "Medium" against your product (the variant-data problem we cover separately)
Whether the agent can recover when one of your tool calls returns a 500 mid-flow

These are runtime properties. They only surface when you run an actual agent against an actual checkout. And they're where the gap between "store passes validation" and "agent can buy" lives. The April State of Agentic Commerce report sized that gap concretely: of 4,014 verified UCP stores, only 9 delivered a flawless end-to-end agent experience. A 0.2% flawless rate against a 98%+ conformance rate. The runtime gap is the gap.

The three-layer testing pyramid

The right way to test UCP is not "validator or no validator" — it's three layers, each catching a different class of problem, in increasing order of cost and fidelity:

Layer	Tool	Catches	Cost
1. Schema validation	`/ucp-validator`	Manifest parse errors, missing required fields, malformed URLs	seconds, free
2. Capability score	`/score`	Surface signals, declared capabilities, transport reachability, robots/sitemap hygiene	seconds, free
3. Live agent eval	UCP Playground	Variant resolution, cart/checkout shape, error recovery, multi-model behaviour, attribution flow	dollars per session, paid

Each layer feeds the next. If layer 1 fails, layer 2 has nothing to score. If layer 2 reports gaps, layer 3 will find them magnified in real agent runs. Skipping layers wastes layer 3's time on bugs the cheaper layers would have caught — that's the case for running them in order rather than going straight to live agents.

Most teams stop at layer 2. Stopping at layer 2 is what produces the 99.8%-conformant / 0.2%-flawless gap. A clean Score gets you to "the agent has a fair chance." A clean Score plus a clean eval gets you to "the agent reliably completes the flow you care about."

What live agent testing actually looks like

Layer 3 is where most readers are unfamiliar, so this section walks through what running an agent test against your own store actually involves.

The shape: you point a frontier agent (Claude, GPT, Gemini, Grok, Llama — whichever model you want to evaluate against) at your store's UCP manifest endpoint and give it a multi-turn shopping prompt. The agent does what an agent does — discovers your tools via the manifest, calls search_catalog against your products, evaluates the results, picks something, calls update_cart, navigates checkout. The framework records every tool call, every response, every model decision, the full token-by-token event stream.

At the end of the session you get a structured report:

Did the agent reach checkout_reached (full transaction completion)?
Or did it stop at cart_created, search_only, or failed?
How many tool calls did it make? How many succeeded? Which ones errored?
How many tokens did the model consume?
How long did the session take?
If the agent failed, why?

That's the data layer 1 and layer 2 can't produce. Schema validation tells you what your store says; agent eval tells you what an agent does with what your store says. They're answering different questions.

For most stores, the first eval session is uncomfortable. The agent picks the wrong variant. Or it adds something to the cart and then stalls because the response shape isn't quite what it expected. Or it reaches ready_for_complete and can't move forward because your payment-handler declaration doesn't match what the agent has been trained to handle. Each of those is a fix you can make, and each fix lifts your real conversion rate the next time an actual user-facing agent shops your store.

Why testing on one model isn't enough

A useful pattern from the Playground 1,000-session dataset: the same store gets meaningfully different outcomes across different models. A store that completes checkout 65% of the time on Claude Sonnet 4.5 might complete only 18% of the time on GPT-5.2 — the same UCP implementation, the same shopping prompt, just a different model.

That spread isn't because one model is "better." It's because each frontier model has its own quirks in how it handles tool calls, schemas, error responses, and ambiguous data. Models differ on:

How they handle empty arrays vs missing fields
Whether they follow up on a 4xx response or move on
How aggressively they retry failed tool calls
How they parse multi-line strings in description fields
Whether they pass through optional metadata fields verbatim

The real-world implication: your customers don't all use the same agent. Some use ChatGPT-routed flows; some use Anthropic's; some use Google AI Mode; some use a custom agent built on Llama. Testing against just one model means catching only the bugs that one model surfaces, while shipping silent failures to everyone using a different one. Multi-model coverage is what gets you from "this passes for our internal demo" to "this works for real customer traffic."

UCP Playground supports head-to-head testing across 15+ frontier models. The comparison view lets you run the same store against any two models on the same workload. We'd suggest at minimum testing against:

One Anthropic model (Claude Opus or Sonnet)
One OpenAI model (GPT-5.2 or GPT-4o)
One Google model (Gemini 3.1 Pro or 2.5 Flash)

Three models cover most of the deployed-agent universe. If any of the three behaves badly against your store, you have a real problem worth fixing before more traffic arrives.

Wiring tests into your deploy pipeline

Manual eval is fine for one-off audits. If you're shipping changes regularly, you want this in CI. The Playground exposes a headless API for exactly that:

POST /api/v1/collections          — define a test (sequence of prompts + models + stores)
POST /api/v1/collections/{id}/run — trigger the test
GET  /api/v1/collection-runs/{id} — poll status + results

The pattern most teams ship first: a deploy-time test that triggers an eval after every UCP-related code change, asserts on key metrics, and fails the build if any of them regress. A reasonable assertion shape:

# .github/workflows/ucp-eval.yml
- name: Run UCP eval
  run: |
    curl -X POST $PLAYGROUND_API/v1/collections/$COLLECTION_ID/run \\
      -H "Authorization: Bearer $PLAYGROUND_TOKEN"
    # Poll, then assert:
    # - checkout_rate >= 80
    # - errors.total == 0
    # - avg_duration_ms < 30000

Same shape as Lighthouse CI for web performance. A regression catch you bolt onto your pipeline rather than rediscover in production. The UCP Playground Evals launch post walks through the full pattern with a worked example.

The order to do this in

If you're starting from a fresh UCP implementation:

Run the validator against your manifest. Fix any structural errors. This is the cheapest layer; do it first.
Get a UCP Score for your domain. Aim for B+ (70+) before moving to live testing. Below that, you have surface-level gaps that'll dominate the eval results and waste your test budget.
Run a Playground eval against your store with two different frontier models on a single shopping sequence. Fix whatever fails. Common first-time failures: variant-data ambiguity, response-shape inconsistencies, tool argument validation.
Expand to three models once your single-model baseline works. Multi-model coverage is what catches the long-tail issues.
Wire the eval into CI once your implementation is stable. From this point on, every code change that touches UCP runs against real agents before it ships.

If you've already got a UCP implementation in production and are trying to figure out why agents aren't completing checkouts, skip step 2 and go straight to step 3. The eval will show you the specific failure mode, and you can backfill the score work later.

What good looks like

A store that's passed all three layers cleanly looks like this:

Validator: green
Score: A grade (85+) across Discovery, Conformance, and Capability Coverage
Eval: 80%+ checkout rate against Claude Sonnet 4.5, Gemini 3 Flash, and one other model of your choice; <5s average tool-call latency; zero categorised errors across at least 20 sessions

That's the bar. The State of Agentic Commerce is tracking how many stores hit that bar — currently fewer than 1% of verified stores. The work to get from 99% conformance to 1% bar-clearing is mostly testing work.

Try it

Validator (free, instant): ucpchecker.com/ucp-validator
Score (free, instant): ucpchecker.com/score
Live agent eval (paid per session): ucpplayground.com/evals
Multi-model comparison view: ucpplayground.com/models
CI-ready eval API: documented at ucpplayground.com

Schema validation is necessary. It is not sufficient. The agents your customers use will run real flows against your store, and the only way to know whether those flows succeed is to run them yourself first.

Test before they do.

The State of Agentic Commerce — May 2026

Benji Fisher — Thu, 14 May 2026 09:45:37 +0000

In April, the story was a platform pulling a lever: Shopify migrated its entire UCP fleet to v2026-04-08 in four days, BigCommerce showed up with three stores, and we said the question for May was which platform ships next — because every prior jump in the directory had been a step function caused by a platform-level deployment.

May's answer: none, and it didn't matter. No platform shipped a UCP wave this month. BigCommerce still has three verified stores. WooCommerce still has three. Salesforce Commerce Cloud still has none verified, though a custom build is reportedly in development. And the directory still grew ~32% — the same rate as April — because the baseline discovery rate stepped up. For the first time since we started this report, UCP grew on a slope instead of a staircase.

This is the fourth monthly state-of-the-ecosystem report from UCP Checker. Here's what the data says as of May 12, 2026.

The numbers

5,294 verified UCP stores (up from 4,014 in April, +32%)
5,892 total domains tracked
1,829 new merchants discovered this month; 775 this week alone
5,264 verified stores on the latest v2026-04-08 spec (99.4%)
5,235 verified stores at A grade on UCP Score (98.9%)

Three consecutive months of ~30% growth is a real curve now, not a launch artifact. But the shape changed. February was discovery (first 1,000 Shopify stores). March was expansion (crossed 3,000, first non-Shopify manifests). April was consolidation (the four-day Shopify spec migration). May is the first month where the headline growth came from neither a new platform nor a spec event — it came from crawler optimisations we shipped in early May. The stores were always out there; we just got faster at finding them.

That distinction matters for forecasting. If May's growth had been platform-driven, you'd model the next jump as "wait for SFCC." Since it's discovery-rate-driven, the model is different: the directory keeps filling at a steady clip until either we exhaust the discoverable Shopify long tail, or a platform finally ships a wave and the staircase resumes. Both will happen; the order is the open question.

Shopify's head start, four months in

Platform	Monitored	Verified	Verified %	Avg score (verified)	Avg manifest latency
Shopify	5,242	5,241	~100%	92.5	178 ms
Custom & Headless	642	45	7.0%	83.0	356 ms
WooCommerce	3	3	100%	92.3	1,023 ms
BigCommerce	3	3	100%	88.3	993 ms
Magento	1	1	100%	85.0	218 ms
PrestaShop	1	1	100%	84.0	548 ms

Shopify is 99% of the verified directory — unchanged from April. Every non-Shopify platform combined sums to 53 verified stores, the same as last month. The head start is still the dominant signal in the data, and the Custom & Headless cohort is the mirror image: 642 domains attempted UCP, only 45 got to verified (a 7% completion rate). When a platform hands you the boilerplate, you compound; when you build it yourself, most attempts stall before validation. That's a tooling gap, not a spec problem.

The more interesting movement came from two more platforms shipping UCP support — Bareconnect and Selly.io — both of which already have verified stores live in the directory today, not roadmap promises. The numbers are still small. How either platform is exposing UCP (default for every storefront, opt-in, or a paid tier) decides whether this stays a handful or turns into a wave — that detail we don't know yet. But it's the first new platform movement since the Shopify migration.

Two structural notes on the table. BigCommerce and WooCommerce manifests run ~1 second versus Shopify's 178 ms because they're served from the storefront origin rather than a CDN-cached endpoint — a meaningful handicap as agent response budgets tighten. And geographically the directory is still a US/.com story: 4,720 of 5,294 verified stores ship under generic TLDs; the largest attributable ccTLD cohorts are .uk (229), .au (120), and .ca (66); continental Europe is under 2% by ccTLD (a floor, not a true distribution).

Capability coverage: the ceiling, and the edges

Capability	Verified adopters
`dev.ucp.shopping.checkout`	5,269
`dev.ucp.shopping.fulfillment`	5,264
`dev.ucp.shopping.catalog.lookup`	5,257
`dev.ucp.shopping.catalog.search`	5,256
`dev.ucp.shopping.order`	5,256
`dev.ucp.shopping.discount`	5,253
`dev.ucp.shopping.cart`	5,249
— the cliff —
`dev.ucp.common.identity_linking`	6
`dev.ucp.shopping.buyer_consent`	3
`dev.ucp.shopping.checkout.embedded`	2
`dev.ucp.shopping.ap2_mandate`	1
`dev.ucp.shopping.payment`	0

Identical pattern to March and April: the seven core shopping capabilities ship together as a Shopify-side bundle (~5,250 adopters each), then an 800× cliff. Identity linking: 6. AP2 mandate — the primitive that makes an agentic transaction auditably user-authorised — still 1 (houseofparfum.nl, WooCommerce, scoring 100). Payment capability: still 0. Of 5,294 verified stores, 5,161 (>99%) sit at Tier 2, one is Tier 3, one is Tier 4. The deeper primitives aren't slow-adopting, they're not adopting yet. When demand for AP2 turns into pressure (regulators, payment networks, the working group's eventual requirements), this number moves fast — the way checkout did once Shopify bundled it. Until then, "UCP store" means "agent-shoppable," not "mandate-credentialed."

Where the movement was: the edges of the spec

The new signals in May's data sit at the edges of the spec rather than its core. The first is in the capability namespace itself: below the standard dev.ucp.* entries, a handful of non-standard, vendor-prefixed capabilities are now appearing on real verified manifests:

com.pwc.accelerator.loyalty.rewards — 2 stores. PwC's agentic-commerce accelerator (more below).
com.appointedd.schedule / .booking / .intent — 1 store. Appointment-scheduling primitives — booking-vertical UCP, not retail.
com.woocommerce.ai_storefront — 1 store. A WooCommerce-specific storefront extension.
sh.agentscore.identity — 1 store. An identity primitive from a third party.
com.agoragentic.x402.checkout — 1 store. A checkout extension referencing x402 (the HTTP-402 micropayment pattern).

None is adopted at scale yet — 1–2 stores each, almost certainly vendors' own test deployments — but it's the first month the namespace long tail has held anything other than Shopify defaults. It's the leading indicator of a UCP extension ecosystem: third parties shipping vertical capabilities (loyalty, booking, identity, micropayments) on top of the core spec, a more realistic near-term diversification path than "another commerce platform ships a wave."

The PwC entry is worth pulling out, because it isn't a platform — it's a consultancy. PwC has launched an agentic-commerce accelerator: a practice that stands up custom UCP-enabled storefronts for enterprise clients, with its own capability extensions (the com.pwc.accelerator.* namespace) layered on the core spec. That's a third adoption channel, distinct from "platform ships a wave" and "developer hand-builds" — call it consulting-led. It's slower per engagement, but each accelerator that standardises on UCP arrives with a portfolio of enterprise clients attached. PwC is the leading edge; Deloitte, EY, KPMG, Accenture, McKinsey, BCG, and the systems integrators (Capgemini, IBM, TCS, Infosys) all face the same build-it-once, deploy-to-many incentive.

Transports and payment handlers: the monoculture, and the experiments tier

Transport	Verified declarations
MCP	5,258
Embedded	5,243
REST	47
A2A	2

MCP and Embedded are universal because Shopify declares both. REST shows up on 47 stores — the non-Shopify hand-builds, REST being the natural fit for anyone implementing without an MCP server. A2A (Google's Agent2Agent transport, formally added in v2026-04-08) holds at two. Payment handlers tell the same monoculture story: 5,250 verified stores declare Google Pay and 5,241 declare Shopify Card — the same shared Shopify-managed handler IDs we flagged in February as a single point of failure. Everything else is a rounding error. The payment partner ecosystem (Stripe, Adyen, Visa, Mastercard, PayPal, Affirm, Splitit — all on the registry) is mature on paper; the live handler declarations are two Shopify-managed IDs and a handful of experiments.

The experiments are the part worth zooming in on, because the same small set of builders is populating the spec's newer transport, its newer handler shapes, and its newer capability namespaces simultaneously. Both A2A adopters are agent-native rather than retail: one is an agent-identity storefront running pure A2A with a cryptographically signed manifest (JWS / EdDSA) and two custom payment handlers on crypto rails — an mpp rail on Tempo mainnet and an x402 rail on Base; the other is an agent-to-agent service exposed across MCP + A2A + REST, selling a USDC-priced audit via a com.agoragentic.x402 handler plus a direct USDC receive address. Both ship the custom capability namespaces flagged in the capability section above (sh.agentscore.identity, com.agoragentic.x402.checkout).

Separately, payment processors are starting to run dev UCP endpoints with fully custom handler integrations — their own handler IDs, their own init / verify protocol shapes, declared at v2026-04-08 over REST against real merchants, iterating against the Checker as they build. Still dev, not live, but for the first time the gap between the partner roster and the live handler declarations has something in it that's neither Shopify-default nor mock fixture — and it's coming from processors with the scale to move real merchant bases. Two data points in each direction don't make a trend, but the pattern is coherent: the spec's newer surfaces (A2A transport, custom handler shapes, third-party namespaces) are populated by a small set of builders doing novel work in parallel, while the core carries volume. That's the shape of a protocol leaving its launch phase.

How agents actually perform

The numbers above tell you which stores have UCP. This section is which stores work when an agent shops them. UCP Playground Evals passed 1,000 recorded agent sessions this month — and it's well past that now: a thousand-plus end-to-end agent shopping runs across 105 unique stores and 16 frontier models, totalling ~57M tokens, ~12 hours of cumulative agent runtime, and roughly $119,000 in aggregate cart value.

Outcomes: where the agent stops

Outcome	Sessions	Share
`checkout_reached`	475	37.9%
`search_only` (browsed, didn't cart)	344	27.4%
`failed` (provider error, refusal, max turns)	261	20.8%
`cart_created` (carted, didn't proceed)	172	13.7%

62% of sessions end without a completed checkout — and that ratio has stayed stable as the dataset grew, which is itself the finding. As we add models and stores, the shape of failure doesn't change: agents find products fine (search works nearly everywhere), build carts often, then ~14% of sessions stall at a cart that won't convert and ~21% fail outright (about half of those are variant-shape problems — the agent picks a variant ID the cart rejects and flails until it hits the turn limit). We dug into exactly that this month in UCP Variant Data: The #1 Reason Agent Checkouts Fail — the single largest categorisable cause of the gap between "has a manifest" and "agent can buy from it," and almost entirely fixable in the merchant's variant data without touching any tooling.

Model leaderboard

Checkout-conversion rate by model, from the UCP Playground model leaderboard — sessions where the agent reached a checkout URL ÷ total sessions for that model (the live leaderboard breaks out search, cart, and speed too):

Model	Sessions	Checkout %	Avg session	Vendor
Claude Sonnet 4.5	256	52.0%	~38 s	Anthropic
Llama 3.3 70B	75	49.3%	~48 s	Meta
DeepSeek V3.2	60	45.0%	~46 s	DeepSeek
Gemini 3 Flash	174	42.0%	~21 s	Google
Grok 4	53	39.6%	~77 s	xAI
Claude Opus 4.6	123	39.0%	~30 s	Anthropic
Gemini 2.5 Flash	125	36.0%	~12 s	Google
GPT-4o	63	31.7%	~15 s	OpenAI
Gemini 3.1 Pro	96	29.2%	~48 s	Google
Gemini 2.5 Pro	79	27.8%	~34 s	Google
GPT-5.2	63	20.6%	~36 s	OpenAI
DeepSeek R1	19	15.8%	~60 s	DeepSeek
o4-mini	21	14.3%	~42 s	OpenAI
Grok 3 Mini	21	9.5%	~57 s	xAI
QwQ 32B	25	0%	~61 s	Alibaba

Three things hold from April, plus one shift:

Search works everywhere. Checkout completion is the next frontier. Every model that runs to completion finds products. Checkout conversion ranges from 0% to 52% — a 50-point spread across the field, which is exactly where the work-to-do sits. The best model in the field completes checkout about half the time today; the headroom from there is the frontier the next quarter gets to push.

Reasoning-tuned models still underperform. QwQ 32B: 0% across 25 sessions. Grok 3 Mini: 9.5%. o4-mini: 14.3%. DeepSeek R1: 15.8%. Models that burn tokens on deliberation struggle with the fast, sequential, low-ambiguity tool-calling that shopping requires. Shopping rewards decisive, not thoughtful — true in April, true with 3× the data. (GPT-5.2 also lands below the median at 20.6%.)

Speed and success are decoupled. Gemini 2.5 Flash finishes a session in ~12 seconds; Grok 4 takes ~77. Their checkout rates are 36% and 40% — basically a wash. Being fast doesn't make you good at this; being slow doesn't either. The Claude models sit mid-pack on speed (~30–38 s) and top on conversion, which is the combination that actually matters when the agent is spending someone's money.

The shift: in April we reported DeepSeek V3.2 leading the composite shopping score. With ~3× the sessions, Claude Sonnet 4.5 is now clearly out front on checkout completion — 52% over 256 sessions, by far the largest sample — with Meta's Llama 3.3 70B the surprise second. Treat any single month's ranking as provisional until the eval dataset gets to the point — soon — where it stops being indicative and becomes authoritative.

The reliability gap, one more time

We've made this the editorial spine of every one of these reports, and the May data doesn't let us retire it. 98.9% of verified stores carry an A on UCP Score (5,235 of 5,294; the rest are 57 B's and two C's). By conformance, the directory is in excellent shape. But conformance isn't end-to-end agent-readiness, and that's the gap UCP Score doesn't grade.

A clean schema doesn't tell you whether the cart endpoint accepts the variant the agent picked, whether response-time budgets hold under load, whether payment-handler tokenisation completes inside the agent's timeout window, or whether the checkout URL drops the agent into an auth loop a browser would have handled with cookies. UCP Playground is the test harness developers use to exercise that second layer — replay sessions, probe edge cases, see exactly where an agent trips. By design it surfaces failure modes, not steady-state performance; treating Playground completion rates as a consumer-shopping success metric mis-reads the tool. But the categories of failure it surfaces — variant mismatch, slow tokenisation, malformed cart responses, checkout redirect loops — are real, and they're what separate an A-graded manifest from a store an agent can reliably transact against in production.

That's the gap we'd point a platform team at — and it isn't a percentage, it's a posture. The protocol's first phase, call it the first four months, was about getting the schema right, and the ecosystem did that. The next phase is the unglamorous second-order work: error recovery, schema robustness, response-time SLAs, variant-data hygiene, the long tail of edge cases that separate "manifest valid" from "agent transacts without anything tripping it up." That work is happening — the Playground sessions above are senior engineers doing exactly it. The open question is whether the posture spreads from the engineering teams already running this loop to the long tail of merchants still on bundled defaults. That's where the next quarter's competitive distance gets built.

The demand side: AI traffic is converting

For four months this report has focused on supply — which stores have UCP, what capabilities they declare, the shape of their manifests, what agents do against them in testing. On May 11 Shopify published its first real demand-side dataset, and the numbers reframe the urgency of everything above.

Across Shopify storefronts in Q1 2026, by Shopify's analysis:

AI-referred orders grew nearly 13× year-over-year. Referral sessions from AI chatbots (ChatGPT, Perplexity, Gemini, Copilot, Claude, Grok) grew more than 8× YoY.
AI-referred sessions convert at ~50% higher rates than organic search when they start on product pages.
Average order value is 14% higher for AI-referred than for organic-search orders.
More than half of AI-referred sessions start on a product detail page, vs ~20% for organic — "journey compression," the buyer arrives ready to buy because the AI did the research first.
AI-referred conversion outperforms organic SEO in 23 of 25 merchant categories.

Caveat: this is Shopify's analysis of Shopify storefronts with undisclosed methodology, so treat the precise numbers as Shopify-published rather than independently verified. But the direction is the story: agentic commerce isn't theoretical traffic any more. It's converting at premium rates, in volume, growing fast — and that's the demand signal that explains why every TC member is racing to ship at the productisation layer right now. Shopify Field CTO Sandy Jeong framed the operational work in three buckets: data readiness (machine-readable catalog with structured attributes), channel infrastructure (direct API syndication to AI platforms), and organisational alignment (a named DRI, not a committee). The teams that get those three right capture the 13× curve; the teams that don't watch it route around them.

Spec and ecosystem

Attribution landed in core. On May 5 the Technical Council merged a top-level attribution field into cart, checkout, catalog, and order operations — campaign IDs, click identifiers (gclid, fbclid, ttclid), source/medium markers, as an open string-keyed map. It's the first time advertising-and-measurement infrastructure has landed in UCP core, and the trajectory implication is the story: a protocol that carries attribution context is a protocol being built for commercial-scale deployment, not just technical demos.

The council expanded — and the regional question got sharper. Amazon, Meta, Microsoft, Salesforce, and Stripe joined the Technical Council at the end of April — a governance signal as much as an adoption one (none of the five has shipped a UCP store wave yet), but a notable one: the steering group now includes the company building the leading proprietary alternative (Amazon's "Buy for Me") and the company behind the leading rival protocol (Stripe, ACP). Convergence pressure, formalised.

Two German commerce trade publications picked up the expansion within a day of each other and used our breakdown of the 16-seat composition as a primary source: Exciting Commerce on April 27 (which drove the European enterprise retail audience UCP Alerts was built for), and Shoptechblog the next day. Both lead with the same regional point — "Keine Rolle spielen weiter europäische und asiatische Unternehmen" ("European and Asian companies continue to play no role") — and Shoptechblog adds the analytical layer: the new members sent senior engineers and architects rather than C-suite executives (implementation work, not press); each company's participation reads as defensive; and the real contest isn't the standardised protocol but the layers above it — ranking, paid placement, customer ownership. Which is exactly why attribution-in-core is more than plumbing: it's the first of those upper layers getting wired into the spec itself.

Two TC members shipped at the productisation layer. The contest moving up the stack got two concrete examples this month. On May 5 Google expanded UCP-powered checkout out of AI Mode into the main shopping section of standard Search results, with Wayfair the first live retailer on the new surface — a "Buy" button on listings inside Google Search itself, Google Pay tokenisation, checkout completing without leaving the page. Zero-click search results just became zero-click purchases. The two-track adoption story we drew in February has its first major convergence event.

Google's UCP-powered checkout flow on Wayfair: AI Mode query → product page with Buy button → Google Pay review → order complete. Source: Google.

Shopify, separately, started rolling out an Agentic Storefronts dashboard in merchant admin this week (live docs) — surfaces ChatGPT / Microsoft Copilot / AI Mode traffic, offers an "Allow Shopify to manage for me" toggle that auto-generates the AI-readability files (llms.txt, llms-full.txt, agents.md) for stores that opt in. The dashboard is protocol-agnostic: it covers ChatGPT (ACP), Copilot, and UCP-powered Search inside one admin view. UCP is one of the protocols Shopify is now monetising on the agentic-readiness layer, not the whole product. For Shopify it's the natural next step after the v2026-04-08 fleet migration; for everyone else watching the head start, it's the answer to what the next phase of it looks like.

Shopify Agentic Storefronts in merchant admin — ChatGPT / Microsoft Copilot / Shop Channel split, "Allow Shopify to manage for me" toggle, agentic-readiness checklist.

A potential spec gap, still being validated. In the variant-data guide we noted that v2026-04-08 makes variant.options[] optional even on products where product.options[] is non-empty and there are multiple variants — meaning two fully spec-compliant manifests can produce identical-looking payloads where one is unambiguous and the other is agent-unresolvable. The candidate fix would be a conditional MUST ("when product.options is non-empty and variants.length > 1, every variant MUST populate options[]"). It's a working hypothesis from one analysis, not a filed proposal — we want to sweep more of the live dataset for real-world incidence and check the edge cases (single-variant simple products, productGroup behaviour, platforms that already populate options by default) before raising it formally. If the pattern holds, it's a candidate for a future minor release.

No v2026-05. v2026-04-08 remains current. On the cadence so far, the next minor release more likely lands late summer (a notional v2026-08), probably bundling AP2 mandate refinements, schema corrections shaken out by running validators against thousands of real stores, and whatever the council formalises over the next two months. On the partner side: the registry now lists 61 merchants, 11 agents, and 8 extensions; the payment-handler roster (Adyen, Amex, Mastercard, Stripe, Visa, Checkout.com, Affirm, Splitit, PayPal) is unchanged and still almost entirely unrepresented in live manifest declarations.

What we shipped — and what developers are doing with it

UCP Variant Data: The #1 Reason Agent Checkouts Fail — the five variant-data anti-patterns, what clean variant data looks like, and the spec gap that lets compliant stores still be broken.
How to Test Your UCP Implementation — the three-layer validation workflow: static audit, live agent test, continuous monitoring.
UCP Score is doing exactly what it was built to do. This is the one we're proudest of this quarter. The Score turns "is my manifest agent-ready?" into a concrete, category-by-category checklist — and developers are using it that way: we've watched a failing manifest climb to an A grade in the space of a few hours, the developer iterating against the score breakdown between checks. That's the loop it was designed for, and it's now the loop it runs.
UCP Playground got sharper as a development tool. Two halves of the same loop: the agent-inspection tooling — replay any session, see the exact tool call where an agent tripped — and the runtime shopping evals, now past 1,000 recorded sessions and more than 12 hours of cumulative agent runtime against real stores. Together they take the build → test → fix cycle for an agent-ready storefront down from a sprint to an afternoon. Every improvement that got us there is in the changelog.
Crawler throughput — we roughly tripled the hourly crawl rate in early May (and added per-IP and global throttles to the expensive public routes so the directory stays fast under load). That's what moved the discovery curve this month.

What to watch in June

Second adopters at every edge. May produced first adopters across multiple novel patterns — non-Shopify platforms shipping UCP (Bareconnect, Selly.io), a consultancy-built accelerator (PwC), non-default payment-handler integrations (the processors in dev), AP2 mandate (still one), third-party capability namespaces (each at 1–2 stores). The diagnostic for June is whether any doubles up. Each is a distinct watch item; the meta-question is the same: did May's first adopters survive contact with month two?

Google's next live partner on main Search. Wayfair is first up on Google's UCP-checkout expansion into standard Search results. The other co-developing TC retailers — Etsy, Target, Walmart — are the next-most-likely to follow. The cadence of those rollouts is the diagnostic for how fast Google is willing to push agent-completed transactions onto its highest-traffic surface.

The platform-level integration question. SFCC, Adobe Commerce, Wix, Squarespace — any of them shipping a platform-level UCP integration is still the single highest-impact possible event, and still hasn't happened. The one-platform structure is four months old.

Whether the eval leaderboard holds its shape. Claude Sonnet 4.5 leads checkout completion on the largest sample; Llama 3.3 70B is the surprise second. Another month of sessions either confirms that or reshuffles it.

Sources

All data is from the UCP Checker crawler (re-checks every tracked domain at least every 24 hours) and UCP Playground's eval sessions, as of May 12, 2026. The verified-merchant dataset is published monthly on Hugging Face under CC-BY 4.0; the same data, a public REST API, the bulk checker, and the rest of our developer tools are all ungated.

Browse the directory: ucpchecker.com/directory
Track adoption live: ucpchecker.com/stats
Run a UCP Score: ucpchecker.com/score
Model + store leaderboard: ucpplayground.com/evals
Public dataset, REST API & developer tools: ucpchecker.com/developer-tools
Previous report: State of Agentic Commerce — April 2026

External coverage cited in this report:

Jochen Krisch, "Amazon schließt sich Googles Universal Commerce Protocol an," Exciting Commerce, April 27, 2026
Roman Zenner, "Agentic Commerce: Das UCP Council wächst," Shoptechblog, April 28, 2026
Google expands UCP Checkout to main Search shopping results, Search Engine Land, May 2026
New tech and tools for retailers to succeed in an agentic shopping era, Google blog (Ads & Commerce)
Shopify Agentic commerce developer docs — Agentic Storefronts, llms.txt, llms-full.txt, agents.md reference
What Shopify checks for agentic readiness, WISLR Research
Kyle Risley, "AI-referred shoppers convert better and spend more (2026)", Shopify Enterprise Blog, May 11, 2026

UCP Variant Data: The #1 Reason Agent Checkouts Fail

Benji Fisher — Wed, 13 May 2026 11:12:54 +0000

A user asks an AI shopping agent for "a medium grey t-shirt." The agent finds the product. It picks a variant. It adds it to the cart. The merchant rejects the cart. The agent retries with a different variant. The merchant rejects that one too. The session ends in cart_created without a checkout — the user's $40 purchase quietly disappears, and nobody on the merchant side ever sees the failure.

This pattern is the single largest source of agent checkout failures we see across the 4,500+ verified UCP stores in the directory. More than schema invalidity, more than tool errors, more than payment-handler problems. Variant mismatch — the agent and the merchant disagreeing on which SKU corresponds to "Medium" — is responsible for a meaningful fraction of the gap between "store has a UCP manifest" and "agent can actually buy from it."

The good news: it's almost entirely fixable on the merchant side, in your variant data structure, without changing any tooling. This post walks through the failure pattern, the five most common variant data anti-patterns we observe, and what clean variant data looks like in practice.

Anatomy of a variant mismatch

Here's the cleanest way to see the failure:

Two frontier agents — call them Agent A and Agent B — get the same prompt against the same store: "Add a medium grey t-shirt to my cart." Both agents call search_catalog, both get the same product back, both see three variants:

{
  "variants": [
    {"id": "var_5571", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "Small"}]},
    {"id": "var_5572", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "Medium"}]},
    {"id": "var_5573", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "Large"}]}
  ]
}

Agent A picks var_5572. Agent B picks var_5572. Both add to cart. Both succeed. Clean data, predictable behaviour. Each variant declares its options as an array of {name, label} pairs — the spec's selected_option shape — so the agent matches "medium" against the Size axis unambiguously.

Now the broken version. Same prompt, same product, but the variant data looks like this:

{
  "variants": [
    {"id": "var_5571", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "S"}]},
    {"id": "var_5572", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "M"}]},
    {"id": "var_5573", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "L"}]},
    {"id": "var_5574", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "Medium / Regular Fit"}]},
    {"id": "var_5575", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "Medium / Slim Fit"}]}
  ]
}

Agent A picks var_5572 (interpreting "M" as the canonical "Medium"). Agent B picks var_5574 (interpreting "Medium / Regular Fit" as the more explicit match). Neither is wrong. The user said "medium" and both interpretations are defensible. But because the variant data conflates two different axes — size and fit — into a single Size label, the two agents diverge, and the user's experience depends on which model they're using. The spec form makes the bug obvious: Fit should be its own selected_option, not crammed into the Size label.

Worse: many real implementations don't even include the option labels. They expose only opaque variant IDs:

{
  "variants": [
    {"id": "var_5571"},
    {"id": "var_5572"},
    {"id": "var_5573"}
  ]
}

Now the agent has no way to know which variant corresponds to "Medium" at all. It guesses. Sometimes it guesses right. Often it doesn't. That's how checkout sessions end up in cart_created without ever reaching checkout_reached.

Why this is the #1 failure mode

Across the Playground session dataset, roughly 62% of sessions end without a completed checkout. The breakdown is informative:

Outcome	Share
`checkout_reached`	38%
`search_only` (browsed, didn't add)	27%
`failed` (provider error, model refusal, max turns)	22%
`cart_created` (added, didn't proceed)	13%

The cart_created cohort — sessions where the agent successfully picked something but couldn't finish — is the variant-mismatch signal. The agent had enough information to add to cart but the cart contents weren't valid for checkout. That's the structural shape of "wrong variant picked."

Roughly half of the categorised failed sessions are also variant-shape problems — the agent picked a variant ID that the cart endpoint rejects, retried with another, hit max_turns_exceeded while flailing through the variant list. Add those in and variant-related failures account for somewhere around a fifth of all sessions, which is more than any other categorisable failure mode.

The thing that makes this pattern so consistent: clean variant data is not part of UCP Score or schema validation. A store can pass UCP Score at A grade and still emit variant data that breaks every agent in the field. The validator looks at whether the manifest parses; it doesn't look at whether the variants are agent-resolvable. That gap is exactly why this post exists.

A spec gap that compounds the problem

Even when a store is fully UCP-compliant, the protocol leaves room for ambiguity. The 2026-04-08 schema makes variant.options[] optional — including on products where product.options[] is non-empty and there are multiple variants. So a payload like {"options": [{"name": "Size", "values": [{"label": "Small"}, {"label": "Medium"}]}], "variants": [{"id": "var_a"}, {"id": "var_b"}]} is technically valid but agent-unresolvable: nothing links var_a to "Small" rather than "Medium." Two consumers looking at this payload can defensibly pick different variants for the same prompt.

A conditional MUST in the spec — "when product.options is non-empty and variants.length > 1, every variant MUST populate options[]" — would close this cleanly. Until that lands, agent-resolvability is on the merchant rather than the protocol.

The five variant anti-patterns

In rough order of frequency observed across the dataset:

1. Opaque variant IDs with no option metadata

The shape from the third example above — variants exposed only as var_5572, no options, no attributes, no human-readable axis. Agents have no way to map a user's "Medium" to a specific ID. They either guess or pick the first variant, both of which produce wrong outcomes routinely.

Fix: every variant must carry the axis values that distinguish it from siblings, in the spec's selected_option array form: "options": [{"name": "Size", "label": "Medium"}, {"name": "Color", "label": "Grey"}]. The name field tells the agent which axis the value belongs to; label is what gets matched against the user's request. Whatever the product's options page shows to a human shopper — size, colour, material, fit — the variant data should expose programmatically with one selected_option entry per axis.

The corollary: descriptive attributes that aren't selection axes belong in metadata, not product.options[]. A one-variant simple product with "Color: Gray" should expose Gray as metadata.attributes, not as a single-value product.option — otherwise consumer UIs render a one-button picker that looks selectable but isn't. The split: product.options[] is for axes the buyer chooses across; metadata is for descriptive properties of the (only) variant.

2. Conflated axes in a single string

The shape from the second example — "Medium / Regular Fit" as a single option value where size and fit are two separate user choices. Agents can parse this, but inconsistently across models, because the conflation is ambiguous. Different models split the string differently, and the variant they end up picking depends on which side of the slash they prioritise.

Fix: each variant attribute lives in its own field. Don't compose. If your product has size + fit as two axes, the variant data should look like:

{
  "id": "var_5574",
  "options": [
    {"name": "Size", "label": "Medium"},
    {"name": "Fit", "label": "Regular"}
  ]
}

Two clean axes, two unambiguous values, no string parsing required. Agents pick consistently. The array-of-selected_option form is the shape UCP 2026-04-08 defines for variant.options — see selected_option.json.

3. Inconsistent labelling between sibling variants

Not all variants on the same product use the same option vocabulary. One says "M", another says "Medium", another says "med". We see this on stores that have grown organically — different teams added variants over different years, naming conventions drifted, the inconsistency is invisible to the merchandising team because the storefront UI hides it.

Fix: one canonical label per axis value, applied consistently across every variant on every product. If "Medium" is the canonical label, every Medium variant uses exactly "Medium". No "M", no "med", no "Medium " (trailing space). Agents reason by string match; consistency is what makes the match reliable.

4. Missing or inconsistent stock / availability flags

A variant exists in the catalogue but is sold out, and the variant data doesn't say so. The agent picks it, the cart accepts the add, the checkout endpoint rejects it. The agent doesn't know to retry with a different variant — it had no signal that the variant was unavailable.

Fix: every variant declares its availability object — {"available": true, "status": "in_stock"} is the spec shape, with well-known status values in_stock, backorder, preorder, out_of_stock, and discontinued. Agents skip unavailable variants if you tell them to, and status gives them enough signal to decide whether to wait, substitute, or surface an out-of-stock message to the user.

5. Declared axes that variants don't honor

product.options[] declares the selectable axes; variants[] is the universe of actual purchasable combinations. When the cardinality of declared axes doesn't match what variants actually carry — e.g., product.options declares Color × Size = 9 combinations but only 3 color-only variants exist — agents try to satisfy a Size selection that no variant honors. Strict consumers return null and refuse to add; lenient consumers guess and pick wrong.

Fix: keep product.options[] and variants[] in sync. Either every declared axis combination has a corresponding variant, or the axis shouldn't be in product.options[]. If sizes aren't actually configurable for this product, drop Size from the axes; don't leave it dangling.

What clean variant data looks like

Here's the shape that resolves cleanly across every frontier model we test:

{
  "id": "prod_42",
  "title": "Heavyweight Crew Tee",
  "description": "Heavyweight cotton crew-neck tee.",
  "price_range": {
    "min": {"amount": 4500, "currency": "USD"},
    "max": {"amount": 4500, "currency": "USD"}
  },
  "options": [
    {"name": "Color", "values": [{"label": "Charcoal"}]},
    {"name": "Size",  "values": [{"label": "Small"}, {"label": "Medium"}]},
    {"name": "Fit",   "values": [{"label": "Regular"}]}
  ],
  "variants": [
    {
      "id": "var_5571",
      "title": "Charcoal / Small / Regular",
      "description": "Heavyweight crew tee, charcoal, size small, regular fit.",
      "price": {"amount": 4500, "currency": "USD"},
      "availability": {"available": true, "status": "in_stock"},
      "options": [
        {"name": "Color", "label": "Charcoal"},
        {"name": "Size",  "label": "Small"},
        {"name": "Fit",   "label": "Regular"}
      ]
    },
    {
      "id": "var_5572",
      "title": "Charcoal / Medium / Regular",
      "description": "Heavyweight crew tee, charcoal, size medium, regular fit.",
      "price": {"amount": 4500, "currency": "USD"},
      "availability": {"available": true, "status": "in_stock"},
      "options": [
        {"name": "Color", "label": "Charcoal"},
        {"name": "Size",  "label": "Medium"},
        {"name": "Fit",   "label": "Regular"}
      ]
    }
  ]
}

Four spec fields make this work:

product.options at the product level — declares the axes (Color, Size, Fit) and their valid values as an array of product_option {name, values: [{label}]}. Agents know upfront how many dimensions a variant occupies and what values are valid on each axis.
variant.options as an array of selected_option {name, label} — each axis has its own entry, no string parsing, no conflation. The name matches the product-level axis; the label matches the user's request.
variant.availability with available and status — agents skip unavailable variants without trial-and-error, and status (in_stock, backorder, preorder, out_of_stock, discontinued) gives them enough signal to wait, substitute, or surface the right message.
Required scaffolding — id, title, description, and price on every variant, and id, title, description, price_range, variants on the product. These aren't "nice to have"; they're the schema's required fields. Variants missing any of them won't validate.

Bonus stability: when present, option_value.id and selected_option.id give stable identifiers that survive label drift. If your platform supports it (most do — Shopify uses GIDs, WooCommerce uses pa_* taxonomy slugs), populate id alongside label and consumers can match on the stable key when labels change.

Stores running variant data in this shape resolve user prompts to specific variants reliably across every model we've benchmarked. The pattern isn't novel — it's the same shape Shopify uses internally, the same shape WooCommerce variations use when properly structured, the same shape every traditional e-commerce platform ends up at after enough years of evolution. UCP just exposes it programmatically to the agent layer.

How to validate your variant data

Three layers, in order:

1. Static audit. Run your store through UCPChecker. The validator surfaces variants with missing options data, conflated axes, inconsistent labels across sibling variants, and missing availability flags. None of this is part of strict UCP-spec conformance, but our methodology flags variant-quality issues as part of the Capability Coverage score because they materially affect whether agents can transact.

2. Live agent test. Run a multi-model agent session against your store via UCP Playground. The framework exercises the full search → variant-pick → cart → checkout flow against frontier agents across 15+ models. If your variant data is ambiguous, you'll see different models pick different variants for the same prompt — the exact pattern we walk through in the Playground 1,000-sessions analysis.

3. Continuous monitoring. Variant data changes over time as you add products and SKUs. Set up UCP Alerts so you get notified when a variant audit starts surfacing new issues — typically a sign that a recent merchandising change introduced inconsistent labelling at scale.

The order matters. Static audit catches the easy cases (missing fields, schema-shaped problems) cheaply. Live agent test catches the cases where the schema is fine but agents disagree (the conflated-axis cases, the inconsistent-label cases). Monitoring catches drift over time. Skipping any of the three leaves a class of variant problems undetected.

What to fix in your store, and how to verify it

If you're a merchant reading this and your store is running on Shopify, WooCommerce, BigCommerce, Magento, or PrestaShop, the variant data structure is mostly determined by your platform's defaults. The platform-specific fixes are documented in the platform guides — but the meta-pattern is the same:

Audit at ucpchecker.com/check — get a list of variant-data issues
Fix the most common one first (usually missing options metadata)
Test at ucpplayground.com with two different models against the same product, asking for the same variant
Verify that both models pick the same variant ID consistently
Monitor weekly — variant drift is the most common reason a store's UCP Score regresses

Variant data is a back-office data-quality problem dressed up as an agentic commerce problem. The fix is mostly editorial — get your axis labels consistent, expose your option values structurally, mark sold-out variants as such. None of this is technically hard. It's the kind of work that adds up to "agents can buy from your store" rather than "agents try to buy from your store and quietly fail."

If you fix one thing on the agent-readiness side this quarter, fix variant data. The conversion lift is bigger than any other single change you can make.

One thing worth naming: consumer tools that silently paper over variant data problems (substring matching, positional guessing, falling back to variants[0]) make this worse, not better. They hide the failure mode from merchants who would otherwise see it and fix the data. Faithful rendering — null when the match is ambiguous, errors when the data is inconsistent — is what produces correct merchant behaviour. If your variant data only works in some agents, that's a signal the data is the problem, not the agent.

Try it

Audit your variants now: ucpchecker.com/check — flags variant issues alongside the rest of the UCP Score
Test variant resolution with real agents: ucpplayground.com — run two models against your store on the same prompt, see if they pick the same variant
Read the broader failure-mode taxonomy: Common UCP Errors and How to Fix Them
Track ecosystem-wide variant adoption: State of Agentic Commerce — April 2026