Agentic commerce rewards stores with clean data

Agentic commerce will reward merchants with boring, accurate systems. An AI shopper cannot rescue a vague variant, a stale price, or a checkout that changes totals without explanation. It will compare what your store says across a feed, product markup, cart response, and payment request. When those answers conflict, the agent has safer stores to choose from.

That changes the preparation order. A new chat widget is near the bottom of the list. The useful work is to make every sellable item machine-readable, keep commercial facts current, expose a checkout with explicit states, and preserve the buyer's authority through payment. Most of this work improves ordinary shopping integrations too, so a merchant does not need to bet the roadmap on one agent or protocol.

The first merchants to get this right will not win because they attached "AI" to the storefront. They will win because an agent can answer four plain questions without guessing: Is this the right item? Can it ship to this buyer? What will the buyer pay? What happens after the order?

AI shoppers consume a contract, not a storefront

Preparing a store for AI shoppers means turning the sales promise into a contract that software can inspect. The contract includes product identity, variant choices, price, stock, fulfillment, returns, checkout state, and order status. A polished product page still matters to a human, but it cannot be the only place where those facts live.

Search crawlers could tolerate some ambiguity because they mostly ranked pages and sent a person to resolve the rest. A buying agent may select a variant, assemble a cart, compare delivered prices, and ask for authorization. Ambiguity now sits inside a transaction. If the title says "wool jacket," the feed calls the material a blend, and the variant API omits lining details, the agent should not infer an answer.

Treat product discovery and transaction execution as separate paths. Discovery data can be cached and broad. Transaction data must be narrow and current. The catalog may say that a shoe exists in size 42, while the cart service decides whether that exact sellable unit remains available for the buyer's market. This distinction prevents a common and expensive mistake: making a discovery index responsible for reserving inventory.

The store also needs an explicit source of truth for each field. Product information usually leaks across a commerce platform, warehouse system, merchandising spreadsheet, search index, and tag manager. Pick an owner for SKU identity, price, available quantity, shipping promise, and return policy. Then document how each downstream surface receives updates. Without ownership, a protocol integration only distributes contradictions faster.

Do not build a special "AI catalog" by hand. It will drift from the store. Build a normalized commerce record from the same systems that serve the storefront, then map that record into each feed or protocol. The adapters can change as standards change. Your internal meanings should not.

One catalog record must settle every product question

A useful agent feed describes sellable variants, not attractive parent products. Color, size, pack count, subscription terms, regional eligibility, and condition belong on the item the buyer can actually put in a cart. A parent with six pictures and a price range is discovery material, not an orderable offer.

At minimum, every variant needs a stable merchant ID, a parent grouping ID where applicable, a plain title, a factual description, canonical product and image references, price with currency, availability, condition, brand or manufacturer identity, and a checkout reference. Physical goods also need weight or dimensions when they affect shipping, plus fulfillment regions and enough data to calculate delivery. Regulated or category-specific products need their relevant attributes rather than a generic paragraph.

Stable means stable. Do not recycle an old SKU for a new product because a spreadsheet makes that convenient. Agents, marketplaces, analytics, and support systems may retain the old identifier. Reuse turns a reorder into the wrong item and corrupts performance history.

Feed delivery needs deletion semantics as much as update semantics. If an item vanishes from an incremental export, a consumer cannot tell whether the merchant removed it or the export failed halfway through. Send an explicit tombstone for retired offers, give every batch an ID and completion marker, and keep a full snapshot available for reconciliation. Consumers should apply a batch atomically or retain the prior valid batch. A half-applied catalog can pair yesterday's variants with today's prices.

Regional offers need durable identity too. The same physical SKU can have different currency, tax treatment, price, warranty, delivery promise, and legal seller across markets. Do not hide those differences in translated description text. Either model a stable offer ID beneath the SKU or make market part of the offer identity, then require the agent to provide its locale and destination context before it presents a final claim.

