How AI Agents Buy From Online Stores: The Full Path

Quick answer. AI agents buy from online stores the way a careful shopper would, without a screen. They find product pages or catalogue feeds, read structured data for price, stock and variants, compare options against the buyer’s constraints, then either hand the choice back to the buyer or complete checkout through an API or a delegated payment credential. Your job is to make every step unambiguous to software.

What matters most

• An agent buys in five stages — discovery, retrieval, extraction, comparison, transaction — and most stores fail at extraction, not at checkout.
• Schema.org Product and Offer markup in server-rendered HTML is the highest-leverage fix, and contradictory markup is worse than no markup at all.
• Fully automated payment is still the exception; most agent journeys end with a cart handoff link, so build that handoff properly.
• Discovery is fragmented across search indexes, product feeds, marketplace catalogues and tool servers, and no single standard covers all four.
• Agent fetchers usually do not run JavaScript, so client-side analytics will undercount them; server logs are the more reliable source.

What does an AI agent do between a customer’s request and a paid order?

An AI agent is software that takes a goal, plans steps and calls tools until the goal is met. For a purchase, the goal is a constraint set: a waterproof jacket, size medium, under a set price, delivered by a date. The agent cannot see your storefront. It reads text, HTML and structured data, and it acts through whatever interfaces you expose.

The path has five stages. Each one fails in a different way, so each needs a different fix.

Stage five is the one people overestimate. Most agent journeys still end with a filled cart and a link the buyer clicks. Fully automated payment happens on specific, supported paths, not everywhere. Build for the handoff and the ceiling will not surprise you.

The stages also have different owners inside your business. Discovery is a feed and SEO problem. Extraction is a templating and data problem. Transaction is a checkout and payments problem. Treating agentic commerce as one project is why it stalls.

• Discovery: the agent finds candidate products through a search index, a product feed, a marketplace catalogue or a tool server you publish.
• Retrieval: it fetches the product page, the feed row, or calls an API endpoint.
• Extraction: it pulls price, currency, availability, size, colour, delivery estimate and return terms out of what it fetched.
• Comparison: it filters and ranks against the buyer’s constraints. Contradictory data loses the sale here.
• Transaction: it builds a cart, then completes payment or hands a checkout link back to the buyer.

Where to go next

• agentic delivery platforms and what they change for a storefront
• the commerce platforms we build and audit on
• e-commerce SEO for catalogue and product pages
• analytics and attribution for agent traffic

What does an agent actually read on a product page?

Most agents fetch the raw HTML. Some run a full browser and see the rendered page, but a large share do not execute JavaScript. If your price or stock appears only after a client-side call, part of your audience will never see it.

The dependable layer is schema.org Product and Offer markup in JSON-LD, in the HTML your server returns. Google’s product structured data documentation sets out the properties it expects for merchant listings. Those same properties answer an agent’s questions, which is why the markup pays twice.

The failure mode is rarely missing markup. It is contradictory markup. A price in JSON-LD that disagrees with the price on the page. A sold-out size still marked InStock. An empty priceCurrency. A parent product marked available while every variant is gone. An agent that hits a conflict will take the conservative reading or drop you entirely, and you will not see it in a funnel report.

Two things stores routinely omit: a stable canonical URL per variant, and specifications as text in a table rather than an image or an accordion that loads on click. Both are cheap. Both are read by every agent that reaches the page.

Where do agents find your products in the first place?

There is no single agent catalogue. Discovery is split across four surfaces, and they do not automatically agree with each other.

Treat the llms.txt proposal plainly. It is a convention, published at llmstxt.org, for a Markdown file that summarises a site for language models. It is not a ratified standard, and no major agent platform has said it depends on one. Publishing it costs an hour. It is not a substitute for product markup or a feed.

An MCP server is the more substantive option. MCP is an open protocol for connecting AI applications to external tools and data. For a store, that means a small read-only surface: search products, fetch one by ID, check stock and price. An agent calling a function gets a deterministic answer instead of guessing from HTML. You still need the pages to be right, because that is where most agents start.

Feeds and pages answer different questions. A feed says what you sell and at what price. A page says why it fits. Agents need the first to shortlist and the second to justify the choice. Generate both from the same source of truth.

• Search indexes: pages that rank and qualify for rich product results are the pages AI features can surface.
• Product feeds: Merchant Center and marketplace feeds carry price, availability and identifiers in a fixed schema, which is easier to parse than a page.
• Tool servers: an MCP server exposes your catalogue as callable functions rather than as HTML to be scraped.
• Site-level files: robots.txt, XML sitemaps and the proposed /llms.txt.

Where does the buying path break?

Checkout is where agent journeys stop. The obstacles are ordinary and mostly deliberate.

Some of that is the point. Fraud controls and strong customer authentication exist for good reasons, and no store should weaken them to accommodate an agent. The practical middle ground is a handoff: the agent assembles a cart, then passes a link that opens checkout with the cart intact. The buyer finishes with their own credentials.

Fully delegated payment is being built. The patterns involve payment credentials scoped to a merchant, an amount and a time window, plus checkout flows designed for agents rather than browsers. Which pattern becomes standard is unsettled, and the answer will differ by market and payment provider. Do not rebuild your checkout around one vendor’s agent programme. Do make sure a cart can be created by URL or API, because that part is stable and already useful.

