What Product Data Do AI Shopping Agents Need? Product Truth, Offers, Feeds and Agentic Commerce

AI shopping does not remove the need for governed product data. It adds another destination for it. The useful architecture separates relatively stable product and variant facts from fast-changing seller and offer state, then exposes the right combination through the feed, catalogue or tool interface each shopping surface expects. Sources as at 6 September 2026. OpenAI product feeds and Shopify's agent-facing catalogue tools are current operational examples. Google's Universal Commerce Protocol checkout integration in Merchant Center is still early access in the United States for select merchants, so it is treated separately below.

Separate product truth from offer truth

A product does not become a different product because a retailer changes its price at lunchtime. Equally, a technically correct product description is not enough to transact if the offer is out of stock.

That is why the first useful split is between product truth and offer truth.

The split is architectural, not ideological. A commerce platform may already be the right owner for price and availability. Copying those fields into a PIM simply to say that everything lives in one place can make the data staler rather than better.

For stable facts, the stronger rule is one governed answer for each fact, with authority and evidence made explicit. For dynamic offer state, use the system that can maintain the current seller context and publish it reliably.

What OpenAI's supported product feed requires now

OpenAI's current Agentic Commerce product feed specification is a useful concrete example because it is not an abstract future architecture. The Stable schema is a supported discovery feed today.

The feed is oriented around the purchasable item or variant, not just a high-level product family. It expects stable identity and seller context, and it includes current commercial state such as price and availability. That is exactly the pattern above: a destination representation combines reusable product facts with current offer facts.

OpenAI also separates its Stable and Draft schemas. The Merchant Feed Terms of Service and product specification make clear that the feed specification can change, while the Draft schema is for planning and feedback rather than production support. Requirements for advertising and checkout are separated from the discovery feed.

That distinction matters operationally. A business should not treat an experimental field or a future checkout concept as if it were already a stable production requirement. It should version the destination mapping and know which schema it is producing against.

A feed submission also does not certify the factual truth of every attribute in the row. It shows that data has been supplied in a form the destination can consume. If a consequential product claim matters, the evidence for that claim still belongs in the upstream governance model.

What Google UCP adds, and why early access matters

Google's current UCP implementation shows a second pattern: agentic commerce can sit on top of existing merchant product data rather than replace it.

As at 3 September 2026, Google's Merchant Center UCP integration guidance describes gradual early-access onboarding in the United States, with checkout available for select merchants. That is real implementation activity, but it is not evidence of universal availability across merchants or countries.

Google's preparation guidance for UCP also recommends supplemental product data for UCP-specific needs such as checkout eligibility, consumer notices and identifier mapping.

That is a useful architecture signal. The agentic-commerce layer can be a destination overlay. The underlying product record does not have to be rebuilt around one destination's eligibility flags or notices. Instead:

1. govern the reusable product facts once;
2. keep current Merchant Center and seller data where it is maintained;
3. add UCP-specific fields and validation for that destination;
4. record the destination status separately.

The same principle applies outside Google. One governed record does not mean one identical payload.

What Shopify's UCP-over-MCP catalogue shows

Shopify's Storefront Catalog MCP demonstrates a third pattern. Agent software can discover and call catalogue tools over MCP, while the returned commerce data follows UCP-aligned catalogue semantics.

The important point is what this does not mean.

MCP is not a product-master schema. The July 2026 MCP specification release is concerned with protocol mechanics such as transport, routing, tools, resources and authorisation. Shopify can use that protocol to expose product, variant, price and availability data, but the protocol does not become the authority for those facts.

In business terms:

• the product and variant data still need owners;
• the offer state still needs a current seller source;
• UCP can define commerce-domain structures and capabilities;
• MCP can provide a way for software to discover and invoke the tools that expose them.

If the question is how a product identity can help software discover an action and why discovery is not permission, that belongs to Product as an API Endpoint. This page owns the product and offer data that shopping agents consume.

Feed, UCP and MCP are three different jobs

The names are close enough to be confusing, but the jobs are not interchangeable.

This is why a business can support several agentic-commerce routes without creating several masters. The destination contracts can change while the governed facts remain stable.

