A shopping agent that always returns a complete answer is not necessarily useful. In commerce, completeness can be a warning sign.
Product pages are uneven. A listing may state price, stock, return terms, handling time and a delivery estimate while omitting exact dimensions, compatibility, maximum load or included accessories. A human buyer usually notices the gap and asks a follow-up question. A language model may instead complete the pattern from similar products and present the inferred value with the same confidence as a seller-declared fact.
The difficult part of AI commerce is therefore not only retrieval. It is preserving provenance and uncertainty through the entire decision process.
Three classes of product facts
An agent-facing product record should distinguish at least three classes:
- Declared facts: values supplied by the seller or another accountable source.
- Derived facts: values calculated from declared inputs through a visible rule.
- Unknown facts: values that are absent, ambiguous, stale or unsupported.
These classes should not collapse into one polished description. A field that is absent should remain absent. A derived estimate should identify its inputs. A seller statement should not silently become a platform guarantee.
An illustrative response shape could look like this:
{
"item": "Metal Laptop Cooling Stand",
"declared": {
"price": { "amount": 18.4, "currency": "USDC" },
"availability": "in_stock",
"return_window_days": 7,
"handling_time_hours": 72,
"delivery_estimate_days": { "SG": 12, "default": 18 }
},
"decision_flags": [
"new_seller",
"no_sales_history"
],
"unknown": [
"exact_dimensions",
"weight",
"supported_laptop_size_range",
"maximum_load",
"included_parts",
"material_thickness"
],
"checked_at": "2026-08-23"
}
This is an explanatory shape rather than a claim that every commerce platform uses the same schema. The useful property is the separation itself.
Why a string like unknown is not enough
Production systems usually need more than a null value. The reason a field is unknown affects what the agent should do next.
For example:
{
"field": "maximum_load",
"state": "unknown",
"reason": "not_declared_by_seller",
"next_action": "ask_seller",
"blocks": ["compatibility_recommendation"]
}
Other reasons might include stale_value, conflicting_sources, not_applicable, or outside_sale_region. These states lead to different behavior. A stale price may require refresh. Conflicting dimensions may require evidence review. An undeclared compatibility claim should block a recommendation rather than invite a guess.
Decision flags are not verdicts
Risk indicators need the same care. A new seller or a seller with no sales history is not automatically untrustworthy. Those are decision flags: facts a buyer may want to weigh, not accusations generated by the platform.
The agent should surface the flag, explain its source and allow the buyer to choose. It should not convert a sparse history into a fabricated reputation score.
A public test surface
WebAZ currently exposes a reviewed, discovery-only shopping surface at:
https://webaz.xyz/mcp/shopping-v1
The surface exposes one search tool and cannot create orders or move funds. The WebAZ Agent Commerce Lab includes a known-versus-unknown prompt using the real reviewed laptop-stand listing described above.
The prompt asks the agent to produce two lists:
- facts the listing actually states, with values;
- facts a careful buyer would want but the listing does not state.
For the second list, the agent must say unknown and must not fill gaps with typical values for similar products.
That constraint matters because it makes the failure visible. If an agent invents a screen-size range or maximum load, the output can be compared against the public listing and rejected.
A practical evaluation checklist
When evaluating a shopping agent, test more than whether it found the product.
- Does every price include a currency and a freshness signal?
- Does availability come from the current sellable variant rather than marketing text?
- Are handling time and delivery time kept separate?
- Are return terms represented as conditions rather than a vague "easy returns" claim?
- Can the agent list important missing fields without guessing?
- Does it distinguish seller statements from platform verification?
- Are decision flags shown as evidence for human judgment rather than automated verdicts?
- Does the workflow stop before an unsupported or irreversible action?
This evaluation is useful even before a store supports agent checkout. It reveals product-data gaps that affect human buyers too.
Honest incompleteness is a capability
AI commerce is often presented as a race toward fewer questions and faster checkout. That framing rewards confident completion, even when the underlying product record is incomplete.
A safer goal is decision readiness. The agent should collect what is known, preserve where it came from, expose what remains unknown and identify the next responsible action. Sometimes that action is comparison. Sometimes it is asking the seller. Sometimes it is stopping.
You can run the known-versus-unknown test on the discovery-only WebAZ Agent Commerce Lab:
Ask it to separate seller-stated facts from missing details. The quality of the unknown list may tell you more than the recommendation.
Top comments (0)