Ecommerce Product Discovery for AI Agents

12 min read

Ecommerce product discovery for AI agents is the process of turning a buyer's request into a short, defensible set of purchasable variants. It needs two data paths: an index for stable product facts and a runtime lookup for volatile facts such as price, inventory, promotion eligibility and delivery promise. If those paths are collapsed into one stale index, the agent will eventually recommend an option it cannot buy.

This guide is for commerce architects and search engineers who need an implementation they can test, not another catalog-feed checklist. The outcome is a discovery service that can explain why a variant matched, prove that hard constraints were satisfied and revalidate the offer before a consequential action.

It is part of Intelliger's agentic commerce architecture guide, which connects discovery to transaction and trust boundaries.

What product discovery means in an agent system

Traditional site search often optimizes a list for a human who can inspect filters, badges and product pages. An agent needs a smaller and more explicit contract. It must resolve an underspecified request, compare variants, preserve hard constraints and know which facts require a fresh lookup.

Use these definitions consistently:

• Product is the durable commercial concept, such as a shoe model.
• Variant is a purchasable configuration with its own identifier, such as size 44 in black.
• Indexed fact changes slowly enough to live in a search index, such as material, dimensions or compatibility.
• Live state can change between retrieval and action, such as stock, price or delivery estimate.
• Eligibility is a hard pass or fail decision derived from constraints, policy and live state.
• Preference affects ranking but does not make an ineligible item eligible.

This distinction matters beyond semantics. OpenAI describes product feeds as a way for merchants to represent catalogs and promotions in ChatGPT, while also describing local availability and ETAs as evolving commerce capabilities (OpenAI product discovery). Shopify's agent-facing store description exposes discovery endpoints, read-only product data and commerce capabilities rather than assuming one page contains every answer (Shopify agents.md documentation). Both point toward a contract made of structured data and callable capabilities.

Build two data planes, not one oversized document

The discovery path should be readable as a simple state model:

1. Ingested: source records are mapped to canonical product and variant identities.
2. Indexed: stable facts are searchable and carry source timestamps.
3. Retrieved: candidates match lexical, semantic and structured constraints.
4. Validated: authoritative services confirm current price, stock and other volatile facts.
5. Ranked: eligible candidates are ordered using preferences and evidence quality.
6. Presented: the agent receives a small set with reasons and freshness metadata.
7. Revalidated: the selected offer is checked again before cart or checkout.

In accessible terms, the index answers "what could fit?" and live systems answer "what can be bought now?" The agent should never be asked to reconcile contradictory inventory snapshots itself.

type Currency = 'USD' | 'EUR' | 'GBP';

interface IndexedVariant {
  productId: string;
  variantId: string;
  title: string;
  attributes: Record<string, string | number | boolean>;
  categoryPath: string[];
  compatibleWith: string[];
  sourceUpdatedAt: string;
}

interface LiveOffer {
  variantId: string;
  market: string;
  priceMinor: number;
  currency: Currency;
  availableQuantity: number | null;
  purchasable: boolean;
  promotionIds: string[];
  delivery?: { postalCode: string; earliestDate: string };
  observedAt: string;
  expiresAt: string;
}

interface DiscoveryCandidate {
  variant: IndexedVariant;
  offer: LiveOffer;
  eligible: boolean;
  failedConstraints: string[];
  preferenceScore: number;
  evidence: Array<{ field: string; source: string; observedAt: string }>;
}

Do not copy priceMinor or availableQuantity into the durable product record and forget their age. Google Merchant Center explicitly defines availability values and expects landing-page and checkout availability to agree (Google availability specification). An internal agent service needs at least the same discipline.

Normalize identity before improving ranking

Most discovery failures blamed on embeddings are identity failures. A supplier SKU, ERP material number, marketplace listing and storefront variant may refer to the same sellable unit. Keep the mapping explicit and versioned.

canonical_variant: shoe-482-black-44
identifiers:
  merchant_sku: SH482-BLK-44
  gtin: '00012345678905'
  erp_material: '4820044'
attributes:
  color: black
  size_system: EU
  size: 44
provenance:
  attributes: pim://products/482/version/91
  compatibility: rules://footwear/2026-07-15

Do not silently merge records solely because their titles are similar. Require a deterministic key or a reviewed reconciliation rule. Preserve the original value beside the normalized value, particularly for units, color families and regional sizing. The original supports audit and correction; the normalized value supports retrieval.

For bundles and configurable products, model components and selection rules. An agent asking for "the laptop with 32 GB RAM" needs to know whether 32 GB is a stocked variant, a build-to-order option or an incompatible combination. Flattening all three into a text description creates false positives.

Turn conversation into constraints before retrieval

An LLM can parse language, but the retrieval service should consume a typed query. Separate hard constraints from preferences and unresolved questions.

interface DiscoveryIntent {
  category: string;
  hard: Array<{
    field: string;
    op: 'eq' | 'in' | 'gte' | 'lte' | 'compatible';
    value: string | number | boolean | string[];
  }>;
  preferences: Array<{
    field: string;
    direction: 'prefer' | 'avoid';
    weight: number;
    value: unknown;
  }>;
  market: { country: string; postalCode?: string; currency: Currency };
  unresolved: string[];
}

Reject or clarify contradictory hard constraints before search. If a buyer wants a 16-inch laptop weighing less than one kilogram and the catalog contains none, return a structured no-match result. Do not quietly relax the weight limit. If the user says "lightweight," treat it as a preference until the conversation establishes a threshold.

