Agentic commerce and getting your store ready for AI agents

Agentic commerce means an AI agent, acting for a person, finds a product, checks it is available and completes the purchase through your store's data and APIs instead of its pages. To sell to that buyer you need a catalogue the agent can parse, stock data it can trust, and a checkout it can finish without a human typing into a form. The rest of the work is attribution and consent wiring.

TL;DR: Agentic commerce moves the buying decision from a rendered page to a machine-readable interface. An agent needs a structured catalogue, availability it can trust, and a checkout it can complete on its own. Most stores already have the catalogue. They lose the sale at availability and checkout, to a competitor that exposes both cleanly. The work is data plumbing and consent design, and it does not need a new model.

What is agentic commerce, from the merchant's side?

The next shopper to reach your store may be software. It will not scroll or click "add to cart," and your hero image means nothing to it. It reads your catalogue as data, confirms the item is in stock, and tries to finish the order end to end.

Three open specifications now describe that exchange, and you should know what each one covers before you build anything:

• OpenAI's Agentic Commerce Protocol defines a product feed, an Agentic Checkout Spec that merchants implement, and a Delegated Payment Spec that payment providers implement.
• Google's Agent Payments Protocol (AP2) describes how an agent proves it may pay, using signed mandates for both human-present and human-not-present purchases.
• The Universal Commerce Protocol is an open standard for agents, merchants and payment providers to transact without one-off integrations. It uses OAuth 2.0 for account linking and AP2 for payment.

You do not have to pick a winner today. All three expect the same things from your store underneath: clean product data, current availability, and a checkout exposed as an API.

The three things AI shopping agents need that human shoppers do not

AI shopping agents need three primitives before they can transact with you, and your homepage is none of them.

1. A structured catalogue. That means products with explicit, machine-readable attributes: name, price, currency, variant, size or color, category, image URL and one stable product ID. A person infers that "charcoal" is the grey one and that the price in the photo is current. An agent cannot infer, so every field has to be there.
2. Machine-readable availability. Whether the item is in stock, how many, where, and when it can ship or be collected. An agent will not put an out-of-stock item in a cart it intends to complete. If availability is ambiguous, it moves to the next store.
3. A checkout it can complete. A path from cart to confirmed order that the agent drives programmatically: add line items, apply a payment credential, receive an order confirmation. If the last step drops the agent into a human login or a CAPTCHA, it fails at the only step that produces revenue.

Each primitive is a data or API surface. A store that exposes all three is machine-transactable today, while a store that exposes only the catalogue gets browsed and then abandoned at the cart.

Your product data is now your storefront

For a person, the storefront is the rendered page. For an agent, it is the product feed and the structured data the page emits. The same SKU can look finished to a person and empty to a machine.

An agent reads three things:

• Structured data on the product page, usually JSON-LD using schema.org Product and Offer, with variant-level price, availability and identifier.
• Your API surface. On a hosted platform that is the Storefront API, on a headless build your commerce API, or a feed endpoint in the format the agent platform asks for.
• Consistency between the two. If the page says "in stock" and the feed says "out of stock," the agent has a reason to distrust you and leave.

The usual failure is inherited data. Catalogues grow over years. Attributes go missing, variants get listed as separate products, and one generic field ends up holding five different kinds of value. A person fills the gaps by looking at the photo. An agent guesses, which is worse, or leaves. Fixing titles, filling attributes and assigning one canonical ID per variant is the highest-value commerce work you can do right now, because the same fix feeds the human page and the machine interface. Catalogue enrichment comes before any ranking or assistant work in agentic commerce development.

How do AI agents check out and pay?

Checkout is where the money moves, and where most stores currently drop the agent. Three pieces have to fit together.

1. Consent and authority. The agent must prove it is allowed to spend. In practice that is a payment mandate or consent record: a scope-limited credential, an authorization token, and a stored consent stating what class of item it may buy and up to what amount. AP2 formalizes this as a Checkout Mandate and a Payment Mandate, each a signed, verifiable credential. An agent without proof of authority should not be able to spend. An agent with it should not need a human to approve every line item.
2. A payment method the agent can drive. A card on file, a wallet, or a delegated token, applied to the order through an API. Your checkout must accept a payment intent and return a confirmation, without bouncing the agent into a session cookie or a fresh login.
3. A human checkpoint where one still belongs. Returns and refunds, address changes, anything over the spend ceiling, and final confirmation on high-value or regulated purchases. The agent does the work and the person owns the decision.