Use one normalized record as the input to every adapter. This example is intentionally independent of any specific protocol:

{
  "merchant_sku": "shoe-1042-blue-42",
  "product_group": "shoe-1042",
  "title": "Trail shoe, blue, EU 42",
  "description": "Water-resistant trail shoe with a 6 mm drop.",
  "attributes": {"color": "blue", "size_system": "EU", "size": "42"},
  "price": {"amount": "129.00", "currency": "USD"},
  "availability": "in_stock",
  "condition": "new",
  "sellable_regions": ["US"],
  "return_policy_id": "returns-us-standard",
  "updated_at": "2026-08-09T10:15:00Z"
}

The updated_at field does not make stale data fresh, but it lets a consumer reject or recheck an old snapshot. Keep amounts as decimal strings if your surrounding contract requires exact decimal representation. Never let a binary floating-point conversion turn 129.00 into an unexpected cart total.

Validate the export in continuous integration, not after a marketplace rejects it. A small check catches missing identity, invalid amounts, and absent policy references before deployment:

jq -e '
  .merchant_sku != "" and
  (.price.amount | test("^[0-9]+\\.[0-9]{2}$")) and
  (.price.currency | test("^[A-Z]{3}$")) and
  (.availability == "in_stock" or .availability == "out_of_stock") and
  (.return_policy_id != "")
' product.json

Successful output is true; failure returns a nonzero exit status. Run the same validation against samples from every category because apparel variants, made-to-order furniture, digital goods, and subscriptions fail in different fields.

Structured data should agree with the feed

Product structured data is a reconciliation surface, not a replacement for a feed or commerce API. Put Product and Offer markup on the canonical product page, and make its identity, price, currency, condition, and availability agree with the variant a buyer can select on that page. When a page covers several variants, represent the relationship clearly instead of publishing one convenient price for the whole family.

Google Merchant Center documentation explicitly recommends price, priceCurrency, availability, and condition for automatic item updates. Google Search Central also documents shipping details and MerchantReturnPolicy, including the return window, method, and fees. Those properties matter to agents for the same reason they matter to merchant listings: delivered cost and reversibility can change which offer is suitable.

Markup cannot repair a bad operating model. If a client-side script inserts the current price after several requests, some consumers will observe the old HTML while others see the new state. Render critical commercial facts predictably, and test the result that a crawler or plain HTTP client receives. A browser screenshot proves presentation, not machine readability.

Choose a precedence rule before systems disagree. Google documents a precedence order for its own merchant surfaces, with product-level feeds above several markup and account-level sources. Your internal rule can differ, but it must be explicit. I normally let the transaction service own current price and stock, the policy service own returns and shipping rules, and the catalog own descriptive attributes. The page and external feeds become projections of those owners.

Run a daily comparison across page markup, primary feed, and product API for a sample that includes top sellers, long-tail products, sale items, and every variant type. Compare exact SKU, price, currency, availability, and policy ID. Alert on mismatches, not merely missing markup. A beautifully valid block that says the wrong price is worse than no block because it looks trustworthy during testing.

SEO does not disappear in agentic commerce. Clear product names, complete attributes, original descriptions, and accessible policy pages still help a system retrieve and evaluate an offer. The shift is that persuasion has less room to hide missing facts. Write copy for people, then expose the claims an agent must verify as structured fields.

Fresh inventory beats richer copy

An agent needs a fresh answer at the moment it creates or updates a cart. A nightly feed can support discovery, but it cannot safely promise the last unit at noon. The cart endpoint should reprice every line, recheck availability, apply market rules, and return any change as structured data.

Separate three meanings that teams often collapse into one boolean. "Discoverable" means the item may appear in search. "Sellable" means this buyer can order it in a given market and channel. "Available" means inventory or capacity exists now. A discontinued product may remain discoverable for accessories, while it is neither sellable nor available. A product restricted in one country can be available in the warehouse but unsellable to that buyer.

