Last week an agent I'd never seen ran 500+ searches against a public catalog API I operate. It never loaded a page. It never fired a single frontend event. It queried structure, filtered, shortlisted, and left.
That's the whole of "zero-click commerce", stripped of the conference-keynote framing. And I think most of the discourse around it is aimed at the wrong problem.
The framing that produces bad engineering
The usual take is we're losing traffic. That leads teams toward recovering clicks — which, if the buyer is an agent, is not a recoverable thing. Agents don't click. They read.
The precise statement is narrower and more actionable:
When nobody loads the page, the only part of your store still in the conversation is the part a machine can retrieve.
Your CSS, your product photography, your carefully A/B-tested CTA — none of it participates in the decision. What participates is whatever your server returns to a GET. If that's a 200 KB HTML document built for human eyes, the agent scrapes it badly or skips you.
What the compression actually looks like
The classic funnel: search → browse several stores → compare pages → read reviews → decide → checkout.
The agent funnel is roughly three steps: ask → shortlist → act.
The middle — the part we spent fifteen years optimizing with layout and merchandising — is now done by a program, and that program does it by parsing rather than looking. Everything downstream of "shortlist" only matters if you made the shortlist.
Three failure modes worth naming
1. Absence is silent. This is the one that gets engineers' attention when I put it this way: a store that can't be read isn't ranked lower. It's not in the candidate set. There's no impression, no bounce, no analytics row. You cannot instrument the requests you never received. It's the difference between losing a race and never entering one.
2. Unverifiable data gets discounted. An agent that can't check a claim against an authoritative source treats it as weak. Scraped copies, stale feeds, third-party mirrors — all fail that test. Serving your own data from your own domain isn't just architecture, it's a trust position.
3. Snapshots rot. Price and stock are boundary truths. A nightly feed is wrong for up to 24 hours, and "wrong about price" is worse for an agent than "unknown", because it burns trust on the next lookup.
What a readable catalog actually returns
Concretely — this is a summary projection from the catalog layer I work on, one product:
{
"id": 3412,
"sku": "TS-BLK-M",
"name": "Merino base layer, black",
"url": "https://example.com/product/merino-base-layer/",
"price": { "current": 79.0, "display": "€79.00", "currency": "EUR" },
"stock": { "in_stock": true, "confidence": "variant_dependent",
"agent_note": "Select a variation before reporting numeric stock" },
"updated_at": "2026-08-04T09:12:08+00:00"
}
Roughly 300 bytes. The full record for the same product is ~4.4 KB, and the HTML page is orders of magnitude more. An agent screening 200 candidates wants the 300-byte version, then fetches the full record for the three it shortlisted.
Two design points in there that matter more than they look:
-
confidence: variant_dependent— the system declaring what it doesn't know. Counterintuitively this increases trust. A stack that confidently returns a wrong number is worse than one that says "ask me more precisely." -
updated_atper record — lets a caller do?modified_after=and pull deltas instead of re-reading the catalog. Pagination and delta sync are not hostile to agents; monolithic dumps are. A 10k-SKU catalog served as one blob is ~70 MB and blows any context window. That's a bad answer regardless of who's asking.
The boring checklist
Nothing here needs a protocol war to resolve first:
- A discovery document at a well-known path, so a caller can learn what your store exposes without guessing.
- Bounded, read-only search answering from your live database, not a snapshot. Rate-limited. No admin credentials anywhere near it.
- A lean projection for screening plus a full record for verification. Don't make callers download everything to filter.
- Honest price and stock blocks, including the "it depends" cases.
- Fill the data gaps. Completeness is now a ranking input for a reader that can't infer anything from your product photo.
Where I'd push back on my own side
Vendor numbers on this topic are mostly marketing — mine included, so weigh direction over magnitude. Surveys report high AI usage somewhere in the shopping journey while purchases completed on an AI referral remain a small slice. Gartner's multi-trillion B2B projection for 2028 is a scenario, not a measurement.
And the honest limit on the engineering work: being readable makes you eligible, not chosen. Agents still weigh price, availability, delivery and reputation. A legible catalog full of weak offers loses to a legible catalog full of strong ones. What readability buys is the right to compete on the merits — which, when the shopper never visits your page, is the only competition left.
I build KaliCart Bridge, an open-source WooCommerce plugin for this layer, and a federated catalog on top of it. Longer version of this post, with the telemetry breakdown, is on the blog.
Curious what other people are seeing: if you operate a public API that agents hit, what does your traffic look like? I've mostly got registry probes plus the occasional real consumer.
Top comments (0)