One operational gap worth naming: stock reservation. A human checks out in minutes. An agent may hold a cart while the buyer is asked to confirm, which can take hours. If your inventory only decrements at payment, two buyers can be promised the same unit. Decide how long a cart holds stock, and say so on the page.

• Forms that need a session, cookie or hidden token the agent cannot obtain.
• Bot management and CAPTCHA on cart and checkout endpoints.
• Account creation, email verification and one-time codes.
• 3-D Secure and payment challenges designed to require a human.
• Address, tax and shipping logic that depends on a browser session.

What should you fix first on the platform you run?

Start with what the platform already exposes. In most stores the data an agent needs already exists in the admin. The work is making it visible in server-rendered HTML and consistent across every channel.

Then make the page readable. Specifications in a table, not an image. One canonical URL per variant, or a parameter the page honours. No contradictions between the theme, the structured data and the feed. These are templating changes, not replatforming, and they are the same changes that help conventional search performance.

If you sell across several storefronts, audit them together. A variant that is available on one channel and unavailable on another is a data problem, and agents resolve it against whichever source they trusted first.

• Shopify and Shopify Plus: check the product template’s JSON-LD for per-variant Offers. Themes often emit one Offer for the parent product, so sold-out sizes look available. Render specifications from metafields on the server.
• BigCommerce: catalogue fields drive both the storefront and the Storefront API, so fixing identifiers and availability once fixes both.
• WooCommerce: variable products are the usual gap. Confirm each variation carries its own price and availability, not just the parent.
• Adobe Commerce and Magento: the GraphQL schema is the reference for what the catalogue actually holds. Mirror those fields into JSON-LD.
• Headless storefronts: render Product markup on the server. A JSON-LD block injected in the browser is invisible to fetchers that do not run JavaScript.

How do you measure agent traffic and orders?

Badly, at first. Most agent fetchers do not run JavaScript, so client-side analytics miss them. Referrals from AI assistants often arrive with no referrer. Order attribution is hardest of all: an agent that hands back a checkout link produces something that looks like a direct visit.

None of the methods below produces a complete number. Report the gap rather than presenting a partial figure as the total, because the missing share is the part that will grow.

• Server logs: count requests to product, cart and checkout URLs by user-agent.
• Structured data monitoring: alert when JSON-LD loses price, currency or availability.
• Tagged handoff links: a unique parameter per surface lets a completed order be traced back.
• MCP server logs, if you run one: tool calls are clean, countable events rather than page scrapes.

What is still unsettled?

Several things, and pretending otherwise would waste your budget.

The stable part is the data layer. Correct prices, availability and identifiers, served in HTML and in feeds, help every agent and every search surface regardless of which pattern wins. That is where the first quarter of work belongs.

• Checkout standards: competing agent checkout and payment patterns exist, and platform support varies.
• Discovery preference: whether agents favour feeds, structured pages or tool calls is not decided, and behaviour differs by agent.
• llms.txt adoption: it remains a proposal without a ratified standard behind it.
• Liability: who is responsible when an agent orders the wrong variant or ignores a delivery constraint is largely untested.
• Returns: agents can read a return policy, but starting a return on a buyer’s behalf is rarely supported.

Frequently asked questions

Do AI agents actually complete purchases on their own today?

Sometimes, on narrow supported paths. Agents routinely research, compare and build carts. Completing payment without a human still depends on the store, the payment provider and the permissions the buyer granted. It is the exception rather than the rule. Expect a handoff link at the end of most journeys, and make that handoff clean.

Do I need an llms.txt file for agents to buy from my store?

No. llms.txt is a proposal for a Markdown summary of your site aimed at language models. It is not a ratified standard and no major agent platform has said it requires one. It may help some crawlers understand your structure, but it does not replace product markup, a product feed or a working checkout. Publish it if it is cheap. Do not prioritise it.

Should agents read my product pages or my product feed?

Both, and the two should agree. Pages carry the detail a buyer sees: specifications, images, delivery text and returns. Feeds carry fixed fields: identifier, price, availability and condition. Agents that can parse a feed prefer it because it is unambiguous. Agents that start from a search result get the page. Contradictions between the two are the most common reason a product gets dropped.

Will bot protection block AI agents from my store?

It can, and often should. Bot management exists to stop scraping, card testing and inventory hoarding, and an agent that behaves like a scraper will be treated like one. The practical answer is to separate research traffic from transactional traffic: allow identifiable agents to read product pages at a reasonable rate, and require a human-authenticated session for payment.

How do I know if AI agents are visiting my store?

Start with server logs. Look for user-agent strings that identify AI crawlers and fetchers, and count requests to product, cart and checkout URLs. Client-side analytics will undercount, because most fetchers do not run JavaScript. For orders, tag cart handoff links with a unique parameter so a completed purchase can be traced back to the surface that produced it.

Sources

• Product and Offer types, and the properties used in product markup
• Google’s product structured data requirements for merchant listings
• Model Context Protocol: how AI applications connect to external tools and data
• The proposed llms.txt convention for a machine-readable site summary