Update speed should match business volatility. Fast fashion drops and event tickets need event-driven changes. A made-to-order table may tolerate a slower catalog update but still needs current production lead time. Set a freshness budget per field, such as minutes for price and stock and hours for descriptive enrichment, then measure violations. One universal cache duration is easy to configure and usually wrong.

Return reasons that software can act on. out_of_stock is better than "Something went wrong." Better still, include the affected SKU, requested quantity, available quantity when safe to disclose, and allowed remedies such as reducing quantity or choosing another variant. Do not silently substitute a color, size, seller, or refurbished item. The buyer authorized a specific offer.

Test the ugly race. Two agents read the last unit, both start checkout, and only one can receive it. Decide whether cart creation reserves stock, how long a reservation lasts, and what the second checkout receives. If reservation happens only after payment authorization, disclose that earlier availability is provisional. The right policy depends on the product, but an implicit policy produces duplicate apologies and refund work.

Sale boundaries deserve the same attention. A feed may advertise a sale at 23:59 while a cart prices after midnight. Return the new amount and force renewed approval. Never treat the buyer's earlier consent as permission for a higher total.

Checkout protocols split the job into distinct layers

There is no single protocol that makes a store "agent ready." Current specifications divide discovery, cart state, checkout, payment instruments, and proof of authorization. Merchants should preserve those boundaries inside their architecture even if they adopt only one external integration.

The Agentic Commerce Protocol, maintained by OpenAI and Stripe, defines an interaction model for agents and merchant checkout. Its public specification uses dated versions and remains labeled beta. The merchant keeps the merchant-of-record role, accepts or declines the order, processes payment through existing systems, and owns fulfillment and support. ACP is relevant when a supported agent surface or payment partner sends buyers through that contract.

The Universal Commerce Protocol covers a broader commerce flow with capability discovery, carts, checkout, and orders. Its checkout specification uses a merchant profile and explicit states. Shopify's UCP documentation distinguishes an exploratory cart from a checkout session, requires authentication or a signed request for checkout tools, and provides a continue_url when the buyer must return to the merchant. It also warns that one cart update operation uses replacement semantics, so omitted fields disappear. That small detail is exactly the kind that creates lost line items when an integration assumes patch behavior.

Google's Agent Payments Protocol solves another problem: evidence that the user authorized an agent to pay. Google's developer guide distinguishes UCP's record of what is being ordered from AP2's record of who approved the purchase. AP2 uses an intent mandate, a payment mandate tied to a cart and amount, and a receipt. Do not claim AP2 compliance because you store a checkbox next to an order. Signed authority, scope, expiry, and transaction binding are the substance.

These protocols overlap and will keep changing. Do not implement every draft behind one giant endpoint. Put a stable internal checkout service behind thin ACP, UCP, or partner adapters. Version each adapter, store the inbound protocol version with the order, and keep contract tests built from published examples. When a field or status changes, you should replace an adapter rather than rewrite pricing and fulfillment.

A platform-native handoff is a reasonable first release. If your commerce platform can create a prefilled cart and send the buyer into the normal hosted checkout, you can support agent-assisted discovery without accepting delegated payment. That path has more friction, but it preserves mature tax, fraud, address, and compliance controls while the protocols settle.

Your checkout needs states, handoffs, and idempotency

An agent checkout should return what happened and what must happen next. A generic HTTP success code does not tell an agent whether the cart needs an address, the buyer must approve a changed total, or the merchant has accepted the order.

Model checkout as a state machine. UCP's public flow includes states such as incomplete, requires_escalation, and ready_for_complete. Your internal names do not have to match, but every state needs allowed transitions, a responsible actor, and a recovery action. Terminal states must stay terminal.

A useful response shape makes changes visible:

