One request, five different questions
Consider a realistic instruction to a shopping agent:
“Buy an office printer for no more than €300 and have it delivered by Friday.”
The sentence sounds like a single task. Operationally, it contains at least five questions:
- Which printers match the buyer’s functional requirements?
- Which exact model or variation is purchasable?
- Is that exact offer in stock now?
- Can the merchant ship it to this buyer’s address?
- Can the merchant support the requested delivery date at the final price?
Only the first question is pure catalog discovery. The others progressively depend on more specific, more volatile and more private context. Treating all five as one search result is how an agent turns a good product match into a false commercial promise.
A catalog match is a candidate, not a promise
An agent-readable catalog is excellent at narrowing a large inventory. It can identify printers below a catalog price, filter incompatible products, compare features and return compact candidate records. That is the right place to be fast and economical.
But a summary record should not silently claim more than it knows. “In stock” may describe the parent product while the required colour, capacity or bundle is unavailable. A price may be the lowest value in a variation range. Shipping may be available to one country and impossible in another.
The correct output of discovery is therefore not “buy this.” It is “this candidate satisfies the catalog constraints; now verify the exact offer.” That distinction is central to the catalog-before-checkout architecture.
The exact variant changes the commercial truth
WooCommerce variable products can assign price, stock, image, weight, dimensions and shipping class to individual variations. Its own variable-product documentation makes the scope explicit: each variation can carry its own offer and inventory data.
For an agent, this creates a strict rule: do not quote a parent record as if it were the final purchasable item when selection is still required.
| Catalog signal | What it proves | What it does not prove |
|---|---|---|
| Parent product exists | The product family is published | The buyer’s required variation is available |
| Price range €249–€319 | Published variations span that range | The suitable variation is below €300 |
| Parent marked in stock | At least one sellable state may exist | The selected option is in stock |
| Attributes list Wi-Fi and duplex | The product carries those facts | Every bundle or variation includes them |
The agent should resolve the exact variation ID, option values, current price and stock before it presents the item as purchase-ready. If that information is missing, the honest status is selection_required or verification_required, not a guessed answer.
Stock is a claim with a scope and a timestamp
Availability is not merely true or false. It belongs to a particular product or variation, at a particular merchant, at a particular moment. Backorders, low-stock thresholds and external inventory systems add further semantics.
A federated index or feed may be suitable for discovery but still be older than the merchant’s live inventory. That does not make the index useless. It means the agent should treat it as a candidate source and recheck the selected record at the merchant-controlled endpoint before commitment.
Useful machine-readable evidence includes:
- the product or variation identifier to which availability applies;
- an explicit stock status rather than prose;
- the time at which the source produced or refreshed the claim;
- a canonical URL or detail call for final verification;
- a clear indication when the source cannot guarantee exact quantity.
Shipping does not exist without a destination
A product page can say “free shipping” and still be unable to answer the buyer’s request. WooCommerce shipping zones are geographic rules. According to the official shipping-zone documentation, the methods shown to a customer depend on the address and the first matching zone; a zone with no methods means shipping is unavailable.
This has two consequences for an agent:
- It should not claim that an item can be shipped before it knows enough destination information to match the relevant rule.
- It should not ask for the buyer’s full address during broad catalog search. Personal data becomes necessary only after a shortlist exists and the user has authorized the next step.
A public catalog can expose broad merchant facts — countries served, pickup availability, policy notes — without pretending to calculate a destination-specific quote. The exact method and rate belong later in the flow.
“Arrives by Friday” is not a product attribute
A delivery date is a computed claim. It may depend on:
- the selected variation’s physical availability;
- the buyer’s postcode and the matched shipping zone;
- the chosen carrier and service level;
- warehouse handling time and order cutoff;
- weekends, holidays and exceptional delays;
- the time at which the quote is requested.
If WooCommerce or a connected shipping service does not expose those inputs and a resulting estimate, the agent cannot manufacture certainty. It can report that the product is in stock and that an eligible method exists. It cannot convert those facts into a guaranteed Friday delivery by intuition.
This is a healthy boundary, not a failure of agentic commerce. A disciplined agent knows when the evidence supports a recommendation and when the merchant must calculate the next fact.
The final price is also destination-specific
The €300 constraint looks simple until the question becomes: €300 for what?
- Catalog price before shipping?
- Price for the selected variation?
- Price including tax for the buyer’s location?
- Total after the chosen delivery method?
- Total after a valid coupon or minimum-order rule?
An agent may use catalog price to build a shortlist. It should label that scope. The checkout calculation becomes authoritative once destination, tax context, shipping method and any valid promotion are known.
A useful response exposes what is known and what comes next
An agent interface should not merely return fields. It should communicate the decision boundary.
| State | Evidence available | Correct next action |
|---|---|---|
candidate | Product matches broad catalog constraints | Rank against other summaries |
selection_required | Parent product matches, but options remain unresolved | Choose and retrieve the exact variation |
verified_offer | Exact variation, current price and stock are confirmed | Apply destination constraints |
shipping_quote_required | Destination-specific method or rate is unknown | Request an authorized WooCommerce calculation |
checkout_ready | Final combination and current total are accepted | Ask for user confirmation or hand off |
These names are illustrative, not a claim about a universal protocol. The important contract is the separation of evidence. An interface should never hide that a supposedly final answer still depends on buyer input or merchant calculation.
What the merchant should prepare
- Model real purchasable combinations as WooCommerce variations.
- Maintain price and stock at the correct product or variation scope.
- Configure shipping zones from the most specific geographic rule to the broadest.
- Remove misleading global shipping claims that have destination exceptions.
- Document processing times, cutoff rules and the difference between estimates and guarantees.
- Keep checkout as the authority for destination-specific taxes, shipping and totals.
- Give agents a compact discovery surface and a separate way to verify the finalist.
The catalog foundation still matters. Our WooCommerce catalog optimization guide covers identity, brand, images, attributes, variants, offer data and freshness before this later qualification step begins.
Where KaliCart Bridge fits
KaliCart Bridge gives compatible shopping agents a read-only path to discover the store, search compact product summaries and verify a selected product against current WooCommerce data. It can indicate that variant selection is still required and direct the buyer to the merchant’s canonical purchase path.
Bridge does not turn incomplete public data into a delivery guarantee, does not replace destination-aware WooCommerce calculations and does not take payment authority away from the merchant. The interface is valuable precisely because it can expose both the commercial facts and their limits.
OpenAI’s current shopping guidance similarly advises buyers to confirm final price, shipping costs, availability and relevant policies on the retailer’s site. Product discovery can be broad; commitment requires fresh merchant evidence.