Skip to main content
Intelliger
Agentic Commerce

Why Your Store Is Invisible to AI Shopping Agents

Make an online store visible to AI shopping agents with structured product data, live inventory, executable capabilities and measurable discovery signals.

Why Your Store Is Invisible to AI Shopping Agents
Intelliger•
13 minute read

Your product page can be fast, attractive and profitable with human visitors while remaining nearly useless to an AI shopping agent.

The agent does not experience the page as a shopper does. It needs to resolve a product identity, compare typed attributes, select a valid variant, check compatibility, confirm current price and inventory, understand delivery constraints and discover which actions the merchant supports. If those facts are trapped in images, prose, client-side state or inconsistent feeds, the agent must guess. Good agents avoid guessing when money is involved.

This is no longer a hypothetical distribution channel. OpenAI says merchants can share product feeds and promotions through ACP for product discovery in ChatGPT, while Shopify describes its Catalog API as structured, queryable infrastructure for AI surfaces and has opened UCP tooling to developers. OpenAI's product discovery announcement and Shopify's Spring 2026 developer release make the direction plain.

The practical question is not whether your home page looks ready for AI. It is whether a machine can build a correct, current and actionable representation of what you sell.

Why AI shopping agents lose products at five stages

A product must survive five stages before an agent can recommend it with confidence:

eligible for access
  -> correctly identified
  -> retrieved for the intent
  -> validated against live state
  -> executable through supported actions

A failure at any stage makes the store functionally invisible.

Access fails when automated clients are blocked or no feed, API or supported integration exists. Identity fails when the same product has different IDs across the storefront, feed and inventory system. Retrieval fails when titles and descriptions omit the attributes people actually ask about. Validation fails when indexed price or availability disagrees with checkout. Execution fails when an agent can find an item but cannot determine how to select a variant, create a cart, obtain a quote or hand off to the merchant.

Traditional SEO can help with access and page discovery. It does not solve the entire chain.

Build a canonical product model before adding an agent

Most stores already have several product models. The PIM describes a family. The commerce platform stores variants. The ERP owns inventory. A search index flattens attributes. Marketing pages use hand-written names. The same blue safety shoe may appear under a SKU, a GTIN, a platform product ID and an internal material number.

An agent-facing layer needs a canonical identity map rather than another copy of the catalog.

type ProductVariant = {
  productId: string
  variantId: string
  merchantId: string
  sku: string
  gtin?: string
  brand: string
  category: string
  attributes: Record<string, string | number | boolean>
  compatibleWith: string[]
  marketRestrictions: string[]
  sourceVersion: string
}

Keep source identifiers and provenance. If two records appear to describe the same item but their GTIN, size system or material differs, do not merge them because an embedding says they are similar. Entity resolution errors become wrong recommendations, invalid carts and avoidable returns.

Variants deserve first-class records. A product family called "Trail Runner" is not purchasable if the shopper needs EU size 43 in blue. The agent must know which attributes select a variant, which combinations exist and which variant identifier belongs in the cart operation.

Treat attributes as queryable facts

Agents receive requests that do not match merchandising copy:

I need a black, EN ISO 20345 S3 safety boot,
wide fit, size 43, compatible with orthotic insoles,
delivered to Leipzig by Friday.

A paragraph that says "built for demanding work" contributes almost nothing. Retrieval needs typed fields and normalized units:

{
  "category": "safety_footwear",
  "colour": "black",
  "certifications": ["EN ISO 20345 S3"],
  "fit": "wide",
  "size_system": "EU",
  "sizes": [40, 41, 42, 43, 44, 45],
  "orthotic_insole_compatible": true,
  "weight_g": 690
}

Do not make every merchant invent these names. Map merchant-native fields into a canonical vocabulary, but retain the original value and mapping confidence. Category-specific schemas matter because laptop memory, shoe width and industrial valve pressure are not interchangeable generic attributes.

Missing is different from false. An absent compatibility claim means "unknown," not "incompatible." That distinction lets the agent ask a question, exclude the product under a hard constraint or present uncertainty honestly.

Google's product data requirements provide a useful baseline for identifiers, titles, images, brands and offer data. Its guidance also requires consistency between submitted availability, landing pages and checkout. Google Merchant Center's availability specification is worth reading even if Google is not your target agent surface, because it exposes the operational discipline behind reliable machine-readable commerce.

Separate stable facts from volatile state

Catalog indexes are good at descriptive facts that change slowly: brand, material, dimensions, compatibility and certifications. They are poor final authorities for stock, customer-specific price, promotions, delivery promises and cart state.

Use a two-speed architecture:

Stable product facts
  -> feed and change events
  -> normalized catalog
  -> lexical and semantic indexes

Volatile commercial state
  -> authoritative commerce APIs
  -> price, inventory, promotion, ETA and eligibility
  -> checked immediately before recommendation and execution

This avoids two bad extremes. Scraping every page at query time is slow and unreliable. Treating yesterday's index as the source of truth creates false promises.

The lookup should return freshness and scope, not only a value:

{
  "variant_id": "variant:boot-43-black",
  "market": "DE",
  "price": { "amount": "129.00", "currency": "EUR" },
  "availability": "in_stock",
  "available_quantity": 3,
  "delivery": { "postal_code": "04109", "date": "2026-08-14" },
  "observed_at": "2026-08-11T09:12:04Z",
  "expires_at": "2026-08-11T09:17:04Z"
}

