A new traffic source for online stores quietly turned on over the last year: AI assistants that read stores on behalf of their human users and recommend or buy from them.
When a customer asks ChatGPT "where should I buy a hand-thrown ceramic mug from a small studio in Portugal," ChatGPT doesn't search the way Google does. It reads candidate stores' machine-readable surfaces — llms.txt, structured data, sometimes OpenAPI manifests — and assembles an answer. Claude does the same. So does Perplexity. So will the next half-dozen agents.
The customer doesn't see the URL of the source. They see "I found three studios that fit; here are their stories and what they sell." The agent then either links the customer to the store or, increasingly, completes the purchase on their behalf through standardised commerce APIs.
If your store can't be read by an agent, you're missing from those answers. Here's what "agent-shoppable" actually requires, why it's not the same as "good SEO," and what we built into LOAM to make every store ready for it by default.
Why this is not just SEO
Classic SEO optimises for Google's blue links. The user sees a list of URLs, clicks one, lands on your store, and you have a chance to convert them. The whole game is structured around getting onto page one for a relevant query.
AI search inverts this. The user asks a question, the AI assembles an answer from many sources, the user sees the answer (not the URLs), and the AI either links to a source or transacts on the user's behalf. The optimisation target isn't ranking — it's being a citable source.
The difference matters for what you build:
- SEO optimises for words on the page. Agent-shoppable retail optimises for structured machine-readable surfaces.
- SEO assumes the human reads the page. Agent retail assumes the agent reads the page and the human reads the agent's summary.
- SEO measures ranking position. Agent retail measures citation rate and downstream conversion.
These aren't either-or. You want both. But the work for the second is different from the work for the first.
The four surfaces an agent reads
In practice, an agent that wants to recommend or transact with your store reads from four distinct surfaces. Three are simple; one is more involved.
1. /llms.txt — A plain-text manifest at your root. Says who you are, what you sell, who it's for, how an agent should browse you. Originally proposed for documentation sites; commerce adopted it within months because it works the same way for shops. Costs about 30 lines of text to ship.
2. /.well-known/openapi.json — The OpenAPI 3.1 manifest of your storefront API. Tells an agent what endpoints exist, what data they return, what parameters they take. The agent uses this to know "I can fetch /products?category=ceramics" without reverse-engineering your frontend.
3. /.well-known/mcp/server-card.json — The Model Context Protocol server card. Newer (SEP-1649). Lets an agent that supports MCP discover your store as a capability and call its tools (search products, get product detail, check availability, place order). This is the surface that's growing fastest because OpenAI, Anthropic, and Google all picked it as the standard.
4. JSON-LD on every page — Product, Offer, Organization, FAQPage, BreadcrumbList. Schema.org markup that's been around for a decade but matters more than ever because agents extract structured facts from it. A product page with proper Product+Offer+AggregateRating JSON-LD is dramatically more citable than one without.
Build all four and your store goes from invisible to AI search to a citable source for the question categories you care about.
What's hard about this
Two things are hard about agent-shoppable retail, and neither is the technology.
The first hard thing is consistency. Your llms.txt says you sell hand-thrown ceramics from a studio in Portugal. Your Organization schema says the same. Your Product schema says each item is a ceramic mug. Your page copy is consistent. When an agent reads three or four signals and they agree, citation rate goes up materially. When they disagree, the agent gets cautious — or picks a competitor whose signals don't conflict.
This is mostly an editorial discipline, not an engineering one. The platform can ship the right surfaces; you have to be consistent in what you say across them.
The second hard thing is transactability. Browsing your store is one thing; placing an order is another. For an agent to transact, it needs:
- A standard order-placement endpoint (MCP
place_orderor REST equivalent) - An auth model that distinguishes "agent acting on behalf of customer" from "anonymous browser" — typically OAuth 2.0 with PKCE
- A returns policy clear enough that the agent can summarise it before the customer commits
- Pricing that's actually current — agents catch stale prices and downgrade your citation
This is where a lot of "AI commerce" stories get stuck. Browsing is easy; transacting is hard. Most stores today aren't ready for transactional agents because they were built for browser-only customers.
What LOAM ships by default
Every store on LOAM ships with all four surfaces from day one, no merchant configuration required:
- llms.txt is generated from the brand and catalogue during onboarding. The merchant can override; the default works.
- OpenAPI 3.1 is published at the storefront's
/.well-known/openapi.jsonand describes the full storefront API (products, collections, cart, checkout, customer). This is the same API the LOAM-hosted storefront uses; it's not a separate "agent API." - MCP server card is published at
/.well-known/mcp/server-card.json. Each store exposes the same toolset:find_stores,search_products,get_product,add_to_cart,start_checkout. Agents that support MCP discover and call these directly. - JSON-LD on every page — Product, Offer, Organization, WebSite, FAQPage where relevant, BreadcrumbList, Article on blog posts. Generated by the platform; merchant edits flow through to the schema.
There's a platform-level MCP at loam.st/api/mcp that exposes cross-tenant discovery — find_stores, get_store, browse_themes. So an agent that doesn't already know about a specific LOAM store can find one. This is the "yellow pages" surface, and it's how agent-driven discovery flows into specific store transactions.
How to measure agent-driven traffic
You can't manage what you can't measure. Three signals to watch:
1. Referrer matches for AI crawlers. ChatGPT-User, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended all show up in your access logs. LOAM exposes this in the analytics dashboard as "AI traffic." Most stores see 5–15% of organic traffic from AI crawlers today; we expect 30–50% by 2027.
2. Agent-driven sessions. Sessions that arrive with an LLM referrer and convert. LOAM tracks these distinctly from human organic sessions because the funnel is different (less time on page, more direct add-to-cart, fewer comparison views).
3. Direct MCP usage. When agents call your MCP endpoint to transact — the next-gen metric. Today this is small but growing. LOAM logs every MCP call so you see which agents (ChatGPT, Claude, custom) are exercising your store.
If your platform doesn't expose these, you're flying blind on a traffic source that's about to be a meaningful percentage of your revenue.
What's coming
The next big shift is agent-completed purchases — the agent doesn't just recommend your store, it transacts on the customer's behalf, with stored payment credentials, returning a receipt to the customer's chat. This already works in narrow contexts (OpenAI Tasks, Anthropic's MCP demos). It will be commonplace within 12–18 months for low-risk commerce categories first (perishables, consumables, replenishments) and then for everything.
Stores that aren't agent-shoppable lose this entire customer journey. Stores that are agent-shoppable see it as net new revenue from a customer who never visited the storefront.
The lift is small. The window is short. The competitive advantage compounds.
If you want to make a store agent-shoppable today, we wrote LOAM to do all of it for you by default — read more on /features or /agent. If you'd rather build it yourself, the LOAM API catalog is open and the four surfaces above are the priority order.