Agentic commerce: prepare your catalog before promising AI sales

Separate discovery, integration and transaction

A product can be discovered on the web without the store having an in-conversation purchasing integration. A technical integration can also exist without a product being selected for a recommendation. These are different capabilities, with different requirements and owners.

Before commissioning development, ask the proposal to identify the intended experience, current documentation, eligibility conditions and where payment occurs. Record which responsibilities belong to the catalog, the platform and the merchant. This makes a budget easier to assess and prevents a feature announced for a limited group from being sold as universally available. Keep those assumptions attached to the project brief as conditions change.

Sources: OpenAI: Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol · OpenAI: Powering Product Discovery in ChatGPT

Establish a reliable catalog source

Begin with a limited product group the business can maintain. Record a stable identifier, descriptive name, brand, variants, owned or licensed images, price, currency, availability and destination URL for each item. Every field needs an owner and an update rule; a perfect file today can be misleading tomorrow.

We recommend treating variants as a commercial decision rather than a footnote. When size, color or package changes, verify that the image, price and inventory match the selection. If a field is not yet trustworthy, repair the operational process that produces it before automating distribution. Adding more export destinations increases the cost of an unresolved source error.

Align visible and structured information

Google documents several ways to supply product information, including structured product data on pages and Merchant Center feeds. That guidance helps assess consistency. It does not establish that another provider’s integration is complete or guarantee inclusion in an AI answer.

Compare the same product on its page, in the exported catalog and in the cart. Record differences in currency, price, selected variant and availability. Prevent an expired discount from remaining in a feed or a landing page from displaying a promotion the checkout will not honor. The objective is a customer-verifiable offer regardless of the discovery channel, not simply a technically valid file.

Sources: Google Search Central: Introduction to Product structured data

Illustrative example: stock in the wrong delivery area

Imagine a store that delivers to one region but distributes the same catalog nationally. An assistant may help someone discover an item, yet the customer only learns about the delivery restriction after entering an address. This hypothetical example is not a test conducted on a Patagonia client.

The first task would be to make coverage clear, determine whether inventory depends on location and check how restrictions are communicated before payment. We would then review the data sources feeding the intended shopping experience. Connecting a new channel without resolving these boundaries can send more people into a journey that ends in frustration rather than increase useful demand.

Test the exceptions that affect trust

One successful test purchase does not cover the common failure paths. Prepare scenarios for an unavailable variant, an out-of-area address, a changed price, an invalid coupon, a declined payment and a return request. Use a test environment when available and coordinate any real transaction with the store’s responsible owner.

For each scenario, record the customer-facing message, the order state and the support response. Keep personal and payment information out of test documents. The team should explain who sells, who collects payment, how an order is confirmed and how an incident is resolved. These are parts of the commercial experience, not details to postpone until the integration launches.

Choose the next step using operational criteria

The first deliverable should be a small matrix: product, data quality, observed error, owner and technical dependency. Then choose a pilot with acceptance criteria, such as consistent variants and accurate delivery explanations. Measure errors, journey completion and support inquiries before broadening the catalog.

If the merchant cannot yet maintain its data, prioritize catalog operations and web design. If those foundations work, evaluate a specific integration for the relevant platform and market. Patagonia can connect commercial and technical review; channel access and sales outcomes are verified separately. Good preparation retains value even when a provider changes its shopping experience, commercial requirements or supported integration path.