AI shopping agents reward stores that tell the truth

AI shopping agents do not make a weak commerce operation smarter. They expose every disagreement your storefront has learned to hide. If a feed says a jacket costs $89, the page says $99, and checkout says the blue medium is unavailable, an agent has no polite way to reconcile the three. It either drops the product, reports uncertain facts, or sends a buyer into a failed purchase.

A store is ready when product discovery and purchase run on the same operational truth. That means stable product identity, complete attributes, fresh price and inventory, explicit delivery and return terms, and a checkout that behaves predictably through an API or an ordinary browser. A new protocol can carry that truth. It cannot create it.

I would fund catalog and checkout repair before a dedicated storefront for agents. The first work earns returns across search, marketplaces, support, paid acquisition, and your own site. The specialized integration comes later, once the underlying answers stop changing depending on which system asks.

Discovery begins with catalog truth

An agent can recommend only what it can identify, compare, and verify. Marketing copy helps a human imagine a product, but agents need facts tied to a stable item. A title such as "Premium everyday essential" wastes the most informative field. It does not say whether the item is a shirt, what it is made from, who it fits, or which version the price describes.

Treat the feed as a product database export, not a campaign asset. Every sellable variant needs a durable merchant ID or SKU. The product family needs a clear relationship to its variants. Brand, manufacturer part number, and a valid GTIN belong in the record when they exist. Never fabricate an identifier to fill a required column. A false GTIN can merge your offer with the wrong product, which is worse than admitting that no GTIN exists.

The descriptive fields should answer comparison questions in plain language. Dimensions need numbers and units. Compatibility needs exact models, standards, or limits. Materials should distinguish solid wood from veneer, and cotton from a blend. A food record needs quantity and dietary facts. A replacement part needs the machines it fits. These details are not decoration for rare searches. They are often the constraints in a buyer's request.

Images also carry product data. Use a primary image that shows the exact variant without promotional text covering the item, then add views that answer size, texture, fit, scale, or questions about included components. An agent may use image understanding, but it should not have to infer that a cable is two meters long from a staged photograph. Put the length in a field and in visible page copy.

One distinction saves months of misguided work: discoverability is not buyability. A crawler might understand your page while the purchasing agent cannot select a valid variant or obtain a delivery quote. Measure those capabilities separately. If you combine them into one "agent ready" score, a healthy search result can conceal a broken transaction.

Product identity must survive comparison

A product record is trustworthy when its identity stays stable across the feed, structured data, product page, cart, order, and system used after purchase. Many stores accidentally assign identity to a page URL. That works until a color selector changes the SKU without changing the URL, a regional storefront rewrites the path, or a merchandising team replaces the product behind an old landing page.

Use three layers deliberately: a product family, a sellable variant, and an offer. The family is the model a buyer compares, such as one running shoe design. The variant is the actual combination of size and color. The offer states how that variant can be bought in a market, including price, currency, condition, availability, and seller. A SKU should not mean a family in the feed and a variant at checkout.

Variant attributes must use controlled values. If the catalog calls the same color "navy," "midnight," and "dark blue," decide whether those labels describe one value or distinct colors. Keep the public name, but map it to one internal value. Do the same for apparel sizes, storage capacity, packs, subscriptions, and refurbished grades. Agents compare literal constraints, so ambiguous labels become false matches.

Bundles and minimum quantities need special care. The displayed price must describe the minimum purchasable unit, not an attractive unit number that checkout will multiply. Subscription products need the initial charge, recurring amount, interval, commitment, and cancellation terms stated as separate facts. If a product requires another component, record that dependency. "Works with our system" is meaningless when the buyer asked whether it works with a named interface standard.

Build an identity trace for a sample order. Start with the feed item ID and follow it through page markup, cart line, tax calculation, fulfillment record, confirmation, refund, and analytics event. Any manual mapping or lost variant attribute marks a defect. This exercise catches the familiar failure where the storefront sells the right red lamp but the warehouse receives only the parent lamp ID.

Structured data is a contract, not decoration

Structured data should reproduce visible product truth in a form machines can read, not present a cleaner version of reality to crawlers. Google Search Central describes merchant listing markup with a Product object and an Offer, including price, availability, shipping, and return information. Google Merchant Center also requires submitted price and availability to match the landing page, checkout, and structured data. That agreement is the useful part of the guidance. Rich result eligibility is secondary.

