Designing a storefront an AI agent can actually shop

For twenty-five years, e-commerce has optimised for a human with a screen. Hero images, urgency banners, carousels, a checkout tuned to reduce hesitation. None of it means anything to an agent shopping on someone's behalf.

If an assistant is going to buy from you, it needs three things your storefront probably does not expose: a catalogue it can query precisely, a cart it can manipulate reliably, and a checkout that is safe to hand to a machine.

Your catalogue is written for humans

Marketing copy is ambiguous by design. "Perfect for summer evenings" is good positioning and useless for filtering. An agent asked for "a waterproof jacket under £150 in medium, in stock, delivered by Friday" needs structured attributes it can filter on, not prose it must guess from.

That means real fields — material, waterproof rating, size, colour, stock count, dispatch cut-off — exposed through an API, with semantic search over descriptions as a complement rather than a substitute. Embeddings help with "something smart but not formal". They do not help with "under £150".

Tools, not pages

The practical shape is a small set of well-described tools. Define them once — an MCP server is the natural home — and any agent can drive your storefront.

server.tool("search_products", {
  description:
    "Search the catalogue. Use filters for hard constraints (price, size, " +
    "stock) and query for descriptive intent. Returns at most 20 items.",
  input: z.object({
    query: z.string().optional(),
    filters: z.object({
      priceMax: z.number().optional(),
      size: z.enum(["xs", "s", "m", "l", "xl"]).optional(),
      inStock: z.boolean().default(true),
    }),
  }),
});

Note the enum on size. Give an agent a free-text size field and it will send "Medium", "med", "M" and "medium (UK)" across four requests. Constrain the input and the whole class of problem disappears.

The cart must be idempotent

Agents retry. A network blip, an ambiguous response, an over-eager loop — and add_to_cart fires twice. If your endpoint is not idempotent, the customer receives two jackets.

Accept a client-supplied idempotency key on every mutating operation and return the same cart state for a repeated key. This is standard practice in payments and mostly absent from cart APIs, which is exactly where it now matters.

Checkout is where autonomy stops

Search, compare, configure and assemble a cart — all reversible, all safe to automate. Charging a card is not reversible in the same cheap way, and it is where trust is won or lost.

The pattern that works: the agent prepares a complete, priced, itemised order and hands the customer a single confirmation step. One tap, full visibility, no surprises. You keep almost all the convenience and remove nearly all the risk.

Make yourself readable

Alongside the tool layer, the boring fundamentals matter more than they used to:

• Product schema markup so crawlers and assistants can parse price and availability without scraping.
• A clean feed — a structured export of the catalogue is easier to consume than any HTML page.
• Honest stock and delivery data. An agent that promises Friday delivery because your API lied will not shop with you again, and neither will its owner.
• Stable identifiers. Agents cache. SKUs that change break carts assembled minutes ago.

The storefronts that win the agent era will not be the ones with the best hero image. They will be the ones an agent can query precisely, trust completely, and transact against safely.