Eight Stores Accept an Agent Checkout. Their Own llms.txt Never Says So.

There is a tidy assumption underneath most of the advice being written about AI and ecommerce right now: that a store’s llms.txt tells you how prepared it is for agents. Audits are built on it. Adoption percentages are quoted from it. We quoted one ourselves.

It does not hold. We requested both /llms.txt and /.well-known/ucp on the same 58 hosts, and the two results are only loosely related. Eight stores accept a full agent checkout while publishing an llms.txt that says nothing about it — and four of those publish no llms.txt at all.

That is roughly a quarter of every agent-transactable store in the sample, invisible to the audit method the whole category is using.

The eight

Each row was confirmed twice: the discovery document returns HTTP 200 with a versioned merchant profile and registered payment handlers, and the llms.txt column is what that host actually served, by content-type rather than by status code.

Only the last of the eight mentions the protocol anywhere in its file. The other seven describe the brand to a reader, or describe nothing at all, while the store answers commerce requests on a path the file never names.

The counter-intuitive part

Notice what three of those rows have in common. Burrow, Liquid I.V. and Outdoor Voices did the thing every guide recommends: they wrote a considered, hand-authored llms.txt. Burrow serves genuine text/markdown, opens with a real description of what it sells, and lists thirteen curated category URLs. It is, judged as a document, better than the generated alternative.

And two of the three never mention the endpoints their own store answers on.

We cannot tell from the outside whether a hand-written file displaced a generated one or whether the generated one was never switched on, and it would be wrong to assert either. The observable fact is narrower and still worth acting on: on these hosts, the file a careful team authored is what sits at that path, and it omits the store’s most consequential machine-facing capability. Effort spent on the document did not carry over to the protocol.

So the practical note for anyone about to write their own: check what is at that path today before you replace it, and read it. If it names endpoints, carry those forward into whatever you write.

A trap for anyone counting adoption

Harry’s is the row to study if you are building an audit. Requesting /llms.txt returns HTTP 200 — and 2.2 megabytes of text/html. It is the site’s catch-all page, not a file. Any survey that counts status codes records Harry’s as an adopter.

curl -sLI https://harrys.com/llms.txt | grep -i content-type
# content-type: text/html; charset=utf-8   <- not an llms.txt

curl -sL -o /dev/null -w '%{size_download}\n' https://harrys.com/llms.txt
# 2226473

Two cheap guards catch it: reject anything whose content-type is HTML, and treat a file larger than a few hundred kilobytes as suspect. A soft 200 is the single most common way a crawler-facing measurement goes quietly wrong, and it inflates every adoption figure it touches.

What an agent can pay with is a merchant setting

One more thing fell out of the same data, and it is the finding with the clearest operational consequence.

Thirty of the thirty-one discovery documents register three payment handlers. One registers two:

curl -s https://feals.com/.well-known/ucp | jq '.ucp.payment_handlers | keys'
# ["com.google.pay", "dev.shopify.card"]

curl -s https://allbirds.com/.well-known/ucp | jq '.ucp.payment_handlers | keys'
# ["com.google.pay", "dev.shopify.card", "dev.shopify.shop_pay"]

The handler list is not a platform constant. It reflects that individual store’s configuration, and the Google Pay entry carries a per-merchant identifier rather than a shared one.

Which means the payment methods a team enabled in an admin screen — a decision made about human shoppers, probably some time ago — now also determines what an autonomous buyer can pay with. Nobody was told that. It is the clearest example we have found of an existing setting silently acquiring a second meaning.

What we are claiming, and what we are not

Claimed: on 14 August 2026, these eight hosts returned a valid UCP discovery document, and their llms.txt was as described. Both requests, same host, same session, content-type recorded.

Not claimed: that a hand-written file causes the omission, that these brands are unaware (we have not asked them), or that any of this reflects ecommerce generally. The sample is 58 well-known US DTC brands chosen for recognisability, and it skews to one platform. We did not attempt a purchase on anyone’s store.

Also worth stating plainly, because it cuts against us: this partly corrects our own earlier framing. We described the generated llms.txt as where the platform announces agent commerce. That is true of the file, and it is a poor proxy for the capability — 8 of 31 stores have the capability without the announcement. A metric that misses a quarter of its subject is not a metric to build advice on.

Per-brand data is in the DTC AI crawler index, free to cite with attribution. The wider survey is in agentic checkout is already live on half of DTC. To see what an agent can read on your own store, the readiness checker now reports a live discovery document when it finds one.