Your theme is not a product API
If you have built anything that reads product data off a live storefront, you already know the failure mode. You scrape the product page, pull the title and price out of the HTML, and it works until the merchant renames a section, swaps a theme, or A/B tests the layout. Then the parser returns garbage without complaining. In mid-2026 Shopify shipped a Catalog API aimed at AI agents for exactly this reason — structured catalog queries instead of reverse-engineering a theme. The useful part of that release is not the tooling. It is the modeling lesson underneath it.
Scraping reverse-engineers a presentation layer
A product page is built for a person with a browser. It mixes marketing copy, layout chrome, reviews widgets, and the actual sellable facts — price, variants, availability, options — into one HTML response. When you scrape that page you are treating the presentation as an accidental API. It will break on every theme change, return stale prices, and have no reliable notion of variants, shipping eligibility, or a checkout link.
That is expensive in the wrong place. You end up maintaining parsers across stores that all render differently, instead of spending the time on the product behavior that is actually specific to the business. We have seen the same shape outside agents: a florist's operations pipeline does not want Shopify's storefront HTML, it wants a structured order webhook. A clinician-facing product site does not want checkout reinvented, it wants the content model around the SKU. In both cases the durable interface is the structured record, not the page that happens to display it.
So the first decision is simple: if a machine needs product truth, do not point it at the theme.
What the Catalog API actually changes
Shopify's Global Catalog, exposed as an MCP server, gives agents three tools that form a short funnel: search for candidates (text, image, or both), look up known IDs or product URLs into live catalog records, and get full product detail with variants and checkout links. There is also a storefront-scoped catalog when discovery should stay inside one merchant.
None of that removes the need for a real storefront. People still browse. What it removes is the excuse that the only way for an agent — or any integration — to learn what you sell is to parse your markup. Live price, availability, and a checkout path come from the catalog, not from whatever was in the HTML the last time a crawler ran.
For a single-store build the Storefront API already covered a lot of this. The shift worth noticing is that platform catalogs are now being treated as first-class surfaces for machines, with the same expectations of structure and freshness you would demand from your own admin API.
The modeling work happens before any agent shows up
A catalog query only returns what you put in the catalog. If material, sizing, clinical claims, or bundle rules live as prose in the description, an agent will guess from prose. If they live as options, variants, and metafields, the same agent can filter and cite them without inventing structure.
That is the same discipline we already apply when a CMS owns marketing pages and Shopify owns the sellable object. On Provale Cup, the hard content — clinician resources, how the cup meters a sip, regulatory-sensitive wording — sits in Sanity as editor-owned documents. Shopify holds the product and checkout. The seam works because each system stores what it is good at, in a shape that system can enforce.
Agent-ready is the same seam, pushed one step further. Specs that buyers (or agents) will filter on belong in structured fields. Narrative belongs in rich text. Titles are labels, not databases. If you bury facts in the description to make the theme look denser, you are training every future integration to scrape.
URL lookup beats a cached guess
Agents constantly handle product URLs: a pasted link, a comparison list, a citation from another page. Looking those URLs up against the live catalog is the difference between "this probably costs what the HTML said last week" and "this variant is available, ships to the buyer's country, and here is a checkout link."
We already treat webhook payloads the same way in operations work. An order ID from Shopify is a rumor until you have upserted it idempotently and reconciled against a pull. Catalog lookup is that instinct applied to discovery: resolve the reference to the current record before you act on it.
If your own tools still scrape product pages for price or stock, that is a smell. Prefer the Admin or Storefront APIs for first-party jobs, and prefer a platform catalog when the consumer is an agent you do not control. Scraping remains a last resort for surfaces that truly have no API — not a default because the page was convenient.
What we check on a commerce engagement now
During scoping we ask where product truth lives. If the answer is "mostly in the theme," we fix that before anyone talks about chatbots or shopping agents. Options and variants modeled cleanly. Metafields for the attributes people actually filter on. Descriptions for reading, not for smuggling data. One canonical product record, with the storefront as a rendering of it.
Then we draw the same line we draw for checkout: the platform owns money and the canonical sellable object; we own presentation and the operational systems around it. Adding an agent surface does not change that line. It makes a fuzzy catalog more expensive, because the agent will amplify whatever ambiguity you left in the data.
The Catalog API is a useful forcing function, not a product strategy. If your catalog is already structured for humans and integrations, agents can query it. If it is not, no MCP wrapper will save you — you will just get fluent answers built on scraped guesses.