The design rule is to separate authorization from execution. Put the human at the decision points and take them out of data entry. That split makes checkout fast for the agent and safe for the buyer. It also shrinks your attack surface, since a checkout that accepts machine traffic is a target for prompt-injected or compromised agents. Our piece on AI agent security covers the threat model for exactly this kind of tool-calling flow.

How an AI shopping agent picks between two stores

Discovery is no longer a results page a person skims. The agent solves a selection problem against structured criteria and picks the store that returns the most certain answer in the fewest steps. Roughly in order, it weighs:

• Match and certainty. Does your catalogue return the exact item with the exact attributes, or a near miss with fields missing?
• Availability confidence. Is stock current and machine-readable, or inferred and stale?
• Total cost as data. Price, shipping and tax expressed so the agent can compare them directly.
• Steps to a completed order. Fewer hops, fewer walls and fewer retries win.
• Trust signals it can parse. Structured ratings, a returns policy published as data, and a verifiable merchant identity.

Two stores selling the same product at the same price compete on latency and certainty. An agent arrives with a task and a budget and no loyalty to your brand, so if your store needs three API hops and a CAPTCHA to confirm a cart and a competitor confirms in one call, the competitor wins by default. Treat agent discovery as a funnel whose metric is "query to confirmed order," and instrument it that way.

Some agents reach stores through tool servers rather than direct API calls. If you plan to expose your catalogue or cart that way, read how MCP servers define tools and permissions before you publish one.

Attribution when the referrer is a model

The business model here is still open. When the shopper is an agent, the click that marketing attribution was built on does not happen.

An assistant surfaces your product, hands the purchase to an agent, and the agent completes it. There may be no browser, no UTM parameter and no last-click event. Your analytics records an order with no source. Three changes follow:

• Referral identity moves into the request. Agents and assistants can pass a source identifier or affiliate token through checkout, but only if your store asks for it and records it.
• Attribution becomes a declared field. You build the plumbing that accepts and stores "who introduced this order" instead of inferring it from a session.
• Platform terms are unsettled. The assistant platforms are still deciding whether and how they pass attribution, and what they charge merchants for agent-driven orders. Instrument for both cases: accept a token when one arrives, and fall back to first-party order metadata when it does not.

Add a source field to the order object, accept tokens in the checkout API and log them. You cannot optimize a channel you cannot see, and this one arrives without a referrer header.

AI agents in ecommerce, a readiness checklist for Shopify or headless stores

Most stores are two or three items away from being agent-transactable, and the first two items cost nothing but time.

• One stable ID per variant, with a GTIN or barcode where one exists.
• Variant-level price and currency, set on the variant rather than the parent product.
• Availability as data: current stock, a ship window, and one source of truth that both the page and the API read.
• JSON-LD Product and Offer on the product page that matches the API exactly.
• A checkout path that accepts a payment intent and returns an order confirmation without forcing a human login.
• An authorization model with scope-limited credentials, a spend ceiling and a consent record for machine-driven purchases.
• An attribution field on the order object that records the source token when present.
• Logging on "query to confirmed order," so you measure agent traffic separately from human traffic.

On Shopify, an agent reads two surfaces: the Storefront API and the structured data your theme emits. Keep them consistent. Shopify also publishes agent documentation covering catalogue search, cart building and checkout completion for agents, which is worth reading before you design your own endpoints. On a headless build you own both surfaces, which means more work and more control. Either way, run this list before you build anything new.

Is agentic commerce real yet, and what should you do first?

It is partly real. Assistants that shop are live, and people use them for low-risk purchases. The fully autonomous buyer that spends large sums with no human checkpoint is not here yet. Build for the part that exists: a machine-readable catalogue, trustworthy availability and a consent-gated checkout.

Start with product data and availability. Both lift human conversion too, so the work pays back even if agent traffic grows slowly. Add the attribution field next, before agent orders start arriving without one.

Ignore the model hype. A buyer-side agent does not need your store to run a model. It needs your store to return clean data and let a payment through, so spend on data plumbing and consent before you spend on another chatbot.

You do not need to build your own buying agent. You need your store to be legible to whatever agent the buyer uses. The seller-side assistant, a conversational sales agent a merchant runs for its own store, is a separate problem. Our AI commerce agent case study covers that side: a sales agent over social messaging, distinct from the buyer-side agent you prepare your store for.

Where to start this week

Pull a sample of 50 product pages, compare the JSON-LD against your API responses field by field, and count the mismatches in price, availability and variant IDs. That number tells you how far you are from being readable by AI shopping agents, and it gives you a backlog you can sort by revenue. Fix the data, expose checkout as an API with a spend ceiling, then add the attribution field.

If you want a team to do the catalogue and checkout work with you, see how we approach agentic commerce for merchants.