How LLMs Discover and Evaluate Products

By the Agentic Commerce Report editorial team — covering the AI-to-checkout layer since September 2024.

AI agents powered by large language models are already discovering, evaluating, and purchasing products on behalf of users — without those users ever visiting a product page. For merchants, this represents both an urgent threat and a structural opportunity: if your catalog is not machine-readable in the ways LLMs expect, you will be invisible to an increasingly automated buyer.

This guide explains exactly how LLM product discovery and purchase works under the hood, and what operators must do to compete. For a foundational overview of how these systems are structured, see what is agentic commerce.

What Is LLM Product Discovery?

LLM product discovery is the process by which an AI agent — acting on a user's intent — queries multiple data sources, evaluates candidates, and surfaces (or purchases) one or more products without requiring the user to browse manually. The LLM serves as the reasoning layer: it interprets ambiguous natural-language intent ("find me a lightweight running shoe under $120 that works for wide feet"), decomposes that into structured sub-queries, retrieves product data from external sources, and synthesizes a ranked recommendation or executes a transaction.

This is distinct from traditional search-based discovery. A keyword search returns a list; the user does the evaluation. An LLM agent conducts the evaluation itself, then either presents a shortlist or — in fully autonomous configurations — proceeds directly to checkout.

How LLMs Process Purchase Queries

Intent Decomposition

When a purchase query arrives, the LLM does not execute a single lookup. It performs intent decomposition: breaking the natural-language request into a set of structured constraints that can be tested against product data.

A query like "I need a coffee grinder for espresso, quiet enough for an apartment, under $200" decomposes into:

The LLM maps these constraints to filterable attributes it can use when querying catalog APIs or passing parameters to web search tools. Constraints that cannot be directly parameterized — like "quiet enough for an apartment" — are retained as semantic evaluation criteria to apply when scoring retrieved results.

Query Planning

After decomposition, the LLM generates a query plan. In modern agentic frameworks, this plan is executed using tool calls: the LLM selects from a registered toolset (web search, catalog API, price comparison API, review API) and determines which to fire, in what order, and with what parameters.

The sophistication of this step is why structured product data matters so much. An LLM that retrieves a page of unformatted HTML must spend tokens parsing and inferring attributes. An LLM that retrieves clean JSON-LD with schema.org/Product fields can immediately apply its constraint filters without lossy text extraction.

Multi-Source Product Discovery Architecture

Production shopping agents do not rely on a single data source. They execute parallel queries across multiple feeds and merge the results. Understanding this architecture tells you where you need to be present.

Web Search APIs

The first retrieval layer is typically a web search API — Bing Search API, Google Custom Search, or Brave Search API. The agent submits a structured query ("burr coffee grinder espresso apartment quiet $200") and receives a ranked list of URLs and snippets.

These snippets are the first place where your product content is evaluated. If your title and meta description do not surface the attributes the agent is filtering on, your result will be deprioritized before the agent even fetches the page. For LLM-oriented search, descriptive, attribute-dense titles outperform brand-forward titles that bury specifications.

Catalog and Product Feed APIs

Many enterprise agents connect directly to catalog APIs: Google Shopping API, Amazon Product Advertising API, Shopify Storefront API, or proprietary retailer feeds. These return structured product records — often in JSON — which the LLM can process with high fidelity and low token cost.

If you operate on Shopify or a headless commerce platform, ensuring your Storefront API is clean, complete, and attribute-rich is a direct input to your discoverability. Missing variants, incomplete metafields, or absent size/weight/material attributes all reduce the signal quality an LLM can use to match your product to a user's constraints.

ACP and UCP Feeds

The Agent Commerce Protocol (ACP) and Universal Commerce Protocol (UCP) are emerging feed standards designed specifically for machine-to-machine commerce. Unlike Shopping feeds optimized for human-facing SERPs, ACP/UCP feeds expose inventory availability, real-time pricing, fulfillment SLAs, return policies, and transaction endpoints in a single structured payload.

Agents consuming ACP feeds can query availability and price without a separate inventory lookup, and can initiate a purchase transaction without navigating a checkout UI. Merchants who publish ACP-compliant feeds will have a structural advantage as agent adoption scales — their products are immediately actionable, not just discoverable.

Price Comparison APIs

Price sensitivity is among the most consistently applied constraints in purchase queries. Agents frequently invoke a price comparison step using APIs such as PriceAPI, Rainforest API, or direct integrations with comparison engines. This step occurs after candidate retrieval and before final ranking.

If your price is not the lowest, you need other attributes to compensate: faster shipping, better return policy, higher review scores, or availability that competitors lack. Agents weigh these tradeoffs explicitly — which is why surfacing them in structured data rather than in prose copy is essential.

Review and Sentiment APIs

