Do AI shopping agents see your Shopify sale price?

On 28 September 2026 Shopify switched on WebMCP tools for checkout. Browser-based agents could already search a Shopify catalogue and build a cart through structured tools; they can now read the checkout, change the address or delivery option, and place the order once the buyer confirms. TechCrunch framed it as Shopify going the opposite way from Amazon, which has been blocking agents rather than handing them tools.

Most of the commentary is about who wins the agent war. The question a store owner with a sale running should ask is smaller and more immediate: when an agent asks your store what a product costs, which number does it get back? Because for a lot of Shopify sales the honest answer is “the full price”, and nothing about that changes until you know why.

What the storefront tools actually return

Shopify’s WebMCP documentation lists the storefront tools an agent can call in the buyer’s browser: search the catalogue, browse collections, fetch a product, show a variant. They are not a new pricing engine. They read the same product data the theme reads, and the Ajax product endpoint that themes have used for a decade shows what that data looks like. Open /products/your-handle.js on any Shopify store and you get a JSON document with a price and a compare_at_price for every variant, and nothing else about money.

Discounts live somewhere else. In the Storefront cart object a discount shows up as an allocation on a cart line, with the discounted amount and a title, and the cart cost reflects it. That is where automatic discounts are calculated: when a line is in a cart, not when a product is looked at. The product knows its stored price; the cart knows what the buyer will pay.

So there are two prices, and an agent working through the shopping journey meets them at different moments. At discovery, when it is comparing your store with three others, it has the product price. At cart, once it has committed to your store, it has the discounted total.

Three ways to run a sale, three different answers

The mechanism you used to build the sale decides what an agent reads at the discovery stage. This is the same distinction we covered in automatic discounts versus compare-at rewrites, seen from a new reader.

A human on your product page does not notice the gap, because your theme shows a badge saying “-20% at checkout” and they trust it. An agent reading structured fields has no badge. It has a number. If that number is the regular price, your Black Friday offer is invisible at the exact moment a shopper asked their assistant to find the best deal.

A word on certainty: WebMCP is weeks old and nobody, Shopify included, knows yet how much traffic agents will send or how they will rank stores. What is not speculative is the data model. Automatic discounts have always been cart-time, and the new tools do not change that.

Discount codes are the odd one out

Checkout WebMCP lets an agent update discount codes on a checkout, so a code the buyer already has can be applied without typing. But an agent does not go looking for codes on coupon sites, and it does not read the announcement bar where you pasted “use SAVE20”. A code-only sale is the least visible option in this world, for the same reason it was the least visible before: the price only moves after an extra step.

Choosing per campaign, not per store

The tempting conclusion is “rewrite prices for everything”, and it is the wrong one. Rewriting stored prices is the mode with the asymmetric failure: if the revert does not run, wrong prices stay live on your storefront and in every feed that reads them. It also does not combine cleanly with other automatic discounts, and Markets fixed price lists do not follow it. A cart-time discount that fails leaves the price correct and the saving missing, which is annoying and harmless.

SafeSale runs both. A sale is created in exactly one mode, and the default is the automatic discount built on Shopify Functions, because its failure mode is the safe one. The opt-in mode rewrites price and compareAtPrice so every reader, human or not, sees the crossed-out original and the sale price in the product data itself. Before a single variant is written, SafeSale takes an immutable snapshot of the original values, and the revert at endsAt restores from that snapshot, not from whatever the live price happens to be.

A reasonable split for a store that cares about agent visibility:

• Site-wide or category-wide seasonal sales, where you want the discounted number in every comparison: price rewrite, with the hard cap and confirmation threshold on.
• Short flash sales, loyalty-only offers, and anything that overlaps another promotion: automatic discount, and accept that the product price stays regular.
• The same products in both at once: never. Preview will show you the double discount before it goes live, and the answer is to pick one.

Keeping the numbers coherent

Once the sale price is in the product data, everything downstream inherits it: the theme, the Ajax JSON, the storefront tools, and the product feed Google Merchant Center pulls. That is a strength and a responsibility. If the price rewrite happens at 00:00 and the revert at 23:59 six days later, every one of those consumers sees a consistent story. If the revert fails silently, every one of them keeps the sale price until someone notices; the Merchant Center post covers what a stale price does to a feed. SafeSale’s drift detection exists for this: it compares the live price against what it wrote and flags the variant when the two disagree.

Two habits worth adopting whichever mode you use. First, do not let compare_at_price lie. Structured readers treat it as “the price this was before”, and a compare-at that has been sitting inflated for a year is exactly the kind of thing a comparison tool will surface rather than reward. Second, make the badge match the mechanism. If the sale is cart-time, the badge should say so, because a shopper who saw “-20%” in their assistant’s summary and a different figure on the product page is going to trust neither.

A five-minute check

1. Open /products/<handle>.js for a product currently on sale and read price and compare_at_price on one variant.
2. If price is the sale price, agents and feeds see the sale. Confirm compare_at_price is the genuine previous price.
3. If price is the regular price, the sale is cart-time. Decide whether that is what you want for this campaign.
4. Add the product to a cart and check the cart total moves. If it does not, the discount is not applying to that variant at all, which is a different problem.

Next step

SafeSale is not yet publicly listed on the Shopify App Store. The landing page demo shows the same sale previewed in both modes, the per-variant snapshot taken before a price rewrite, and the exact restore at the end. See how SafeSale runs a sale agents can read.