Retrieval should combine four signals:

1. Structured filtering for category, dimensions, certification and compatibility.
2. Lexical retrieval for exact model names, technical terms and SKUs.
3. Semantic retrieval for descriptive needs and synonyms.
4. Business eligibility for market, channel and policy restrictions.

Fetch live offers for a bounded candidate pool, then remove failed hard constraints. Rank only what remains. The related AI search for ecommerce guide covers this pipeline and its evaluation in more depth.

Return evidence an agent can use

A product result should not be a prose paragraph generated from hidden fields. Return structured facts, source references and explicit reasons.

{
  "variantId": "shoe-482-black-44",
  "eligible": true,
  "matchReasons": [
    { "constraint": "size = EU 44", "field": "size", "value": 44 },
    {
      "constraint": "color in [black, navy]",
      "field": "color",
      "value": "black"
    }
  ],
  "offer": {
    "priceMinor": 12900,
    "currency": "EUR",
    "purchasable": true,
    "expiresAt": "2026-08-11T14:05:00Z"
  },
  "provenance": {
    "product": "pim://products/482/version/91",
    "offer": "commerce-api://offers/shoe-482-black-44/request/8f31"
  }
}

This shape lets the conversational layer explain a result without becoming the authority for its price or eligibility. It also enables a deterministic verifier to compare what the agent said with what the service returned.

Keep the candidate set small enough to reason over, commonly a configurable top-k rather than the whole catalog. Do not hard-code a universal number. Complex industrial products may need more candidates during compatibility resolution than commodity products.

Failure cases and recovery paths

Stale price in the index. The candidate looks eligible at $89, but the offer service returns $109. Replace the indexed display value with the live offer, record the discrepancy and rerank if the price violates a budget. Do not preserve the lower price in generated copy.

Variant-level stock hidden by product-level stock. The product is "in stock," but the requested size is unavailable. Live validation must use the variant identifier. If no exact variant passes, return alternatives with the relaxed constraint clearly named.

Compatibility inferred from description. A semantic match suggests a part fits a machine, while the compatibility table says it does not. The deterministic compatibility source wins. Route unknown compatibility to clarification or human review.

Offer service timeout. Never convert "unknown" to "available." Return candidates as unverified, retry within a bounded budget or degrade to browse-only results. Disable cart actions until a fresh offer is available.

Catalog update races with deletion. An index still contains a discontinued variant. Use tombstones and monotonic source versions. A live not_found response should suppress the candidate and enqueue an index repair.

Delivery promise lacks destination. Do not show a generic ETA as a committed promise. Ask for postal code or label the estimate with its assumptions.

These recoveries work because unknown, false and stale are separate states. A Boolean available field is not enough.

A reproducible discovery evaluation

Build a fixture from catalog snapshots and authoritative offer responses. Each case should include the intent, expected eligible set, forbidden variants and the clock used for freshness checks.

case: waterproof-hiking-shoe-eu44-under-150
clock: 2026-08-11T14:00:00Z
intent:
  hard:
    - [category, eq, hiking-shoe]
    - [waterproof, eq, true]
    - [size, eq, 44]
    - [priceMinor, lte, 15000]
expected:
  must_include: [shoe-482-black-44]
  must_exclude: [shoe-117-black-43, shoe-901-blue-44]
  max_offer_age_seconds: 300

Run the same fixture after every schema, synonym, model or ranking change. Measure at least:

Keep a separate human judgment set for subjective preferences. Do not mix "I prefer this style" with hard eligibility metrics. OpenAI similarly reports product accuracy in shopping evaluation as whether recommended products satisfy user requirements, while warning that current price and availability can still be wrong (OpenAI shopping research).

Implementation checklist

• Establish canonical product and variant IDs across PIM, ERP and storefront systems.
• Label every field as indexed, live or derived, with a source and freshness rule.
• Normalize units and taxonomies without deleting original values.
• Parse hard constraints, preferences and unknowns into separate structures.
• Combine structured, lexical and semantic retrieval before live validation.
• Apply compatibility and policy rules deterministically.
• Return evidence, timestamps and failed constraints with each candidate.
• Revalidate the selected offer before cart or checkout.
• Test stale, missing, conflicting and timed-out data paths.
• Version fixtures so ranking changes can be compared against the same catalog state.
• Send unsupported or safety-sensitive compatibility claims to qualified review.

Where Intelliger and OATI fit

Intelliger's commerce architecture is currently a blueprint, not a claim that a production Commerce Graph, Merchant Agent Runtime or Agent Search Console is deployed for customers. The target design places normalized catalog facts in a commerce graph, resolves volatile state through merchant connectors and exposes evidence-bearing capabilities to agents.

OATI is a separate open-standard developer preview for authorizing and recording consequential agent actions. Its schemas, SDKs, CLI, conformance suite, local sandboxes and a public trust/lookup vertical slice are available today. Independent review, a complete policy compiler, evidence and dispute workflows, a customer gateway fleet and two-enterprise production acceptance remain incomplete. See the OATI overview, documentation and public repository for the current boundary.

Security-sensitive eligibility, authorization and payment designs require expert review before production use. This guide provides an engineering pattern, not a certification of a specific implementation.

If you are turning a large catalog into an agent-facing discovery service, bring one category and its failure cases to an Intelliger architecture review.