JSON-LD is usually the easiest format to generate and inspect. Render it from the same commerce service that supplies the visible price and stock. Do not paste static markup into a theme when those values change independently. The following example is intentionally small enough to audit, while still identifying one exact variant and its offer:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail jacket, navy, medium",
  "sku": "TJ-NV-M",
  "gtin13": "0123456789012",
  "color": "Navy",
  "size": "M",
  "image": ["https://shop.example/products/tj-navy-front.jpg"],
  "offers": {
    "@type": "Offer",
    "url": "https://shop.example/products/trail-jacket?variant=TJ-NV-M",
    "price": "89.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

Replace the example identifiers and URLs with real ones, and validate the GTIN check digit rather than copying the sample. For products with variants, use the vocabulary and structures supported by the destination you care about, such as ProductGroup and variant relationships where accepted. Support differs across consumers. A valid Schema.org property is not proof that every agent reads it.

Render the essential markup on the server when practical. A crawler that must execute a large application in the browser can see delayed, partial, or personalized state. The visible page and JSON-LD should come from one resolved product snapshot. If your price changes by market, create an explicit market context rather than guessing location from an IP address and returning an unexplained currency.

Validation has two levels. Syntax validation asks whether the JSON-LD parses and uses recognized properties. Semantic validation asks whether the named SKU, price, currency, availability, condition, and URL describe the offer a buyer can actually purchase. Teams often celebrate the first while failing the second. Run both in release checks.

Freshness beats descriptive polish

Fresh price, stock, and delivery data matter more than a beautifully rewritten description. Agents assemble an answer at one moment and may attempt the transaction minutes later. A stale field converts a relevant recommendation into a broken promise.

Choose one system of record for each volatile fact. The commerce platform may own base price and stock, a promotion service may own discounts, and a fulfillment service may own delivery estimates. Your feed publisher can combine them, but nobody should edit the output by hand. Every value should carry an update time internally, even if the public format does not expose it. That gives operators a way to tell whether "in stock" came from thirty seconds ago or yesterday's export.

Set freshness objectives by failure cost. A unique chair with one unit left needs faster inventory updates than a digital template with unlimited delivery. A flash price needs an exact activation and expiration time. A product made on demand needs production capacity and lead time, not a generic in-stock flag. The point is not universal real time. It is a stated maximum age that matches the promise.

Google Merchant Center's product data specification is blunt about consistency: price and availability should match the feed, landing page, structured data, and checkout. Its automatic item updates can correct some mismatches, but its own documentation says those updates do not replace regular feed maintenance. Treat correction by a channel as an alarm that your publishing path is late.

Monitor the path, not just the export job. A successful file upload proves that bytes moved. It does not prove that all variants arrived, that a currency stayed attached to each amount, or that zero inventory changed to out of stock. Track catalog count, variant count, rejected item count, age of the oldest volatile record, and disagreement rates between feed, page, and checkout. Alert on sudden distribution changes, such as half the catalog losing brand or every shipping weight becoming zero.

Caches need explicit invalidation. Purge or version page data when price and availability change. Keep the product URL stable, but do not let a CDN preserve an obsolete offer past your promised freshness window. If your feed publishes hourly while the page cache lives for a day, the store will contradict itself by design.

Variant logic must be explicit

An agent should receive valid combinations, not every theoretical combination of attributes. A product page can visually gray out impossible choices. A feed or API must state them. If a sofa comes in three fabrics but one fabric allows only two sizes, publishing a Cartesian product creates offers that cannot reach the cart.

Model each purchasable combination as a variant with its own ID, price, availability, image, and relevant attributes. Keep the family relationship so an agent can present options without treating each color as an unrelated model. When an option changes price or lead time, return the revised total and promise before the buyer approves.

The common failure looks harmless. A feed exports the parent shoe with a price range and marks it in stock because at least one size exists. The agent recommends it to a buyer who requested size 10 under $120. The page opens on the cheapest size 7 at $109. Size 10 costs $129 or is sold out. Discovery used family truth to answer a question about a variant, so every component behaved as built and the customer still got a false answer.

Do not solve this by deleting variants from discovery. That popular shortcut reduces feed complexity, but it also removes the facts an agent needs to satisfy constraints. Export complete variants and group them. When a destination accepts only one landing URL, use a stable variant parameter or server state that opens the exact choice. The SKU in structured data must then match the selected choice.

Substitutions require buyer intent, especially for groceries, parts, and regulated items. Record whether substitution is allowed, what attributes must remain equal, and whether price can rise. A generic "similar item" rule may swap an allergen, incompatible connector, or wrong pack size. The agent needs limits that your fulfillment system can enforce, not a prose suggestion that disappears after checkout.

Checkout must work without a browser

Checkout compatibility means the merchant can calculate and commit the same order through a deterministic interface, while still owning price, tax, inventory, payment, fulfillment, and support. It does not mean letting an agent click through a consumer page and hope selectors remain unchanged. Browser automation can help test a fallback, but it is a brittle purchase contract.

The Agentic Commerce Protocol, maintained by OpenAI and Stripe, makes this separation concrete. Its current beta specification uses versions named by date and defines operations to create, update, complete, inspect, and cancel checkout sessions, plus order events. The merchant returns the authoritative cart state, including line items, fulfillment options, discounts, taxes, totals, status, and errors. The agent presents choices; the merchant still decides what can be sold and remains responsible for the order.

That protocol may not be the only channel you support, and its details can change. Put an adapter in front of a stable internal commerce service. The adapter translates a channel request into your own commands: quote this cart, reserve these items, select this delivery option, apply this promotion, authorize this scoped payment, and place the order. A protocol version then changes at the edge instead of leaking into inventory and order logic.

Guest checkout is the cleanest baseline. If an account is mandatory, expose account creation and consent without requiring an inbox detour that the agent cannot complete. Never hide a required membership, phone verification, or app installation until the final step. State market restrictions before collecting payment information.

A checkout response must explain recoverable errors. "Invalid request" is useless when a postal code is unsupported, an item sold out, or a promotion expired. Return a stable machine code, a safe message for the customer, the affected field or item, and the refreshed cart state. The agent can then ask for a different address or variant rather than abandoning the order.

Keep the confirmation boundary explicit. Preparing a cart is not permission to buy. Bind payment authority to the merchant, amount, currency, and a short validity window where your payment provider supports it. Recalculate the complete cart immediately before order creation, and require new approval if the amount or material terms changed.

Agent checkout is distributed systems work

Reliable agent checkout depends on idempotency, authentication, signed events, bounded retries, and observable state transitions. Teams that treat it as another interface route eventually create duplicate orders or carts that the agent and merchant remember differently.

Every mutation should accept an idempotency key. Store the result against the caller and operation, then return that result when a retry arrives. Do not merely check whether an order with the same cart exists. Two legitimate purchases can contain the same products, while one request that timed out can otherwise produce two charges.

Authenticate the calling agent and authorize each operation. Verify request signatures before parsing business fields, use HTTPS, rotate credentials, and reject timestamps outside a narrow window. Sign outbound webhooks and give each event a durable ID. The ACP documentation explicitly calls for authenticated requests, signatures, idempotency, input validation, and safe retries. Those controls are not protocol ceremony. They describe failures payment engineers already know.

Keep a state machine with allowed transitions. A checkout might move from open to ready for payment, then completed, canceled, or expired. An order has a separate life after completion. Do not let a delayed update reopen a completed checkout or let a cancel race erase an order that already exists. Compare versions or use conditional writes when two requests can touch the same session.

Log enough to reconstruct a purchase without storing unnecessary payment or personal data. Record request ID, idempotency key, authenticated caller, checkout version, item IDs, totals, transition, response code, and related order ID. Redact credentials and sensitive address fields. The support team should be able to answer whether the agent repeated a call, the merchant changed a quote, or the payment provider timed out.

Fraud systems also need agent context. Deterministic traffic may look unlike human browsing, while a malicious bot may imitate an agent. Do not relax fraud checks for anything with "agent" in its user agent. Pass verified channel identity and delegated payment context into risk decisions, preserve normal velocity limits, and watch approval and dispute rates by channel.

Policies must give explicit answers

Shipping, returns, warranties, subscriptions, and restrictions belong in structured operational data because they decide whether a product fits the request. An agent asked for a gift arriving by Friday cannot use a generic "fast shipping" claim. It needs a delivery option, destination, cost, cutoff, and estimated arrival for the actual cart.

Keep broad policies on stable public pages, then return terms for each order during checkout. The catalog can state that a product is returnable and identify the applicable policy. The quote should resolve exceptions, return window, return cost, final sale status, and market rules. If a policy differs for oversized items, hygiene goods, digital products, or clearance stock, encode the exception instead of expecting an agent to interpret legal prose.

Customer support handoff needs the same clarity. Return an order reference and the merchant's support route after purchase. Order events should communicate accepted, shipped, delayed, canceled, refunded, or states that require action without forcing the agent to scrape an account page. The merchant remains accountable for fulfillment even when another interface presents the transaction.

Consent must be specific. Ask only for data required for the chosen fulfillment and payment path, explain material subscription or recurring terms before approval, and avoid preselected extras. If an agent sends more personal data than the order needs, ignore or discard the surplus according to your data policy. Agent access does not justify collecting a richer customer profile.

I argue against starting with an llms.txt file, a shopping chatbot, or a prose page called "AI policy." These additions are easy to announce because they do not touch old systems. They also do not repair a wrong SKU, stale inventory, unquotable shipping, or a checkout that creates duplicate orders. Publish explanations for machines when a channel uses them, but treat operational data and transaction behavior as the work.

Test the purchase, not the page

A test of readiness should begin with a buyer constraint and end with a reconciled order, refund, or deliberate rejection. Page validation belongs inside that test, but a green structured data result alone proves very little.

Use a small matrix of products that forces your hard cases: one ordinary item, one variant family, one item with little stock, one promotion, one restricted destination, and one product with a special return rule. Run each case in a staging environment with tax responses resembling production, inventory, fulfillment, and payment responses. Then execute this sequence for every supported agent channel:

1. Retrieve the feed record and confirm identity, attributes, market, price, stock, images, policy references, and update time against the source systems.
2. Fetch the exact product page, parse its structured data, and compare the selected variant and offer with both visible content and the feed.
3. Create a checkout, change quantity and address, select fulfillment, and verify that every response returns a complete recalculated cart with usable errors.
4. Submit the same completion request twice with one idempotency key, then retry with a different request ID. Confirm that only one payment and order exist.
5. Change stock or price during an open session, require a fresh approval when needed, finish or reject the purchase, and reconcile the agent state with payment, order, inventory, and notification records.

Add cancellation, expiration, refund, webhook retry, and delayed fulfillment events after the basic path passes. Test unsupported locations and unavailable variants as successful rejections: the right result is a specific, stable error, not an order at any cost.

Score discovery and transaction separately. Discovery measures eligible catalog coverage, attribute completeness, feed age, identity consistency, and offer disagreement. Transaction measures quote success, checkout completion, duplicate prevention, error recovery, order reconciliation, and event delivery. Segment both by market, device or agent channel, and product type. A single overall conversion number will not tell you whether agents choose the wrong items or fail after choosing the right ones.

Run synthetic purchases on a schedule and after commerce releases. Use inexpensive test products or payment test modes where systems allow them, but keep the same tax, promotion, inventory, and fulfillment code paths. A mock that skips those services proves only that the mock works.

Readiness is an operating model

Agent commerce is worth preparing for, but protocol work should follow evidence of catalog and checkout health. OpenAI's product discovery direction now emphasizes merchant feeds and lets merchants use their own checkout experiences, while ACP supports deeper programmatic checkout. That split is a reminder to keep discovery, transaction, and payment as separate capabilities with shared truth. A store may choose one level now and add another when the channel, market, and economics justify it.

Assign one owner to the complete promise, even if several teams own its components. Merchandising may own descriptions, commerce engineering may own checkout, operations may own stock, and finance may own payment reconciliation. Someone still needs authority to stop a release when those systems disagree. Otherwise each dashboard stays green while customers receive false answers.

Put catalog contract tests in deployment, freshness alarms in operations, and reconciliation for agent channels in the weekly commerce review. Treat feed rejections, structured data drift, quote errors, and duplicate attempts as product defects with owners. Record protocol versions at the adapter boundary and rehearse an upgrade before a channel removes an old version.

For founders with a store and a small engineering team, this is a good use of a Team & AI Audit from oleg.is: map the data and checkout bottlenecks, identify automation work, and avoid hiring a separate team around inconsistent systems. The useful result is not an agent demo. It is a store that can state an offer once, update it on time, accept a constrained purchase safely, and prove what happened afterward.

If your team cannot trace one variant from feed to refund today, do that before opening another commerce channel. The trace will show exactly where the store stops telling one coherent story.