Locale Is Not Currency: A Small AI Shopping Bug Exposed a Bigger Commerce Contract

I asked Grok to use WebAZ to find folding bicycles for delivery to Singapore.

The useful part worked: the AI called a read-only shopping tool, found real listings, and rendered product cards with product images, seller information, delivery estimates, return terms, and prices denominated in USDC.

Then the interface exposed a small but important problem.

The conversation was in Chinese. The shipping destination was Singapore. The underlying listing price was in USDC. Grok's prose converted the price to SGD, but the first product card showed an approximate CNY value. After more explicit Singapore context, a later card showed SGD.

No purchase was made, and the USDC listing price did not change. This was a presentation inconsistency, not a settlement error. But it revealed a larger design problem for AI commerce:

Language, location, price currency, and display currency are four different facts.

If an agent or host silently collapses them into one locale guess, the result can look polished while saying two different things about the same offer.

The Four Fields That Should Never Be Conflated

An AI shopping request can contain at least four independent dimensions:

1. Interface language: the language used to explain the result.
2. Shipping destination: the place used to evaluate delivery availability, ETA, taxes, and logistics.
3. Listing or settlement currency: the currency in which the seller states the price or the transaction is committed.
4. Reference display currency: an optional conversion shown only to help the buyer understand the amount.

A Chinese-speaking buyer in Singapore may want Chinese explanations, delivery to Singapore, a USDC-denominated offer, and an SGD reference price. None of those choices implies the others.

This matters even before checkout. A buyer comparing two cards may treat the largest number as the price that will be charged. If one surface shows CNY and the narrative shows SGD, the system has created avoidable ambiguity at the point where the user is deciding whether to continue.

What the Tool Contract Should Say

The display currency should be explicit input, not an undocumented inference:

{
  "query": "folding bicycle",
  "ship_to": "SG",
  "display_currency": "SGD",
  "language": "zh-CN",
  "limit": 6
}

The result should preserve the authoritative amount separately from any reference conversion:

{
  "price": {
    "amount": "554.14",
    "currency": "USDC"
  },
  "reference_price": {
    "amount": "700.93",
    "currency": "SGD",
    "is_estimate": true,
    "rate_observed_at": "2026-09-10T13:00:00Z"
  },
  "shipping": {
    "destination": "SG",
    "delivered_total": null
  },
  "warnings": [
    "Shipping cost is not included",
    "Reference conversion is not the settlement amount"
  ]
}

Three properties are doing most of the safety work here:

• The original price remains intact.
• The conversion is visibly marked as an estimate with a timestamp.
• An unknown delivered total stays null instead of being guessed.

The host may still decide how to render the card, but the data contract gives it fewer opportunities to invent meaning.

Search, Presentation, and Commitment Are Different States

The experiment also reinforced a boundary we use throughout WebAZ:

• Search discovers candidate offers.
• Presentation helps a human compare known facts and visible unknowns.
• Commitment must bind the exact seller, product or variant, amount, currency, terms, and approval.

A reference conversion belongs to presentation. It must never silently replace the amount being approved or paid.

This distinction becomes more important as AI clients move from answering questions to taking actions. A fluent answer is not a transaction receipt. A product card is not proof of inventory reservation. A starting price is not necessarily the price of the pictured variant. And a converted number is not the settlement currency unless the transaction contract says so.

Try the Read-Only WebAZ Experiment

WebAZ exposes a dedicated public Grok connector for reviewed-product search:

https://webaz.xyz/mcp/grok-search-v1

It requires no WebAZ account and exposes exactly one read-only tool: webaz_search.

One useful test prompt is:

Use WebAZ to find folding bicycles for delivery to Singapore.
Show the original listed price and an SGD reference price.
Mark missing shipping costs, taxes, or unclear variants.
Do not place an order or pay.

When reviewing the result, ask four questions:

1. Does the card preserve the original currency?
2. Does the reference conversion name its currency and remain clearly approximate?
3. Does changing the conversation language alter the displayed money unit?
4. Are missing freight, tax, inventory, or variant facts shown as unknown?

WebAZ's public-search surface is intentionally narrow. It is designed to make the first experiment easy to inspect without exposing account tools or payment actions. Compatible hosts can render product cards; structured and text results remain the fallback, and the host controls the final presentation.

Why Publish the Imperfect Test?

Because agent commerce will not become trustworthy through perfect screenshots alone.

It will become trustworthy when builders publish the exact request, distinguish observed behavior from intended behavior, preserve authoritative values, and turn mismatches into explicit contracts and regression tests.

The currency selector is now a concrete product-design item for WebAZ rather than a vague localization concern. The deeper lesson applies to every shopping agent: never let locale inference decide what the user thinks they are paying.

You can inspect the current WebAZ Remote MCP guide or browse the public product surface. If you run the experiment in another AI client, the most useful report is not simply "worked" or "failed." Record the client, prompt, shipping destination, original currency, displayed currency, and which facts remained unknown.

That is the evidence needed to make AI commerce less magical and more dependable.

Comments

[Raknaos]

The four-fields framing is right, and it generalizes beyond commerce: language, location, currency, and settlement currency drift apart the moment an agent renders on behalf of a model instead of a renderer. Our browser bridge had the same class of bug with timezones in display vs storage.

One thing I'd add: the fix is not just "never conflate" but "render from the same structured record the model reads". The moment prose and cards get their numbers through different paths, you'll keep shipping these mismatches.