When merchants hear that AI assistants may become a new shopping interface, the first reaction is often: do we need to build another storefront for agents?
Usually, no.
The more immediate problem is that the existing store rarely has one dependable product record that both a person and an agent can interpret in the same way.
A human shopper can open several tabs, read the product description, inspect a variant selector, find the shipping FAQ, and ask support what a vague sentence means. An agent has to turn all of that into a structured decision. If the facts conflict or a detail is missing, the model may omit the problem or fill the gap with a plausible answer.
That is not mainly a chatbot problem. It is a product-data and action-boundary problem.
One commercial truth, two interfaces
An AI-ready store does not need two independently maintained catalogs. It needs one commercial source of truth that can be rendered for humans and exposed to agents.
At minimum, that record should make these categories explicit:
- Identity: product, exact variant, SKU or merchant product identifier.
- Current state: whether the item is active and in stock now.
- Commercial terms: price, currency, sale region, and seller or payee reference.
- Fulfillment: handling time and delivery estimate, kept separate.
- Returns: whether returns are accepted, the time window, and important conditions.
- Evidence: when the value was checked and which system supplied it.
- Unknowns: details the merchant has not declared and the agent must not invent.
The last category is easy to underestimate. A record that says unknown is often safer and more useful than a polished paragraph that lets a model infer the wrong compatibility, delivery date, warranty, or included accessory.
Here is an illustrative audit shape, not a claim about a universal commerce standard:
{
"item_id": "merchant-item-123",
"variant": "black-128gb",
"availability": "in_stock",
"price": {
"amount": 49.00,
"currency": "SGD"
},
"sale_regions": ["SG"],
"handling_time": "2 business days",
"delivery_estimate": "3-5 business days",
"returns": {
"accepted": true,
"window_days": 7
},
"unknowns": [
"official warranty coverage"
],
"checked_at": "2026-08-22T07:00:00Z"
}
The exact schema will differ by platform. The important design property is that the agent does not have to reverse-engineer a transaction from marketing prose.
Discovery is not checkout
Making a product readable to an agent does not mean the agent should immediately be able to buy it.
These are different capability levels:
- Discover: find products that match a request.
- Compare: explain differences, missing information, and risk flags.
- Prepare: build a quote, cart, or order request without creating an obligation.
- Commit: create the order or authorize payment through the required human and policy controls.
- Settle and recover: record what happened, reconcile unknown outcomes, and define who acts next.
A store can become much more useful to AI at levels one and two without granting autonomous checkout. This is a practical migration path because it improves product clarity before introducing irreversible actions.
A live implementation boundary
WebAZ is currently testing this separation in public.
As checked on August 22, 2026, its public protocol document reports software version 0.1.35 and schema version 37. The broad machine catalog at:
https://webaz.xyz/.well-known/webaz-acp-feed.json
is explicitly described as an ACP-inspired discovery projection, not a strict ACP-ingestable merchant feed. It exposes product-level fields such as item identity, title, description, price, availability, seller, sale region, category, and return terms when available.
WebAZ also exposes a smaller human-reviewed shopping surface at:
https://webaz.xyz/mcp/shopping-v1
That endpoint is deliberately discovery-only. It lets an agent search reviewed, active, in-stock listings and return decision flags, but it cannot create an order or move funds.
This boundary matters more than the size of the catalog. It creates a place to test whether agents can represent products honestly before asking them to perform consequential actions.
Audit one product page
Pick one product from an existing store and ask:
- Can a buyer and an agent identify the exact sellable variant?
- Are stock and price current, or only implied by page text?
- Is the sale or delivery region explicit?
- Are handling time and delivery time separated?
- Are return terms machine-readable or buried in a generic policy page?
- Does the page distinguish merchant-declared facts from assumptions?
- Would a human page and an agent response show the same commercial terms?
- If a value changes, can both interfaces identify the newer record?
The goal is not to make the page longer. The goal is to make the same commercial truth available through a human interface and a machine interface.
Start with legibility
AI-ready commerce is often framed as an autonomous-checkout race. That skips the more basic work.
Before an agent can transact responsibly, it has to know what is being sold, by whom, under which terms, which facts are current, and which facts are missing. A separate AI storefront can hide those problems behind another interface. A shared product record exposes and improves them.
You can test the discovery-only WebAZ Agent Commerce Lab here:
Try one real shopping request, then inspect which facts are explicit and which questions still require the merchant or buyer.
Top comments (0)