Claude commerce agents became generally available on 2 September 2026, and Anthropic put the whole blueprint out the same day.
A customer asks for a refund. The agent reads the order and works out that the refund is owed. It still can't pay the money out, because the write is executed by something the model doesn't control.
The refusal is the design. Anthropic built the blueprint so that the payout happens outside the model.
Three of the decisions inside that design are things you can check in a quote before you sign: who executes the write, how many agents there are, and when it's allowed to go live. None of them needs anyone to read code.
The agent works in your own shop, on your own catalogue
That refund happens inside an agent you build yourself, on your own catalogue. Claude commerce agents is Anthropic's name for it.
What Anthropic has published is a blueprint anyone can download. There are two agents in it. The shopping agent searches the catalogue, handles requests for several items, compares them, builds the cart and covers customer service in the same conversation. The merchant agent runs sales analytics, tracks inventory, recommends prices and drafts marketing campaigns.
Working implementations ship for four verticals: retail, travel, telecom and ticketing. It runs on the Messages API, the Agent SDK or Claude Managed Agents, which is in beta, and it deploys on the Claude API, Amazon Bedrock, Microsoft Foundry and Google Cloud Vertex AI. Wix says it had a working agent in fifteen minutes.
Generally available here means there's no waitlist and no access request. The code is out, and so are the patterns and the built-in guardrails published with it. For a Danish shop, the question now is who is going to build it, and what they have to be able to answer along the way.
It's the merchant agent that makes this relevant to companies that will never put an agent in front of their customers. Sales analytics, inventory and campaign drafts are internal work, and that half of the blueprint looks a lot more like what most people need first.
Then there are two things the announcement doesn't say.
This is a blueprint for building your own agent on your own catalogue, not agents that visit other people's shops.
Visa and Mastercard are named as "solutions partners", and that is the role the announcement gives them. An agentic payment rail would need its own announcement, with its own mechanics.
The measurements you can use
The announcement carries two numbers. Carts run up to 35 percent larger, and shoppers are 60 percent more likely to complete a purchase. Anthropic attributes both to retailers running shopping agents on Claude. It doesn't say how many retailers, over what period, or what they sell.
The guide has other numbers, and you can do something with those. Anthropic recommends 50 to 100 eval cases per user flow as a baseline, and model choice is decided by evaluation sweeps.
Two questions fall out of that, and you can ask both without any technical background. How many eval cases have you built per flow. And which models did you sweep, against which set.
A quote that can answer both was built by someone who measured. A usable answer sounds like a number and a set: this many cases per flow, run against these models, and here is what came out. If an answer keeps returning to how capable the model is, it hasn't been near a test set.
The model proposes and the harness executes
You probably came here with a question about personal data. There's an answer, and it's below. The blueprint is built around one more risk: the irreversible write.
Three examples, all from the guide's own list of what has to be executed by something other than the model. A price changed across a catalogue. An order placed against an identifier the model invented. A marketing campaign sent out.
It's the same class every time: an action that cannot be pulled back once it has happened. A clumsy sentence in a reply can be fixed in the next one. A price that has gone out across a thousand SKUs has to be rolled back by a person, and the customers have seen it in the meantime.
Anthropic puts the safeguard in the machinery itself. An approval surface that actually exists. IDs the server issues. Writes that queue. Those are properties of the system, and properties are something you can look for. An instruction in a prompt can be read aloud in a meeting. An approval surface has to be something someone can open and point at while you're standing there.
This piece is about looking at what somebody has already built. That is a different job, with different questions, from working out where the line sits when an agent runs unattended. I wrote about the line in Where the line sits for what Claude may do on its own.
Those three decisions sit on five properties of the system. You can check two of them yourself, with no developer at the table.
Is there a real approval surface. Anthropic is specific about it: a button in the operator's portal, a confirmation in the CLI. Ask to be shown it. A surface nobody can point at doesn't exist.
Can a customer see and delete what the agent has stored about them. Anthropic keeps long-term memory in a database outside the model, extracts it asynchronously so it adds no latency, and writes that users must be able to see and delete what is stored. That's also the answer to the personal data question above.
The other three need someone technical in the room with you. Each of them has something concrete to point at.
The server issues the IDs. The write tool accepts only IDs the server issued itself, so an invented identifier never reaches a write. What you ask to see is the tool's schema. There should be no free-text field for an ID.
Outside text is marked. Third-party content is sanitised and marked before the model sees it. Ask to see where that text comes in, and how it's marked as data.
Writes queue. They're serialised, so two writes can't be in progress on the same order at once. Ask what happens when two staff click in the same second.
A supplier should be able to say which of the three designs they tested
Three designs were built for this job, and Anthropic ran all three on its own commerce work. One agent with skills came out on top, ahead of the one-prompt design and the subagent design, where several subagents split the work between them.
Anthropic doesn't publish what the test measured. The testing is its own, on its own commerce work. The result is public, and it comes from the people who build the model.
So I think a supplier offering you several cooperating agents should be able to name the design they tried themselves, and what they measured.
You and the supplier can both use that comparison, and that's enough to change what the meeting is about.
The guide has one more number that makes the question concrete. Anthropic puts a skill in the system prompt when it's relevant to a third or more of the traffic. Ask what's in your system prompt, and why that. The answer tells you whether anyone looked at what your customers ask about, or whether everything just went in.
Somebody owns the agent, and the release calendar comes with them
Anthropic treats the agent as a single unit that ships as one piece, and that has three consequences you can ask about.
Ownership follows system ownership. The team that owns search also owns the search tool and the skill that uses it. That sounds obvious until someone has to say who owns the agent in a company of twenty people. Ask who that is in your own company, while the answer is still cheap.
CI runs before anything rolls out. Anthropic runs CI on the core traffic cases plus the neighbours of whatever just changed. Those are the same kind of eval cases as earlier.
The rollout starts small. Canary means the change goes to a small share of traffic first and widens if it behaves. It's the same idea as letting a new hire take the first ten calls with a colleague listening in, and it assumes someone actually listens to those first ten.
All three hang together in a way that's easy to miss. Ownership decides who watches the canary, and the eval cases decide what they watch for. Whether they have time at all is in the calendar. Drop one of the three and the other two cannot carry it alone.
And there are stretches where nobody touches it. Anthropic recommends freezing changes over peak periods. For a shop, they're usually the weeks that carry the year's revenue, and they're also the weeks when an agent that suddenly behaves differently costs the most.
Ask who, before December.
Trace one refund
Here's the refund this piece opened with, traced. Six steps.
- The customer asks for a refund.
- The agent reads the order and works out that the refund is owed.
- The tool is called against an ID the server issued.
- The proposal queues.
- A person or a policy approves it.
- The harness executes the write, and the refund is paid out.
Step five is the only place where something other than the model has to say yes. That's the approval surface I asked you to look for further up.
Now do the same with your most irreversible action. Pick one: a price change, a credit note or a campaign going out. Write the steps down, from the decision being made to the money or the goods moving, and mark the step where a person or a policy has to approve it.
Then name the surface. What is it called, who clicks, and where does the button live.
If you find no surface, that's your answer. That's the one to build first.
It's the kind of walkthrough I do when I start with a week-long audit of how a team actually works, before anything gets built. It sits under internal AI tools.
Sources
Anthropic: Building commerce agents with Claude (2 September 2026) →
Anthropic: A guide to the anatomy of effective commerce agents (2 September 2026) →
The blueprint on GitHub: anthropics/commerce-agents →
Who did this work
FAQ
Frequently asked questions
It's a Claude agent working in your own webshop, on your own catalogue. Anthropic's blueprint has two. A shopping agent searches the catalogue, handles requests for several items, compares them, builds the cart and covers customer service in the same conversation. A merchant agent runs sales analytics, tracks inventory, recommends prices and drafts campaigns.
Not in the design Anthropic recommends. The guide says order placement, payments, refunds, price changes and campaign launches all end in an action the harness controls, and the harness is a different system from the model.
The blueprint itself costs nothing. You pay for model usage. Anthropic publishes no price for the implementation, so the bill is your supplier's hours plus what the model costs to run.
Anthropic compared three designs and writes that one agent with skills outperformed both the one-prompt design and the subagent design. No benchmark and no figures have been published. Ask your supplier which of the three they tested, and what they measured.
The blueprint is free to download. It's open on GitHub under anthropics/commerce-agents, along with the patterns and the built-in guardrails, and the repository's licence is where you get the final answer on what you may do with the code in your own shop.
The blueprint deploys on the Claude API, Amazon Bedrock, Microsoft Foundry and Google Cloud Vertex AI. Where the data sits depends on the platform you choose. The announcement takes no position on data location, so that question belongs with the platform.
Ask to be shown the approval surface, the button or the confirmation where a person or a policy says yes to an irreversible action. Ask to see that a customer can see and delete what the agent has stored. And ask to see the write tool's schema, where there should be no free-text field for an ID.
This announcement is about the agent a company builds on its own catalogue. Agents that visit other people's shops are a separate subject, and neither the announcement nor the guide addresses it.
