Anthropic’s commerce agent blueprint: two reference agents you can run in an afternoon

On September 2, 2026 Anthropic published a commerce agent blueprint: two reference implementations at github.com/anthropics/commerce-agents, with live demos for retail, travel, telecom, and ticketing.

This is a starting codebase, not a product. That is what makes it worth an afternoon.

The two agents

The shopping agent talks to customers. It searches a catalog, assembles multi-item purchases, and completes transactions through a conversation. Along the way it does personalised recommendations, in-conversation product comparison, cart management, and customer service — answering questions about orders and policies without a handoff.

The merchant agent talks to the person running the store. Sales analytics, inventory tracking, pricing recommendations, and drafted marketing campaigns. Note the word drafted: the blueprint's stated design is that a person approves before anything goes live. That is the right default and you should keep it.

What it runs on

The blueprint is deliberately portable across the deployment surfaces:

• Claude API
• Amazon Bedrock
• Microsoft Foundry
• Google Cloud Vertex AI

And across three implementation levels:

• Messages API — you own the loop
• Agent SDK — the loop is handled
• Managed Agents (beta) — the sandbox and harness are handled too

The repository ships integration points for catalog search, cart management, checkout, customer preferences, and order history, plus a Claude Code plugin to accelerate customisation. Developers report local deployment in well under an hour, which matches what a reference implementation with mocked integration points should take.

Start at the Messages API level even if you intend to end up on Managed Agents. The tool loop is where you will learn what your catalog actually returns, and that is the part no blueprint can hand you. Tool use, in depth covers the mechanics.

The numbers, and how to read them

Anthropic reports that enterprise customers saw carts up to 35% larger and shoppers 60% more likely to complete a purchase.

Take these as a ceiling from selected customers, not an expected value. Two reasons. First, "up to" is doing real work in that sentence. Second, these are Anthropic's figures from customers Anthropic chose to cite — no independent study, no baseline description, no sample size.

That does not make them useless. A 35% cart lift is a large enough claim that it tells you the category is worth testing, and the completion rate figure is the more interesting of the two: it suggests the win comes from removing friction in the decision, not from upselling. But if you put either number in a business case, label it as vendor-reported. Measuring AI ROI covers how to set up a measurement you can actually defend.

The one guardrail that decides everything

The blueprint constrains prices and products to actual catalog data, and avoids manipulative upsell patterns.

The first half of that is not a nice-to-have. It is the difference between a shippable system and a legal problem.

A model that generates a price is a model that can generate a wrong price, and a wrong price quoted to a customer in a conversation is, depending on your jurisdiction, an offer. Same for stock availability, same for delivery dates, same for return windows. The failure mode is not "the agent said something slightly off" — it is "the agent committed us to something we cannot honour, in writing, at scale."

So the architectural rule: every number the customer sees comes from a tool call, never from the model's own text. Price, stock, ship date, policy terms. If your catalog tool cannot answer, the agent says it cannot answer. That constraint feels restrictive until the first time it saves you.

Preventing hallucination in Claude covers the general technique; in commerce it stops being a quality concern and becomes a compliance one.

The second half — no manipulative upsell patterns — is a commercial judgement that happens to also be a regulatory one. Dark patterns in checkout flows are already enforced against in several jurisdictions. An agent that improvises them is worse than a UI that contains them, because you cannot point to the code that produced the behaviour.

What the blueprint does not give you

This is the part to be clear-eyed about before you scope the work. A reference implementation covers the conversational layer. Commerce is mostly not the conversational layer.

Not in the box:

• Payment authorisation. Tokenisation, 3DS, PSP integration, and the entire PCI question
• Fraud. Velocity checks, device fingerprinting, chargeback handling
• Tax. Jurisdiction, nexus, digital goods rules
• Inventory reservation. Two agents assembling carts against the same last unit is a race condition, and a conversation is a slow transaction
• Returns and refunds. The half of commerce that generates most of the support load
• Order state. What happens when the agent's view of an order and the warehouse's view disagree

Every one of those is a real system you either have or do not. The blueprint assumes you have them and gives you integration points. That is the correct design and it means the honest scoping question is not "how long to build the agent" but "how good are the interfaces to the six systems above."

For the operational side of running this once it exists: Deploying a Claude app to production, Monitoring your Claude app, and Error handling in production.

Where the agent will actually break

From the failure patterns that show up in every agent that touches a transactional system:

• Ambiguous product identity. "The blue one" when there are three blue variants. The agent picks. It picks wrong roughly as often as a human would with the same information, which is to say sometimes, which is to say you need a confirmation step on the specific SKU before checkout
• Stale catalog reads. The agent read stock at turn three and checks out at turn eleven. Re-read at checkout, always
• Multi-item carts with dependent constraints. Shipping thresholds, bundle discounts, items that cannot ship together. The agent will assemble a cart that your checkout rejects, and the recovery conversation is the worst part of the experience
• The customer changing their mind mid-cart. Cheap to handle if cart state lives in your system and the agent reads it. Expensive if cart state lives in the conversation

When agents break and Multi-agent failure handling cover the general recovery patterns.

Try this today — the catalog honesty test

Before you write any agent code, run this. It takes 30 minutes and it tells you whether the project is viable.

Step 1. Take your five most-asked customer product questions. Real ones, from support tickets, not invented ones.

Step 2. For each, answer this: can a single tool call against a system we already have return the complete answer?

Step 3. Sort them into three piles.

• Yes, one call. These are what your agent can do on day one.
• Yes, but three or four calls across different systems. These are doable and they are where the integration work is. Estimate them honestly.
• No, the data does not exist anywhere queryable. These are what the agent will hallucinate about, and no prompt fixes it. Either build the data or scope the agent to refuse the question explicitly.

Step 4. Count the third pile. If it is more than one of the five, your first project is not a commerce agent — it is the catalog work underneath it. That is a less exciting answer and it is the one that makes the agent work six months later.

Then clone the repo and run the shopping demo against mocked data, so you have seen the interaction shape before you commit to the integration.

Related: Claude Managed Agents · Tool use, in depth · Preventing hallucination in Claude · Deploying a Claude app to production · How to evaluate your agents · When agents break