Claude Commerce Agents: What Your Product Catalog Must Provide

Anthropic can provide the agent framework. A retailer still owns the catalog, inventory, pricing, policies, and operational controls the agent acts against. That distinction is the most important fact in planning a Claude Commerce Agents integration.

The hard enterprise layer is not producing another fluent conversation. It is turning fragmented supplier, PIM, ERP, commerce, and policy data into product truth that an agent can read and act on without guessing:

identify the product → assemble the right facts → validate them → expose them to the agent → control what can happen → learn from the outcome

Anthropic’s reference implementation separates buyer-facing shopping work from seller-facing merchant work. Its engineering guidance also recommends connecting tools to existing core systems and business logic instead of recreating that logic inside the model. The resulting architectural question is concrete: what contract must the product-data layer satisfy before Claude is connected to it?

Two agents, one operational product layer

A shopping workflow can be reduced to:

intent → search → product → variant → availability → cart

A merchant workflow can be reduced to:

sales → catalog → inventory → pricing → promotion

The model can reason across these stages. It cannot make an unresolved product identity or a six-day-old inventory value become true.

The catalog contract behind a shopping agent

1. Resolve the sellable entity

A product family, model, color-size variant, supplier offer, case pack, and individual unit are not interchangeable. The catalog interface should return stable identifiers and an explicit hierarchy: canonical product, variant, sellable SKU, offer, and packaging level.

Matching needs more than title similarity. Manufacturer and MPN, GTIN where present, normalized variant-defining attributes, and contradiction checks should support the identity decision. Otherwise the agent can find the right family and still add the wrong item.

2. Return decision facts, not a wall of prose

An agent needs typed values for the constraints buyers use: dimensions and units, material, capacity, voltage, compatibility, certification, pack quantity, and intended use. Descriptions remain helpful, but they should not be the only place a critical restriction lives.

Each value should carry its meaning. 12 is unsafe without a field, unit, packaging level, and product identity. Controlled vocabularies and normalized units make filtering reproducible rather than dependent on repeated interpretation.

3. Make relationships explicit

Compatibility, substitutions, supersessions, bundles, and required accessories are graph-shaped facts. A keyword search cannot reliably determine that an adapter is mandatory, two parts fit the same assembly, or a discontinued item has an approved successor. Store the relationship type, direction, conditions, and evidence.

4. Separate durable facts from live offer state

Material and rated voltage change differently from inventory and customer price. The interface should expose timestamps, effective periods, market or location scope, and source authority. Live price, stock, lead time, and promotion eligibility may require calls to transactional systems rather than cached catalog fields.

The contract behind a merchant agent

A merchant agent sees the same entities through an operational lens. It may identify low-stock items, propose a price adjustment, select promotion candidates, or flag a stale listing. To do that safely, it needs:

• sales, inventory, price, cost, and campaign measures joined to the correct product and variant;
• effective dates, currency, tax treatment, location, customer segment, and unit of measure;
• explicit policy rules for margin floors, restricted products, channel eligibility, and approvals;
• a distinction between an observation, a recommendation, an approved change, and an executed write;
• before-and-after values, evidence, actor, reason, and reversal data for every change.

Staging writes until approval is not merely a user-interface pattern. It is a data contract. A proposed action needs an idempotency key, expected current state, permission scope, validation result, approver, and audit record before it can safely become a mutation.

The product-data execution layer

The right architecture does not ask the model to replace the PIM, ERP, inventory service, or policy engine. It gives agent tools a governed layer between messy sources and actions.

1. 1
   Identify

   Resolve incoming supplier and channel records to a canonical product, family, variant, SKU, offer, and packaging level.

2. 2
   Assemble

   Join authoritative specifications, relationships, current commercial state, and applicable policies without flattening their scope.

3. 3
   Validate

   Apply schema, unit, range, vocabulary, cross-field, source-authority, and freshness rules. Preserve conflicts instead of silently selecting a convenient value.

4. 4
   Expose

   Return compact, typed tool responses with identifiers, timestamps, evidence, and uncertainty—not raw source-system noise.

5. 5
   Control

   Enforce permissions and approval policies outside the prompt. Separate read, propose, approve, execute, and reverse capabilities.

6. 6
   Learn

   Capture failed retrievals, rejected proposals, corrections, returns, substitutions, and customer outcomes as signals for catalog improvement.

This is commerce-agent catalog infrastructure: the product identity, attributes, evidence, and freshness layer behind agent decisions, plus the controls that govern agent actions.

What to measure before connecting production actions

Do not declare readiness because a demo answered ten happy-path prompts. Measure entity resolution accuracy, decision-attribute completeness, relationship coverage, stale-value rate, source-conflict rate, unsupported-answer rate, tool error rate, approval rejection rate, and harmful-action escape rate.

Evaluate buyer and merchant scenarios against the same representative product set. When the shopping agent selects a variant, verify that the merchant view retrieves the same canonical entity and operational facts. This catches the integration gaps that isolated conversational tests miss.

Use the catalog preparation guide to define the contract, then run the 20-case commerce-agent catalog test before enabling production access.

Primary sources

• Anthropic: Claude for Commerce — the product context for deploying Claude across commerce workflows.
• Anthropic engineering: building agents for the agentic commerce era — architecture guidance for connecting agents to existing company systems and logic.
• Anthropic’s commerce agents repository — the reference implementation, runnable retail examples, and integration materials.
• Anthropic announcement: commerce agents — the introduction to the shopping-agent and merchant-agent pattern.

FAQ