LLMs evaluate social proof programmatically. Review APIs (Yotpo, Bazaarvoice, Google Reviews, Amazon ratings) return aggregate scores and, in richer implementations, sentiment breakdowns by attribute ("battery life: 4.2 stars", "noise level: 3.8 stars").

A product with a 4.8-star aggregate but consistently negative sentiment on the exact attribute the user cares about (noise) will rank lower than a product with a 4.4 aggregate and strong positive noise sentiment. Agents that have access to attribute-level review data will apply this signal. Merchants who surface granular review data via structured schema or API will benefit.

Parallel Query Architecture

The defining performance characteristic of production shopping agents is that they do not run these queries sequentially. They use parallel tool execution: all retrieval calls fire simultaneously, results are collected asynchronously, and the LLM processes the merged response set.

A simplified parallel query flow looks like this:

User intent → LLM decomposition → Query plan generated
                                        ↓
              ┌─────────────┬──────────────┬──────────────┐
              ↓             ↓              ↓              ↓
         Web Search    Catalog API    Price API    Review API
              ↓             ↓              ↓              ↓
              └─────────────┴──────────────┴──────────────┘
                                        ↓
                              Merge & deduplication
                                        ↓
                              LLM ranking & evaluation
                                        ↓
                         Recommendation / purchase action

The latency budget for this entire flow in user-facing agents is typically 3–8 seconds. This constrains how many sequential hops an agent can make — which reinforces the value of APIs that return comprehensive data in a single call versus requiring multiple round-trips to assemble a complete product record.

For a deeper technical walkthrough of how agents orchestrate these calls, see how AI shopping agents work.

How LLMs Evaluate and Rank Products

Retrieval returns candidates; the LLM then performs evaluation — assigning scores to each candidate against the user's constraint set and synthesizing a ranked output.

Constraint Matching

Hard constraints are applied as filters. If the user specified a price ceiling of $200, any product above that threshold is eliminated regardless of other attributes. Soft constraints — like "quiet" — are evaluated probabilistically using a combination of:

• Attribute values from structured data (decibel ratings where available)
• Review sentiment on relevant dimensions
• Category-level priors in the LLM's training data
• Explicit mentions in product descriptions

Preference Inference

LLMs also apply implicit preference inference. A user who specifies "apartment" when asking about a coffee grinder has implicitly signaled a preference for compact form factors, not just low noise. An agent with strong reasoning capability will surface this inference and apply it as a soft constraint even though it was not explicitly stated.

This is a significant difference from keyword-based discovery. An LLM agent can match products to unstated needs — but only if the product data contains the attributes that allow that inference. A product description that simply says "great for home use" provides weaker signal than one that includes explicit dimensions, operating noise levels, and countertop footprint.

Ranking Signals Summary

Structured vs. Unstructured Product Data: Why Schema.org Matters

The difference between a structured and unstructured product record is not aesthetic — it is the difference between an LLM that can machine-evaluate your product in milliseconds and one that must spend tokens guessing your attributes from prose.

What Schema.org Provides

schema.org/Product with Offer markup gives agents a machine-readable representation of:

• name, description, sku, brand
• price, priceCurrency, priceValidUntil
• availability (InStock, OutOfStock, PreOrder)
• aggregateRating with ratingValue and reviewCount
• gtin, mpn (for cross-catalog deduplication)
• weight, depth, width, height (for physical constraint matching)
• color, size, material (variant attributes)

When a shopping agent fetches your product page, the JSON-LD block in <head> is parsed before any prose. If your schema is complete, the agent can evaluate your product against user constraints without reading a single sentence of your copy.

The Cost of Missing Schema

An LLM attempting to extract product attributes from unstructured HTML faces a high-variance, token-expensive process. For common attributes it may succeed with high confidence; for niche attributes (noise level, compatibility matrix, operating temperature range) it will frequently fail or hallucinate. The practical consequence: your product is evaluated against fewer of the user's constraints, reducing your match probability.

Extended Attributes and AdditionalProperty

The schema.org/PropertyValue type under additionalProperty allows you to expose arbitrary product attributes in structured form. For technical products especially, this is where constraint-matching precision lives:

{
  "@type": "Product",
  "name": "Baratza Encore ESP",
  "additionalProperty": [
    {
      "@type": "PropertyValue",
      "name": "Noise Level",
      "value": "65 dB"
    },
    {
      "@type": "PropertyValue",
      "name": "Grind Settings",
      "value": "40"
    }
  ]
}

Every attribute you expose in additionalProperty is a potential constraint-match point for an agent.

How Agents Handle Out-of-Stock and Alternatives

Out-of-stock handling is a critical branch in agent purchase flows. Unlike a human shopper who will simply look elsewhere, agents must make a reasoned decision between several options:

