A reference blueprint makes commerce workflows concrete
On September 2, 2026, Anthropic published a blueprint for building commerce agents. The company described reference implementations for a shopping agent and a merchant agent, with examples for retail, travel, telecom, and ticketing. The shopping flow can search a catalog, compare products, answer certain service questions, assemble a cart, and hand it to checkout. The design leaves payment to the merchant’s existing checkout or a payment provider. A separate merchant workflow can analyze store information and draft changes, with a person approving a recommendation before it goes live.
That separation is the most useful design clue for an owner: conversational discovery does not have to take over transaction authority. An assistant may help a customer find the right items while the existing payment system remains responsible for price confirmation, address, taxes, fraud checks, and the final charge.
Start with the records that determine a real offer
A commerce assistant is only as dependable as the product and policy data it can consult. Before connecting a catalog, identify the authoritative source for product names, current price, stock status, shipping limits, return rules, and eligibility. Decide what the agent should do when two systems disagree or when a requested detail is absent. The safe fallback is to explain the gap or hand off to a person, not fill it with a plausible answer.
Keep the first release away from inventory or promotion changes. Have the agent search and compare, then assemble a cart that the customer reviews in the normal checkout. For merchant-side recommendations, allow analysis and drafts but require a named operator to approve changes to price, availability, or campaign terms. Log the source records behind the recommendation so the operator can inspect them.
Test failure cases before adding autonomy
Use a small, representative catalog and test ordinary questions plus edge cases: a discontinued item, a price changed moments earlier, an out-of-stock product, conflicting return policies, and a customer request that needs an exception. Verify that the cart contains only valid items and that checkout recalculates the final amount. Measure whether staff can understand the recommendation and whether it cites the relevant sales or inventory records.
An exception is a business that cannot safely expose even a limited catalog or customer service data to the proposed integration. In that case, keep the prototype in a synthetic dataset and validate the tool boundaries first. Also check the blueprint’s actual dependencies and hosting options; an example repository is a starting point, not a production security review or a guarantee that it fits your store.
The decision is where to keep the human decision
The blueprint does not remove the owner’s responsibility for pricing, payments, fulfillment, or customer promises. It offers a structured way to prototype a conversational shopping and merchant experience. A practical next step is to map one low-risk journey, mark which system owns each fact, and decide where customer confirmation and staff approval must remain. If the boundary is clear, a small demo can show whether the conversation makes buying easier without changing how money moves.