Do not return a global in_stock flag if inventory depends on location, fulfillment method or buyer eligibility. Do not treat a list price as the amount a particular customer will pay. Price and availability need market, currency, tax and customer context.

OpenAI's shopping guidance explicitly tells users to confirm final price, shipping and availability on the merchant site because these facts change and may be incomplete. The official shopping research guide is a reminder that discovery data does not eliminate runtime verification.

Retrieval needs more than embeddings

Putting the entire catalog into a vector database is not an agent commerce architecture. Semantic retrieval is useful for fuzzy intent and vocabulary mismatch, but hard constraints need structured filtering.

A reliable path looks like this:

intent parsing
  -> category and market filters
  -> lexical retrieval for identifiers and exact terms
  -> semantic retrieval for descriptive fit
  -> compatibility graph traversal
  -> live price, inventory and ETA
  -> reranking
  -> a small candidate set for the language model

The order matters. If "must fit a 2019 machine" is a hard constraint, semantic similarity cannot compensate for failed compatibility. If the budget is EUR 150, a beautiful EUR 220 match should not outrank an eligible product unless the user asked to see alternatives.

Log exclusion reasons. An empty result should explain whether products were absent, attributes were unknown, inventory was stale, delivery failed or a policy prevented release. Those reasons tell catalog teams what to fix.

Publish executable capabilities

Finding a product does not reveal what an agent may do with it. A merchant might support search, price lookup and checkout handoff but not autonomous payment. Another may expose carts, returns and order tracking. Some actions require customer presence or approval.

Publish a versioned capability description:

{
  "merchant_id": "merchant:example-tools",
  "markets": ["DE", "AT"],
  "actions": {
    "catalog.search": { "available": true },
    "inventory.check": { "available": true, "live": true },
    "cart.create": { "available": true },
    "checkout.create": { "available": true, "handoff": "merchant" },
    "refund.request": { "available": false }
  },
  "protocol_bindings": ["ucp", "mcp", "https"],
  "version": "2026-08-11.1"
}

Capability discovery should be machine-verifiable against the endpoint. A manifest that claims inventory.check while the tool fails for every market is worse than no claim. Test sample calls, record schema versions and expire attestations after material connector changes.

Measure the agent funnel

Page views and click-through rates miss agent-mediated selection. Instrument a funnel that records:

eligible -> retrieved -> considered -> shortlisted
-> live-state checked -> offer requested -> selected -> transacted

Record rejection reasons at each boundary. Examples include missing_gtin, unknown_compatibility, variant_unavailable, price_expired, delivery_miss, capability_failed and policy_denied.

Do not infer a buyer's private prompt from these events or collect it by default. Merchant analytics can work with product IDs, normalized intent categories, constraint outcomes and transaction references. If data will train a model across merchants, obtain explicit rights and apply purpose limitation, isolation and privacy controls.

Test the unpleasant cases

An agent-readiness test suite should include:

  • two variants with the same title but different safety certification;
  • a feed price that differs from checkout;
  • a product marked in stock with no deliverable inventory for the buyer's postcode;
  • a valid product page whose JSON-LD points to the family rather than selected variant;
  • duplicate SKUs across markets;
  • dimensions with missing units;
  • a promotion that expired while the item remained cached;
  • a compatibility field supplied only in an image;
  • a capability manifest that advertises an unavailable action;
  • a cart call repeated after a timeout.

The pass condition is not "the model found something." It is that hard constraints remain hard, unknown facts stay unknown and live facts come from the system that owns them.

Implementation checklist

  • Create a canonical identity map for products and variants.
  • Preserve source IDs, versions and field provenance.
  • Normalize category-specific attributes and units.
  • Represent unknown, false and not-applicable values separately.
  • Publish structured product and offer data on pages and feeds.
  • Keep price, stock, promotions and ETA in authoritative runtime APIs.
  • Validate consistency across feed, page, API and checkout.
  • Combine structured, lexical, semantic and compatibility retrieval.
  • Give hard constraints precedence over model relevance scores.
  • Publish versioned commerce capabilities and protocol bindings.
  • Test claimed capabilities against live endpoints.
  • Add idempotency to carts, reservations and checkout creation.
  • Instrument agent consideration and rejection reasons.
  • Keep sensitive prompts and customer data out of merchant analytics by default.

Intelliger's current boundary

Intelliger's target Agentic Commerce Platform includes merchant connectors, a canonical Commerce Graph, catalog indexing, a Merchant Agent Runtime, capability verification and an Agent Search Console. The proposed readiness audit would detect stale or ambiguous product data, broken capabilities and lost-selection reasons.

Those commerce services are a target architecture, not current production features. The implemented OATI developer preview covers trust objects, schemas, canonical signing, deterministic mandate evaluation, discovery records and a paid-API commerce sandbox. The broader catalog, merchant-agent and Search Console product family remains on the roadmap, and OATI still awaits independent protocol and implementation review.

Merchants can act before that platform exists. Make product identity stable. Publish typed attributes. Verify volatile state at runtime. Expose honest capabilities. Then measure where agents exclude the product. That work improves every agent surface because it fixes the underlying commerce contract rather than tuning one chatbot.

The next engineering step is the large-catalog ecommerce product search architecture. Teams that already have reliable retrieval can use the AI search optimization measurement framework to diagnose why agents consider, reject or select a product.