Agentic Commerce ReadinessFind out in one week what stops an AI agent from buying from you.
- $2,250
- Fixed price
- 1 week
- From day zero
- Read-only
- Access
- 5 layers
- One result each
Open code you can read before you hire us
Who the agentic commerce readiness audit is for
The audit suits stores with more behind them than a catalogue: stock that lives in an ERP, several price lists, several markets, or a checkout built for your business. In those stores the answer to "can an agent buy here" depends on systems a public scanner cannot see.
It is too early for a store with a few dozen products on a hosted platform and a standard checkout. That store is better served by the agent features its platform ships and by a free scanner. We say so on the first call.
What the agentic commerce readiness audit covers
Five layers, audited one at a time, in the order an agent meets them: Discover, Understand, Model, Integrate, Transact.
Passing a lower layer does not mean passing the next one. A store can be fully indexed and fully understood by an AI and still be nowhere near ready for agentic checkout. For that reason each layer gets its own result, backed by technical evidence that can be observed again, and no layer is folded into a single score.
- 1. Discoverability
Can an outside agent or search crawler find and read the store at all? We check robots rules, the sitemap, indexability, access to categories and product pages, restrictions at the CDN and firewall, any blocking of AI bots, and the stability of public URLs.
- 2. Product understanding
Can an agent interpret a product without guessing? We check the name, brand, SKU, GTIN or EAN, description, attributes, images, price, currency, availability, sizes, colours, variants and seller. Structured markup (Schema.org, JSON-LD) is assessed together with the consistency of the HTML, the API and the real state of the product.
- 3. Commerce semantics
Is the commercial model correct, beyond being present? An agent has to tell apart product, variant, offer, seller, price, inventory and delivery. For marketplaces and for B2B and B2C stores we check multiple sellers, wholesale and retail prices, stock by size, promotions, minimum quantities and any other condition that changes which offer is the right one.
- 4. Agent integration
Can an agent work with the store, beyond reading it? We check whether a standard machine interface exists or can be built: UCP, ACP, merchant feeds, a commerce API, discovery endpoints, capability negotiation and MCP integrations. This is the layer that shows whether an AI can request a current price, availability and delivery terms programmatically.
- 5. Transaction
Can an order be carried out safely? We look at creating a cart or a checkout session, choosing the variant and the seller, calculating delivery and tax, obtaining the final price, starting a payment the user has allowed, creating the order and reading its status. We test idempotency, error handling, changes of price or stock between selection and payment, user authorisation and control over what the agent may do.
What you receive
A written report with a separate result for each of the five layers. Each finding carries evidence, a priority and an owner on your side.
A recorded walkthrough call with the engineer who ran the audit.
A recommendation on protocols: ACP, UCP, both, or neither yet, with the reason.
An implementation plan in phases with a budget range and the drivers of that range.
What a finding looks like
An illustrative example, not taken from a client.
F-04 · Priority 0 · Layer 3, Commerce semantics. A product page declares "in stock" in its structured data while the size an agent asks for is unavailable, because the page carries one availability value for all variants.
The raw HTML of one product with mixed stock, captured on the audit date.
One offer per variant, with availability and a timestamp from the stock system.
The storefront team with the owner of the ERP integration.
A sample of products with mixed stock matches across the page, the feed and the API.
The audit can end with "wait". If the honest answer is that your channels do not support agents yet, the report says that and still lists what is worth fixing for ordinary search.
How the week runs
Access is granted and your side names an owner. The week starts then, not at signature.
We run layers one to three on your live store and on a sample of products across categories, variants and stock states.
We work through layers four and five with your engineers, reading the contracts between storefront, ERP and payments.
Report, plan and budget range.
A walkthrough call within the following days.
Price and credit
The agentic commerce readiness audit costs $2,250, fixed.
The full fee is credited toward implementation work of $7,500 or more, if you start within 60 days.
If you decide not to go further, the report is yours and nothing else is owed.
What the audit does not cover
Content and brand work for visibility in AI answers. That is a different kind of agency work.
Shopping agents for your own customers. That is AI agent development.
Agent payments in crypto and stablecoins, which have their own page.
Any promise of traffic or sales from AI channels.
A "UCP-compliant" or "ACP-compliant" badge. Both protocols are young, and no certification exists for us to hand out.
Where we are
Agentic commerce for merchants: UCP, ACP and AI shopping agents
Written from the primary specifications. Last reviewed 2 October 2026.
What agentic commerce is, and where the protocols stand
Agentic commerce means AI shopping agents acting for a buyer: finding products, comparing them and, in some cases, paying. Two open protocols describe how an AI agent talks to a merchant. They are specifications you implement. Neither is a certification, and neither requires you to leave your platform.
The Universal Commerce Protocol, UCP, was announced by Google on 11 January 2026, developed with Shopify, Etsy, Wayfair, Target and Walmart. Google names AI Mode in Search and the Gemini app as the first surfaces. The Agentic Commerce Protocol, ACP, is an open standard under the Apache 2.0 licence, maintained by OpenAI and Stripe as founding maintainers, with a stated path toward broader community governance. The current ACP specification is dated 2026-04-17, and its repository describes it as beta.
In March 2026 OpenAI moved Instant Checkout toward ChatGPT apps, where merchants run their own checkout. An OpenAI spokesperson told the trade press that ACP continues as the infrastructure connecting users to merchants (Digital Commerce 360). The protocol outlived the product.
The practical reading: the specifications exist, and demand is uneven. A merchant should prepare the data and the checkout contracts that serve both protocols, and commit to a single channel only when that channel brings buyers. The explainers go further: What is UCP and ACP vs UCP.
Agentic Commerce Protocol (ACP): what a merchant implements
The Agentic Commerce Protocol is built from five blocks:
- Agentic checkout. Create, update and complete a checkout, with cart handling, fulfilment options and payment.
- Cart and feed. Browse the catalogue and manage a cart before checkout.
- Delegate payment. Pass a payment token between buyer, agent and merchant without exposing the card.
- Delegate authentication. Authorise the agent to act for the buyer, using OAuth 2.0.
- Orders and webhooks. Follow an order through confirmation, shipping, delivery and refund.
The repository publishes each block as an OpenAPI file: checkout, checkout webhooks, cart, feed, delegate authentication and delegate payment. OpenAI's documentation divides the work. Merchants integrate by implementing the Agentic Checkout Spec and provide a product feed through an API or a file upload. Payment service providers implement the Delegated Payment Spec.
The merchant stays the merchant of record. You decide which agents may reach your products and on what terms, and you keep the customer relationship.
Stripe's documentation is the most complete integration path today. Whether another payment provider fits is a question for the audit.
How an ACP purchase works, step by step
- The agent opens a session.
POST /checkout_sessionscarries the items and, optionally, the buyer and the delivery details. The merchant answers with the authoritative cart: line items, totals, fulfilment options and messages. - The agent adjusts it. As the buyer chooses an address or a delivery option, the session is updated and the merchant recalculates the totals.
- The agent obtains a payment token. The token is limited by an allowance: a maximum amount, a currency, the merchant and an expiry. This step sits with the payment service provider.
- The agent completes, or either side cancels. The complete call carries the token and the merchant creates the order.
Every POST carries an Idempotency-Key header, so a retried request cannot create a second order.
Universal Commerce Protocol (UCP): what a merchant publishes
The Universal Commerce Protocol starts with a profile. A merchant publishes a JSON manifest at /.well-known/ucp that lists the services, capabilities and payment handlers it supports. An agent publishes its own profile. The two are compared and the merchant answers with the capabilities both sides understand.
Capabilities are named in reverse-domain form. dev.ucp.shopping.checkout is the checkout capability, and dev.ucp.shopping.discount and dev.ucp.shopping.fulfillment extend it. The shopping specification lists five capabilities: catalogue, cart, checkout, identity linking and order. Transports are REST and JSON-RPC, with support for the Agent Payments Protocol (AP2), Agent2Agent and MCP.
A checkout session moves through three states. incomplete means information is missing and the agent tries to resolve it through the API. requires_escalation means the buyer has to decide something, and the merchant returns a URL to continue. ready_for_complete means the agent can finish. UCP offers two ways to check out: native, through your own APIs, or embedded, where your checkout renders inside the agent's surface.
For Google surfaces a merchant also needs an active Merchant Center account with eligible products.
How a UCP purchase works, step by step
- Discovery. The agent fetches
/.well-known/ucp, learns your capabilities and payment handlers, and negotiates the ones both sides support. - Create. The agent creates a checkout with
line_items. The response carries the sessionid, itsstatusand the totals you computed. - Resolve. While the status is
incomplete, the agent updates the checkout. Messages with a code, such asout_of_stock,item_unavailable,address_undeliverable,payment_failedoreligibility_invalid, and a severity say what has to change. - Hand off. When the API cannot supply something, the status becomes
requires_escalationand the merchant returns acontinue_urlwhere the buyer finishes. - Complete. From
ready_for_completethe agent completes with payment data for a handler in your profile. A completed session cannot change.
A retried complete call has to reuse the same idempotency key. Quantity units must never be reinterpreted silently, a rule that matters for stores that sell by weight, length or pack size.
Which protocol to implement first, and when to wait
Both protocols need the same foundations: a catalogue an agent can read, one source of truth for price and stock, and orders that survive a retried request. Build those first. The protocol itself is the thinner layer on top. The full side-by-side comparison is in ACP vs UCP.
Our rule of thumb for the choice:
- Google is your main channel and Merchant Center is already in place: begin with a UCP profile.
- Payments already run on Stripe and your buyers arrive through ChatGPT: begin with ACP.
- You sell on Shopify: check what the platform ships before you build. Shopify co-developed UCP, and its engineering write-up points merchants to its Checkout Kit.
- Neither channel brings you buyers yet: do the data work and wait.
We advise against implementing both by default. Each one adds a contract to keep in step with stock, price and tax.
Where MCP fits in agentic commerce
MCP lets a model call tools and read data through a server. UCP lists MCP as one transport. For a store, an MCP server over catalogue and order status gives any MCP-capable assistant a read-only view of your shop, without waiting for a channel to adopt a commerce protocol. It is a way to learn how agents use your data before money moves through it.
What AI shopping agents need from your product catalogue
- A stable identifier for every product and every variant.
- An offer per variant: price, currency and a validity date that has not passed.
- Availability per variant, with the time it was last checked. A page that says "in stock" while the chosen size is not is a common failure.
- A delivery estimate per destination.
- Prices that depend on who is asking, such as wholesale or contract prices, tied to an eligibility rule, so an agent cannot quote a price the buyer is not entitled to.
- A return policy in a form a machine reads.
Structured data that exists only for the default variant, or only in markup that nobody checks, produces confident wrong answers. That is worse than no answer.
What agentic checkout changes behind the storefront
Both protocols ask the merchant to return the totals. ACP expects the create call to return the authoritative cart, and UCP responses carry totals the business computed. That puts your price rules, tax and shipping behind an API that an agent calls many times in one session, usually with no person waiting. Three questions follow.
- Can your tax and shipping calculation answer a request on its own, and how fast? If it exists only inside the cart page, it needs an interface first.
- When is stock reserved, and for how long? Sessions end: ACP lists an
expiredstatus and UCP acanceledstate for sessions that are invalid or expired. A session that holds stock needs a release rule, or abandoned agent sessions will eat availability. - Which system owns the price? If the storefront, the ERP and a feed can each produce a price, an agent will find the disagreement before your customers do.
Agentic checkout, payment and consent
An agent works through a quote, a reservation and a confirmation. Each step needs to behave the same way when it is repeated, because agents retry. An idempotency key on the order request is what keeps a retry from creating a second order.
Payment tokens keep card data out of the agent's hands. Consent has to be explicit and recorded: what the buyer approved, at what price. When information is missing, UCP's requires_escalation state is the designed hand-off to a person.
Under ACP the merchant remains the merchant of record, so fraud, chargebacks and refunds stay with you. Plan the refund path before the first order.
Why AI shopping agents fail on stores that look fine
These recur in stores that look fine to a person:
- A bot challenge or firewall rule that returns an error to any client that is not a full browser.
- A sitemap that is stale, or that lists addresses which redirect.
- A redirect on every path except the root, which would also redirect
/.well-known/ucp. - Product pages of several megabytes of HTML that an agent has to download and parse.
- Structured data with one page-level offer while stock differs by variant.
- A price validity date that is already in the past.
- A feed and a product page that disagree about stock.
- A price list meant for one customer type shown to everyone.
Agentic commerce readiness checklist
This is the checklist the audit works through, shortened. Questions one to eight are about what an agent can read. Questions nine and ten are about what it can do.
- Reachable. Can a plain HTTP client, not only a browser, fetch your product pages,
robots.txtand sitemap without a bot challenge or a block? - Open to the right crawlers. Do your robots rules and firewall allow the crawlers of the AI products you want to appear in, and do you know which those are?
- A live sitemap. Does your sitemap list current product URLs, and do they resolve without redirect chains?
- Machine-readable product data. Does every product page carry Schema.org Product and Offer data in JSON-LD, with SKU, GTIN or MPN, brand, price and currency?
- Offers per variant. Are price and availability stated for each variant, and is any price validity date still in the future?
- One source of truth. Do the storefront, the feed and the API return the same price and stock for the same variant at the same moment?
- Prices with eligibility. If the price depends on who is asking, can an agent be shown only the price the buyer is entitled to?
- Policies a machine can read. Are shipping, returns and tax rules available in a form an agent can read, beyond a page of text?
- A discovery profile. Does
/.well-known/ucpexist and return JSON, and is it reachable at the root of the domain even when every other path redirects to a language version? - A checkout an agent can complete. Can a session be created, updated and completed through an API, with an idempotency key, a recoverable error for an item out of stock, and a hand-off URL when a person has to step in?
A sensible order of work
- Measure what an agent can reach and read on your live store. This also helps ordinary search.
- Define one offer model for products, variants, prices and stock, with a timestamp.
- Prototype one read-only agent scenario and one sandbox checkout, with explicit consent.
- Pilot a limited set of products with monitoring and a way to roll back.
The first two steps are worth doing even if no agent ever buys from you.
Terms used on this page
- MCP, Model Context Protocol
- A way for a model to call tools and read data through a server. UCP lists it as a transport.
- A2A, Agent2Agent
- A protocol for agents to talk to each other, listed as a UCP transport.
- AP2, Agent Payments Protocol
- A payments protocol that UCP is compatible with. It supports tokenised payments and verifiable credentials.
- OAuth 2.0
- The authorisation standard ACP uses to let an agent act for a buyer.
- Idempotency key
- A value sent with a request so that repeating the request does not repeat its effect. Both protocols rely on it for orders.
- Merchant of record
- The business legally selling the goods. Under ACP that stays the merchant.
- Payment service provider
- The company that processes the card or wallet payment for the merchant.
- Well-known URI
- A fixed path on a domain, such as /.well-known/ucp, where a standard publishes a file that software can find without being told.
Sources
- Universal Commerce Protocol specification (ucp.dev)
- Google Developers Blog: Under the Hood, Universal Commerce Protocol
- Shopify Engineering: Universal Commerce Protocol
- Agentic Commerce Protocol specification (agenticcommerce.dev)
- Agentic Commerce Protocol repository on GitHub
- Stripe documentation: Agentic Commerce Protocol
- OpenAI developer documentation: Commerce
- Digital Commerce 360: OpenAI shifts checkout plans, 6 March 2026