{
  "checkout_id": "chk_7f31",
  "status": "requires_escalation",
  "currency": "USD",
  "line_items": [{"sku": "shoe-1042-blue-42", "quantity": 1, "unit_amount": "129.00"}],
  "totals": {"items": "129.00", "shipping": "12.00", "tax": "11.63", "grand_total": "152.63"},
  "messages": [{"code": "buyer_approval_required", "field": "totals.grand_total"}],
  "continue_token": "handoff_29b8",
  "expires_at": "2026-08-09T10:30:00Z"
}

The response separates display text from a stable machine code. It identifies the field that needs attention, gives the agent an opaque handoff token, and puts an expiry on a quote. In production, bind that token to the checkout, buyer session, allowed action, and short lifetime. Do not place card data, a full address, or reusable credentials in it.

Require an idempotency token on every operation that can reserve stock, authorize payment, or create an order. Store the token with a hash of the request and the result. If the same token arrives with the same payload, return the original result. If it arrives with a different payload, reject it. A network retry must not create a second order.

Trace one attempt across every boundary. Generate a correlation ID when an agent starts a cart, pass it through repricing, tax, shipping, payment, order creation, and notifications, and return a safe reference in errors. Logs should record state transitions and reason codes without copying personal or payment data. When support sees a charged buyer with no confirmation, the team needs to determine whether capture succeeded, order creation timed out, or the response disappeared. Five disconnected request logs will not answer that quickly.

Timeouts need business outcomes, not blind retries. If payment authorization returns an unknown result, query the processor by idempotency token before trying again. If order creation times out after the database commits, return the stored order on retry. Test both failures by forcing the connection to close between the side effect and the response. Happy-path contract tests miss the duplicate orders that damage trust.

Keep calculation on the merchant side. The agent may propose a coupon, shipping method, or address, but the merchant calculates eligibility, tax, shipping, and the final amount. Return a new version whenever a material field changes. The authorization must bind to that version and amount.

Handoffs need continuity. When the buyer opens the merchant checkout, show the same items, variant details, totals, and applied discounts the agent presented. Explain any change before asking for confirmation. Preserve attribution separately from identity so a missing marketing parameter cannot break the checkout.

Delegated payment does not delegate merchant risk

The merchant remains responsible for deciding whether to accept an order, even when an agent supplies a payment token and the buyer's signed authority. Protocol support does not erase fraud, sanctions, tax, age restrictions, chargebacks, privacy obligations, or card-network rules.

Use scoped payment credentials. OpenAI's description of agentic checkout says payment tokens are limited to a particular merchant and amount with user permission. AP2 similarly binds evidence to intent and transaction details. A reusable card credential passed through an agent creates a much larger breach surface and gives the merchant weak evidence about what the buyer approved.

Keep authorization and capture separate where the business needs an acceptance check. A merchant selling scarce, customized, or regulated goods may need to validate stock or eligibility before capture. Record the checkout version, line items, amount, currency, buyer confirmation event, agent identity, mandate or token reference, and processor outcome. Store references rather than sensitive payment material when possible.

Agent identity is useful input, not proof that an order is safe. Authenticate the calling platform, verify signatures, enforce timestamps and replay protection, and assign rate limits by trust level. Then run ordinary merchant controls against the buyer, shipping destination, basket, and payment result. A known agent can still carry a compromised user account or an abusive instruction.

Rotate verification credentials without breaking active checkouts. Publish the current and next public identifiers, accept a short overlap, and record which credential verified each request. Reject an unknown identifier before parsing a large body, cap request size, and compare signatures in constant time through a maintained cryptographic library. These are ordinary API controls, but delegated purchasing gives an attacker a direct route to reservations and payment attempts if the controls are weak.

Minimize buyer data. Ask for an email, phone number, or address only when the current step needs it. State whether the agent or merchant will send confirmations and support messages. If a handoff can collect sensitive details inside the merchant's existing checkout, prefer that over copying them through another system.