It is also why one product feed should not be assumed to work unchanged everywhere. Even where two destinations use similar words, the field can mean something different or have different validation rules. Where product data stops meaning the same thing is the useful check before a mapping is treated as reusable.

Where evidence, provenance, conflicts and freshness should live

AI shopping creates pressure for compact, machine-readable answers. That makes it more important, not less, to preserve what sits behind the answer.

For consequential claims, we would keep a link from the governed fact to its evidence and provenance. The W3C PROV model is one established way to describe provenance relationships between entities, activities and agents. It is evidence that provenance can be represented. It is not an AI-shopping requirement and it does not mean every agent protocol requires a generic confidence_score or provenance field.

The reviewed OpenAI, Google and Shopify materials do not support a general claim that adding a DPP field, provenance field or confidence score will improve AI-shopping ranking or visibility. That claim is not supported by the accepted evidence.

What provenance does give you is a better internal answer to questions such as:

• Where did this value come from?
• Which product or variant does the evidence cover?
• When was it verified?
• Has a supplier or method changed?
• Is there a conflict between two credible sources?
• Which destination received which version?

Those questions belong upstream of the agent surface. If two systems use the same field name for different meanings, do not let a feed transform hide the problem. Preserve the conflict, resolve it against the right authority and then publish the destination representation.

For machine-verifiable claims, the separate question is what the credential or evidence actually proves. A signed or verifiable record can improve integrity and traceability without making an unsupported claim true.

A practical governed-data architecture for AI destinations

A useful operating model has five layers.

1. Authority. Maintain the strongest reusable product and variant facts in the systems that genuinely own them.

2. Evidence. Attach source, scope, method, date and supporting evidence to consequential claims where the business needs to defend them.

3. Offer state. Keep price, availability, seller and other fast-changing commercial state in the commerce systems that can maintain it at the required cadence.

4. Destination package. Map the reusable facts and offer state into the schema, profile or catalogue representation required by the AI destination. Keep destination-only eligibility and validation fields outside the canonical source fact.

5. Delivery and status. Send the package through the destination's supported feed, API or tool route. Retain schema version, validation outcome, freshness and destination identifiers so failures can be diagnosed without overwriting source truth.

The same pattern appears across other product-data destinations. Product Data Across EU Systems applies it to regulatory records. Product data syndication applies it to retailer and marketplace channels.

What is NOW and what is still EMERGING

The useful conclusion is deliberately less dramatic than the agentic-commerce headlines. Businesses can support current AI-shopping destinations now. They should do it by governing reusable facts and building explicit destination representations, not by assuming a universal agent schema has arrived.

What should a business govern first?

Start with the facts that are hard to correct once they spread and useful across more than one destination:

• stable product and variant identifiers;
• brand and manufacturer or seller identity where applicable;
• the product-to-variant relationship;
• core descriptive facts that have a clear meaning and owner;
• evidence for claims that carry legal, safety or commercial consequence;
• the link between the governed product and the systems that own current offer state.

Then govern the transformation itself: destination field, source fact, rule, target schema version, freshness expectation and validation result.

That is the point where agentic commerce becomes an activation problem rather than another data-clean-up project. One maintained authority layer can serve new destinations without pretending every destination wants the same record.

What would change this page?

Re-check this answer if:

• OpenAI changes the supported Stable product-feed model or combines discovery, ads and checkout requirements;
• Google materially changes UCP availability, geography or Merchant Center integration requirements;
• Shopify materially changes its Storefront Catalog MCP or UCP profile;
• the MCP specification changes the relevant tool, transport or authorisation model;
• credible primary evidence establishes a cross-platform product-data requirement that is not destination-specific.

Sources

• OpenAI Developers, Agentic Commerce product feed specification
• OpenAI, Merchant Feed Terms of Service
• Google for Developers, About UCP integration in Merchant Center
• Google for Developers, Prepare your Merchant Center account for UCP
• Shopify Developers, Storefront Catalog MCP
• Shopify, Universal Commerce Protocol
• Model Context Protocol project, 28 July 2026 specification release
• W3C, PROV Primer
  Standards body