1. Wait for restock — if the user's query implies non-urgency and the agent can subscribe to availability webhooks
2. Select a functional equivalent — choose an alternative product that satisfies the same constraint set
3. Report and defer — present the out-of-stock status and ask the user for guidance
4. Expand the search scope — loosen a non-critical constraint (e.g., relax price ceiling by 10%) and re-query

The agent's choice depends on its configuration, the user's stated timeline, and the availability of alternative candidates already in the retrieved set. This is why having a clean availability field in your schema is not just good practice — it determines whether your product appears as a viable candidate at all, or whether an agent skips it immediately.

Merchants who publish RestockDate or availability notifications via ACP feeds enable agents to take path 1 — holding a purchase commitment for a specific product rather than redirecting to a competitor. This is a non-trivial retention mechanism as agentic commerce scales.

For a detailed breakdown of how agent checkout flows handle these branches, see AI checkout automation.

The Role of RAG in Product Discovery

Retrieval-Augmented Generation (RAG) is the architectural pattern underlying most production shopping agents. Rather than relying solely on the LLM's parametric knowledge (training data), a RAG system dynamically retrieves current product data and injects it into the LLM's context at inference time.

Why RAG Is Necessary for Commerce

LLM training data is static and has a knowledge cutoff. Product catalogs change daily — prices shift, inventory fluctuates, new SKUs launch, old ones discontinue. A shopping agent that relies on parametric knowledge will hallucinate prices, recommend discontinued products, and miss new releases. RAG solves this by pulling live data into the context window at query time.

RAG Architecture in Product Discovery

A typical RAG pipeline for product discovery works as follows:

1. Embedding generation — product records are chunked and embedded into a vector store (Pinecone, Weaviate, pgvector)
2. Query embedding — the user's natural-language intent is embedded using the same model
3. Semantic retrieval — top-k most similar product vectors are retrieved
4. Context injection — retrieved product records are injected into the LLM prompt as context
5. Grounded generation — the LLM generates its recommendation grounded in retrieved data, not training memory

Optimizing Product Records for RAG

If a retailer or aggregator is running a RAG-based product discovery system over your catalog, the quality of your product records determines your retrieval probability. Records that are:

• Dense with attributes — more facets means more embedding dimensions that can match diverse queries
• Written with natural-language descriptions — embedding models capture semantic similarity; clinical spec-only descriptions match fewer query phrasings
• Free of boilerplate — generic filler text ("perfect for any occasion") dilutes your attribute signal in the embedding space

For merchants building their own RAG-based discovery layer, chunk product records by logical attribute groups rather than by character count to preserve semantic coherence.

What Merchants Must Do to Be Discoverable by LLMs

1. Implement Complete schema.org/Product Markup

This is non-negotiable. Every product page needs JSON-LD with at minimum: name, description, sku, brand, offers (with price, priceCurrency, availability), aggregateRating, and relevant additionalProperty entries for technical attributes.

Validate your markup using Google's Rich Results Test and Schema.org's validator. Missing or malformed schema is not a minor issue — it directly reduces your discoverability in agent-mediated purchase flows.

2. Publish a Machine-Readable Product Feed

Beyond on-page schema, publish a structured product feed (Google Merchant Center feed, ACP-compliant feed, or Shopify Storefront API with complete metafield coverage). This is what agents consuming catalog APIs will access, and it needs to be more complete than your SEO-oriented schema because it must support transaction initiation, not just discovery.

3. Create an llms.txt File

The llms.txt standard (proposed by Answer.AI and adopted by a growing number of AI crawlers) provides a machine-readable index of your site's content for LLM consumption. It lives at yourdomain.com/llms.txt and lists the key URLs, their content types, and any guidance for AI agents about how to interpret and use your content.

For an ecommerce site, a well-formed llms.txt signals to crawlers which URLs are product pages (vs. editorial, legal, or navigation), which sections are canonical for pricing and availability, and what your robots.txt permissions are for AI crawling specifically.

4. Practice Answer Engine Optimization (AEO)

AEO is the discipline of structuring content so it can be extracted and cited by AI answer engines — Perplexity, ChatGPT with browsing, Google AI Overviews, and Bing Copilot. For ecommerce, AEO means:

• Writing product descriptions in a format that answers implicit purchase questions ("Is this product compatible with X?" "What is the return policy?")
• Placing key specifications in lists or tables, not buried in paragraphs
• Including FAQ sections on product pages that address the exact questions a shopping agent would ask on behalf of a user
• Ensuring your category pages answer comparison questions ("What is the difference between model A and model B?")

5. Maintain Real-Time Inventory Signals