Build a manual review path that does not dead-end the agent. Return a stable status, a reason category safe to expose, and a continuation method. Do not reveal fraud rules in diagnostic detail. Tell the buyer when the merchant needs a human decision and keep the cart stable during the promised review window.

The order is not finished when payment succeeds

An agent that placed an order will later ask about shipment, cancellation, return eligibility, exchange options, and refunds. If those answers exist only in human support macros, the shopping experience breaks immediately after conversion.

Create a machine-readable order record with durable item identity, fulfillment status, shipment events, cancellation eligibility, return window, refund state, and support escalation. Use the same policy IDs exposed during discovery. If the product advertised a 30-day return window, the order service should calculate and return the actual deadline from the relevant event, not restate "30 days" and make the agent guess.

Publish status changes as events and support a current-state read. Webhooks provide speed, but consumers miss and duplicate them. Every event needs an event ID, order ID, event type, occurrence time, and schema version. The receiving agent or platform should acknowledge idempotently, while a get_order style operation repairs missed history.

Decide who owns customer communication before launch. The merchant usually remains the merchant of record and support owner under current commerce protocols. Confirmations must identify the merchant, describe the order, and give the buyer a usable path for help. An agent surface can relay the message, but it should not become the only copy of the receipt.

Returns expose catalog shortcuts. Support needs the exact purchased variant, condition sold, price paid, discounts allocated, fulfillment route, and policy version. A current product page cannot reconstruct those facts after merchandising edits. Snapshot the commercial terms on the order.

Attribution also needs first-class fields. Record agent or channel identity, referral context allowed by the protocol, checkout adapter and version, handoff versus delegated completion, and timestamps for discovery, cart, approval, and order creation. Do not overload coupon codes or free-text notes. You need to compare agent-originated orders with ordinary orders on accepted checkout rate, cancellations, returns, support contacts, fraud review, and contribution margin.

Conversion alone can lie. An agent may send fewer but higher-intent visits, or it may create carts that fail when shipping appears. Measure each state transition and reason code. That tells product and operations teams whether the next fix belongs in catalog data, fulfillment, trust, or checkout.

Early merchants should prove one narrow path

The sensible early move is one category, one market, one checkout path, and real operational ownership. Broad catalog exposure feels ambitious, but it multiplies variant, tax, shipping, and policy edge cases before the team understands the failure modes.

Choose a category with clean identifiers, manageable variants, predictable fulfillment, and ordinary returns. Avoid the hardest regulated, customized, subscription, or marketplace inventory in the first release. Then run a readiness sequence:

1. Map the source of truth and freshness budget for every commercial field.
2. Export normalized variant records and fail the build on contract violations.
3. Reconcile feed, page markup, product API, cart, and checkout totals.
4. Add idempotent checkout operations, explicit states, and a human handoff.
5. Replay stock races, price changes, payment retries, cancellations, and returns before live traffic.

Do not wait for a winner among ACP, UCP, and payment authorization protocols. Build the internal contract and observability that all of them require. Add an adapter only when a real distribution partner, commerce platform, or customer path justifies its ongoing maintenance. Protocol announcements are not demand.

Assign one owner across merchandising, engineering, payments, fulfillment, and support. Agentic checkout crosses all five, and a committee will leave gaps between them. Review failed sessions weekly by reason code and trace them back to the owning system. Fix repeated data faults at the source rather than adding agent prompts that explain around them.

For founders who cannot tell whether the bottleneck is catalog data, checkout architecture, or team execution, the Team & AI Audit I offer through oleg.is is a fixed $5,000, five-business-day engagement that identifies at least $50,000 a year in savings or costs nothing.

The first production target is modest: an agent can identify one exact variant, receive a current delivered total, preserve the buyer's approval, create no duplicate order under retries, and answer what happened afterward. If your store can do that consistently, new agent channels become adapters. If it cannot, another feed submission will only make the failure easier to discover.