A commerce agent can search a catalog without proving product discovery.

DIRECT ANSWER

Known-catalog search and open product discovery answer different questions.

A first-party shopping agent begins after a business has connected its own catalog. It can translate a customer's need, search those records, compare returned products, resolve options and prepare a cart action.

An external shopping assistant has an earlier problem. It must decide which merchants, pages and products to retrieve from public websites, feeds, platform catalogs and outside sources before it can build a candidate set.

A hit from a connected catalog shows that one backend returned a product for one query. It does not show that an outside AI can naturally discover the product.

This is not a criticism of commerce agents. It is a boundary between two useful systems—and two kinds of evidence merchants should not confuse.

THE REFERENCE ARCHITECTURE

What Anthropic's example actually contains

Anthropic's commerce-agents repository describes two roles over systems a business controls.

• The customer-facing shopping agent searches and compares products, resolves choices, stages cart actions and answers store-policy or order questions.
• The staff-facing merchant agent reads business data and proposes listing, inventory, pricing, promotion or campaign changes for approval.

The adopter supplies the real integration. A StorefrontBackend maps the shopping tools to catalog, cart, customer, order and policy services. The repository says no MCP connectors ship, so this is not a ready-made Shopify connector.

The examples are deliberately bounded: fictional products and brands, checkout handoff rather than a card charge, and staged merchant changes rather than silent live mutations. Those limits matter when translating a reference design into commercial claims.

THE TRANSLATION LAYER

Customers describe needs. Catalogs describe inventory.

The repository's Search Discovery Skill gives the shopping agent an unusually clear instruction:

“Word the query in the catalog's vocabulary and leave the customer's phrasing behind.”

The skill tells the agent to extract constraints such as budget, intended use, size and dealbreakers; move explicit constraints into filters; and compare finalists on the dimensions the customer raised. The full instruction is visible in the pinned Search Discovery Skill.

This exposes a fundamental commerce problem. A shopper may ask for “a compact gift for a frequent traveler,” while inventory is organized by product type, dimensions, material and variant. Someone—or some system—must bridge the language of the need to the language of the catalog.

A merchant-controlled agent can perform that translation inside its own search experience. External systems may have neither the same catalog access nor the same vocabulary. They need enough consistent evidence to make the bridge from what the buyer wants to what the product is.

MC LAB INTERPRETATION

This resembles the Category Bridge—but operates at a different layer.

MC Lab's Category Bridge traces a path from a natural buyer need to an ordinary product category, the attributes that matter in that category, the proof supporting those attributes, and finally the SKU.

The similarity is real: both models recognize that buyer language rarely matches catalog taxonomy exactly. The difference is control.

• Anthropic's skill assumes the relevant inventory is already available through a connected backend and the agent is allowed to rewrite the query.
• MC Lab tests whether public and platform-visible evidence is sufficient for systems the merchant does not control to retrieve the product, associate it with the right category and compare it accurately.

Anthropic does not use or validate MC Lab's Category Bridge. The parallel is MC Lab's interpretation of the same translation problem appearing at a different layer of the shopping system.

PRODUCT RESOLUTION

“Found” can still be one step away from purchasable.

The reference model separates a plain product, a family of options and a purchasable variant. Search normally returns the family; detail lookup reveals the available combinations; the cart requires a resolved variant with its own identifier, price, stock and option values. The distinction is encoded in the repository's product types and backend guidance.

That creates two separate commercial states:

1. the product family entered the candidate set; and
2. a purchasable option with the required size, color, price, stock and market availability was correctly resolved.

This is relevant to Shopify operators, but Anthropic's abstract family-and-variant record should not be treated as a one-to-one representation of Shopify's native model. The broader lesson is that discovery and purchase readiness need separate checks.

EVIDENCE AND CONTROL

Trust is enforced at the tool boundary, not only in the prompt.

The repository also offers a useful design lesson for evidence integrity. Third-party text is fenced and labeled before the model reads it. Cart writes accept product identifiers previously returned in the session. Merchant changes are proposed, previewed, approved and then applied, with guardrails checked again at application.

These controls preserve a traceable path between a record, an agent decision and a consequential action. The repository's safety documentation is equally clear about the boundary: the adopter still owns authentication, authorization, payment, fraud controls, business rules and production guardrail values.

For product discovery, the parallel is simple. A credible result should preserve the question, answer, sources, time, model and session conditions that produced it. Without that record, a claim that a product was “found by AI” is difficult to interpret or reproduce.

MERCHANT CHECK

Before assuming an agent solves discovery, test these five questions.

1. 1

   Where is the agent searching? A private catalog, a platform feed, the public web or some combination?

2. 2

   What was already connected? Catalog access is an input to the test, not proof of external discovery.

3. 3

   Was the product merely retrieved? Record candidate-set inclusion, comparison accuracy and final ordering separately.

4. 4

   Was a purchasable variant resolved? Family-level discovery can hide missing option, stock, price or market details.

5. 5

   Does the landing page support the decision? The PDP still needs to make the relevant fit, facts and next action clear.

These questions turn a broad “AI visibility” claim into a product-level diagnosis. They also reveal whether the next useful action belongs in catalog data, public product evidence, outside authority sources or the PDP itself.

THE DIAGNOSTIC LAYER

Where MC Lab fits

MC Lab does not build customer-facing shopping agents or back-office merchant agents. Product Candidate-Set Diagnostic tests the earlier and cross-surface problem for one real Shopify product:

• Can natural, unbranded buyer questions retrieve usable product evidence?
• Is the product associated with the right category and admitted to a plausible candidate set?
• Are the decisive facts represented accurately during comparison?
• Does a recommended product land on a PDP that supports the decision?

The work follows Test → Diagnose → Fix → Retest. A captured answer is evidence under recorded conditions, not a stable ranking or a guarantee of future inclusion, recommendation, traffic or sales.

For a deeper explanation of the stages, read Candidate-set inclusion is not the same as ranking.