What a buying agent reads on your store before it recommends you
Anthropic published the blueprint for shopping agents on 2 September 2026. Here is what such an agent asks a storefront for, which of those questions a small store can already answer, and the honest limit: being readable is not the same as being chosen.
On 2 September 2026 Anthropic open-sourced a blueprint for commerce agents: reference implementations of a shopping agent that a business embeds in its own storefront, and a merchant agent that works in the back office. The repository is at github.com/anthropics/commerce-agents under the Apache License 2.0 (read 3 September 2026), and the design article is the anatomy of effective commerce agents (read 3 September 2026).
That matters to anyone selling anything online, and not for the reason most posts about it will give. The interesting part is not that you could build such an agent. It is that the blueprint tells you, in public and in some detail, what a shopping agent will ask a store for — and therefore what your store has to be able to answer before an agent can put you in front of anyone.
We have watched this happen once already, from the other side. A buyer's agent read this store before they bought, fetched four URLs that did not exist, and the gaps it found were fixed the same morning. This guide is the general version of that morning.
What the agent actually asks for
The repository describes the shopping agent as one that "searches, compares, plans, fills the cart, answers order and policy questions, and remembers what a customer tells it", and says that a deployment "implements StorefrontBackend over its catalog, cart, order, and policy systems" (read 3 September 2026).
Read that as a list of questions rather than as architecture, because that is what it is:
- What do you sell, and what does it cost? Catalog and prices, in a form something can read without guessing.
- What are the terms? Policies — returns, refunds, licence terms, delivery.
- What happened to my order? Order state, for a customer who already bought.
- Can I put this in a basket? Cart operations.
- How do I pay? And here the blueprint is emphatic, which is the single most useful thing in it.
The part everybody will get wrong: the agent does not pay
From the repository, verbatim (read 3 September 2026):
"Nothing places an order, charges a card, or changes a live listing:
checkoutrenders the cart for the host to complete, and every merchant write is staged until a person approves it."
And from the design article (read 3 September 2026):
"On the consumer side this is structural: the checkout tool renders the cart with a button to place the order, and the backend interface the agent calls has no charge method at all."
The backend interface has no charge method at all. Not a policy, not a prompt instruction — an absence in the contract. An agent cannot spend your customer's money because there is no function to call.
If you are worried about agents buying things on their own, that is the sentence to read. If you are selling to agents, it is also the sentence that tells you where the human still is: at the checkout. Your job is to get an agent to the point where a person clicks, not past it.
Which of those questions can your store answer today?
Here is the honest audit, using this store as the worked example, because these are routes you can fetch yourself rather than claims you have to take on trust.
| The agent wants | Where it looks here |
|---|---|
| A machine-readable index of the site | /llms.txt |
| Instructions written for an agent, not a person | /agents.md |
| A card describing what this site is and where its doors are | /.well-known/agent.json |
| A typed API contract | /.well-known/openapi.json, with the endpoints under /api/ |
| Who to contact about security | /.well-known/security.txt |
| Structured facts about what is for sale | JSON-LD on the home page, as an OfferCatalog of priced Offers |
| A dataset it can cite, with a licence | /data-for-agents |
| A page for agents in general | /for-agents |
| How to connect an assistant to the software itself | /connect-your-ai |
| The terms | /legal |
None of that is exotic. It is a handful of text files and one structured block, and the reason to write them is not that an agent is magic — it is that an agent has no patience for a layout. A person will scroll past a badly organised pricing page and work out the answer. A program fetches, fails to find, and moves to the next shop.
The three failures that cost you the recommendation
From watching one real visit and from the shape of the contract, the ways a store loses here are dull and fixable.
1. The price is a picture, or a JavaScript render, or a "contact us". If your price only exists after a click on a toggle, it does not exist. We track this professionally — of the vendors in the Price Observatory, a large minority publish no figure at all, and every one of them is unquotable to anything automated. If you would like to see what that looks like from the buyer's side, quote-gated pricing is its own guide.
2. The obvious URL 404s. The agent that read this store guessed four addresses that seemed reasonable and got nothing. Guessing is what these things do. The fix is to make the reasonable guesses resolve.
3. Nothing states the terms in words. "What is your refund policy" is a question with a factual answer, and if that answer is a PDF or a paragraph inside a modal, it is not one an agent can quote to a customer who asked.
What this does not do for you, stated plainly
This is the section that makes the rest of the page worth reading.
Being readable is not being recommended. Nothing above makes a model prefer you. An agent that can read your catalogue perfectly may still put a competitor first because the competitor is cheaper, better reviewed, or simply better suited to what was asked. Readability removes a reason to be excluded. It does not create a reason to be chosen.
None of this is measurable yet in any way we would defend. We can see agent-shaped traffic in our own logs and we have exactly one purchase where an agent's visit preceded a human's decision. One is an anecdote. Anyone selling you "agent SEO" with a conversion figure attached is selling you a number they cannot have.
The blueprint is a blueprint, not a standard. It is Anthropic's reference implementation, published this week. It is not a specification anyone has agreed to, other vendors' agents will ask differently, and writing your site to one repository's contract would be a mistake. What generalises is the shape of the questions, which is why this guide lists questions rather than fields.
And nothing here is a product you can buy from us. We have not implemented StorefrontBackend or MerchantBackend, and this page would be worth less if we pretended otherwise. What we have done is make this store answerable, which cost a morning and no money.
Where to start, if you start anywhere
Write /llms.txt first: it is a text file listing what is on your site and where. Then make sure a machine can get a price and a policy without executing JavaScript. Then check your own logs for requests to addresses you do not serve — those are the guesses, and they are free advice about what to create next.
The companion to this page is staged writes: letting an AI run your back office without losing the keys, which is the same blueprint read from the inside — what changes when the agent is yours and it is touching your own data. If you want to see the software this store runs on, Deliora is $99 once and its demo is seeded and open, no signup.