Stale inventory data creates a poor agent experience: an agent recommends your product, the user's agent attempts to purchase, and the item is unavailable. This creates a trust failure that damages the agent's confidence in your catalog for future queries. Inventory accuracy is a discoverability factor, not just an operations issue.

Publish availability via schema with priceValidUntil dates, connect to real-time inventory via API, and implement webhook notifications where possible to alert agent platforms of restock events.

6. Optimize for Attribute Completeness, Not Just Keywords

Traditional SEO optimizes for keyword density and topical relevance. LLM product discovery optimizes for attribute completeness and constraint satisfiability. A product page that ranks for "best espresso grinder" using keyword techniques may still lose to a competitor whose page has a structured noise level attribute, a gtin for cross-catalog matching, and an additionalProperty for grind setting count.

Audit your product catalog for attribute gaps — the attributes your competitors expose in structured form that you do not. Every gap is a potential constraint your products fail to satisfy in an agent evaluation.

Merchant LLM Discoverability Checklist

For a deeper operational breakdown of how to deploy these changes across a large catalog, see AI agents for ecommerce.

Frequently Asked Questions

What is LLM product discovery?

LLM product discovery is the process by which an AI agent uses a large language model to interpret a user's purchase intent, query multiple data sources (web search, catalog APIs, price feeds, review APIs) in parallel, evaluate retrieved product candidates against the user's constraints, and return a ranked recommendation or initiate a purchase. It replaces the human browsing session with an automated reasoning process.

How is LLM product discovery different from Google Shopping?

Google Shopping matches keyword queries to product listings and presents them for human evaluation. LLM product discovery performs the evaluation itself: the AI agent applies constraint filters, synthesizes review sentiment, compares prices, checks availability, and produces a final recommendation or purchase decision without requiring the user to compare products manually. The user specifies intent once; the agent handles the rest.

Why does schema.org markup matter for AI agents?

Schema.org markup provides machine-readable product attributes in a standardized format. When a shopping agent fetches your product page, it parses your JSON-LD schema before reading any prose. Complete schema means the agent can evaluate your product against user constraints precisely and efficiently. Incomplete or absent schema forces the agent to extract attributes from unstructured text, which is slower, less accurate, and more likely to produce mismatches.

What is llms.txt and do I need it?

llms.txt is a proposed standard (analogous to robots.txt) that provides AI crawlers with a structured index of a website's content and guidance on how to interpret it. For ecommerce operators, it signals which URLs are product pages, which contain pricing or policy information, and what crawling permissions apply. It is not yet universally required, but early adoption provides a practical advantage as AI crawler behavior standardizes around it.

What is AEO (Answer Engine Optimization)?

Answer Engine Optimization (AEO) is the practice of structuring content so it can be directly extracted and cited by AI answer engines. For ecommerce, this means writing product descriptions and FAQ content in formats that answer the specific questions a shopping agent would ask — compatibility, sizing, return policy, shipping speed — rather than in marketing language optimized for human emotional response. AEO is increasingly important as AI search surfaces account for a growing share of product discovery traffic.

How do agents handle out-of-stock products?

Agent behavior on out-of-stock products depends on the agent's configuration and the availability data it receives. With clean availability schema, an agent can filter out-of-stock items before ranking — avoiding the recommendation entirely. More sophisticated agents can subscribe to restock webhooks (via ACP feeds) to hold a purchase intent and complete the transaction when inventory returns, rather than substituting a competitor product.

What are ACP/UCP feeds and how do they differ from Shopping feeds?

Agent Commerce Protocol (ACP) and Universal Commerce Protocol (UCP) are machine-to-machine feed standards designed for agentic commerce. Unlike Google Shopping feeds (optimized for SERP display), ACP/UCP feeds expose real-time inventory, pricing, fulfillment SLAs, return policies, and transaction endpoints in a single payload. They enable an agent to discover, evaluate, and purchase in a single feed interaction rather than requiring multiple API round-trips.

How does RAG improve product discovery accuracy?

Retrieval-Augmented Generation (RAG) ensures shopping agents work from live product data rather than the LLM's static training knowledge. Product records are embedded into a vector database; at query time, the most semantically relevant records are retrieved and injected into the LLM's context. This enables accurate price, availability, and specification responses without hallucination from outdated training data. For merchants, it means that the quality and completeness of your product data — not your SEO keyword strategy — determines whether your products surface in RAG-powered discovery systems.

Further reading: What Is Agentic Commerce? — the foundational guide to how AI agents initiate, negotiate, and complete commercial transactions. | How AI Shopping Agents Work — a technical walkthrough of how agents orchestrate retrieval, evaluation, and purchase. | AI Checkout Automation — how agents handle the final step from product selection to completed purchase. | AI Agents for Ecommerce — operational guide for merchants preparing their stores for agent-driven commerce.