Claude Commerce Agents is the open blueprint Anthropic released on 2 September 2026: a working shopping agent and a working merchant agent, forkable, Apache 2.0. Almost every write up since has covered the storefront half. This article covers the half the blueprint deliberately leaves to you, which is what your ERP, your CRM and your permission model actually have to provide before either agent can answer a real customer question.
If your commerce runs on a CRM, an ERP and a warehouse system that disagree with each other on a good day, this is the work that decides whether a Claude Commerce Agents project ships or stalls. What follows is the requirement list we walk clients through, in the order it tends to bite.
There’s a specific moment in these projects that I’ve come to expect.
You demo the agent to the client. It’s fast, it understands a messy question, it builds a sensible cart, everyone in the room is pleased. Then somebody from operations asks what happens when a customer asks about an order that was partially returned, and the room goes quiet, because the answer is that nobody has decided which of the three systems holding pieces of that order is allowed to be the one the agent believes.
That question has nothing to do with the AI. It’s an integration question, and it was there before anyone mentioned agents.
Almost all the coverage in the days since has been about the storefront: what the agent can do for a shopper, what it means for product data, how it fits Shopify. Reasonable, as far as it goes. But it skips the part that decides whether the thing works, which is what happens behind the tool call.
What Anthropic released, briefly
Claude Commerce Agents is an Apache 2.0 reference blueprint, published 2 September 2026. Two agents. The shopping agent lives in your app or storefront and handles search, comparison, multi-item requests, cart building, and customer-service questions like order status and returns. The merchant agent faces your own staff and covers sales analysis, inventory monitoring, pricing and promotion recommendations, and campaign drafting.
Four runnable examples ship with it (retail, travel, telecom and ticketing) plus a Claude Code plugin that will scaffold an agent against your systems or review one you’ve already built.
The line I’d point any client to isn’t on the announcement page, though. It’s at the bottom of the repository README, where Anthropic states plainly that this is a reference implementation, that it is not maintained, and that it does not accept contributions.
That’s not a criticism. It’s a scoping fact, and it’s the most important one in the whole release. You are not adopting a product with a roadmap. You are forking a set of patterns that become your code, your maintenance burden and your security surface from the moment you clone it. Budget accordingly, and don’t let anyone put “Anthropic supports it” in a slide deck.
The blueprint deliberately stops at your systems
Here’s the part I think most readers have glossed over.
The repository ships no MCP connectors. If you have been following the agentic CRM architecture debate, this is the same boundary we described in What Is Salesforce Headless 360. None. Both agents reach the outside world through two Python interfaces, StorefrontBackend on the shopping side and MerchantBackend on the merchant side. Every method on those interfaces is a function your team writes, calling your service, server-side, with a credential your host application holds for the session. The model never sees the credential. It only sees what your method returns.
That design decision carries a commercial consequence that is easy to read past: every capability the agent appears to have is a method your team has to build, own and maintain.
The agent needs, at minimum: catalog search, product detail, cart operations, order lookup, returns and policy answers, customer preferences, sales analytics, inventory positions, pricing rules, promotion state and campaign data. On a mid-market stack, look at where those actually live. Order history is in the CRM. Inventory and cost are in the ERP. Contract pricing is in the ERP or a CPQ layer. Campaign state is in the marketing platform. Product attributes are wherever your PIM is, assuming you have one, which about half the businesses we talk to don’t.
Almost none of it is in the storefront.
So the honest name for a commerce agent project is systems integration project with a conversational front end. That’s a different budget line, a different team and a different risk register than “add an AI assistant to the website,” and if the proposal your client is looking at doesn’t say so, the proposal is wrong.
The ERP and CRM readiness checklist for Claude Commerce Agents
Before any of the agent code matters, twelve things have to be true of your systems. Nine of the twelve are data and process questions that have nothing to do with AI. This is the list we work through with a client before we quote anything.
What your CRM has to give it
- Session identity resolved by your host application. The agent inherits an authenticated shopper; it never decides who the user is. Guest checkout, duplicate email addresses on one account and B2B users buying for several ship-to locations all have to resolve to one answer.
- Order and returns state readable live. Not last night’s extract. Partial returns, exchanges and in-flight refunds included, because those are the questions customers actually ask.
- Account and contract pricing resolvable per customer. If the agent can only see list price, it will quote list price to a customer on a negotiated rate.
- Memory scoped, with a written retention rule. What the agent is allowed to remember between sessions, for how long, and how a customer gets it deleted.
What your ERP has to give it
- Revenue, margin and returns defined the same way everywhere. Two systems that disagree on margin will produce an agent that confidently reports the wrong number.
- On-hand and committed stock, current. Committed matters as much as on-hand; an agent that only sees on-hand will promise stock that is already allocated.
- Cost data to reason against, and price floors it cannot cross. The floor belongs in your system, enforced server-side, not in a prompt.
- Product attributes as structured fields. Size, material, compatibility and voltage as fields, not buried in a paragraph of marketing prose.
- A campaign calendar queryable by product. Otherwise the agent will recommend a discount on something already promoted.
What has to be true across both
- Every merchant write staged for human approval. The blueprint is built this way; keep it that way when you extend it.
- Credentials held server-side in the host application. The agent calls your backend methods, it does not hold keys to your ERP.
- A test set of real edge cases before pilot. Partial returns, price exceptions, shared logins, discontinued SKUs. This is the part that gets cut, and it is the part that decides whether the pilot survives.
If you cannot tick nine of these twelve today, the honest answer is that the first phase of a Claude Commerce Agents project is a data and integration project, not an AI project.
What the Claude shopping agent wants from your CRM
Four things. Most mid-market CRMs supply two of them cleanly and struggle with the other two.
Identity, resolved per session. Before the agent can say anything account-specific it has to know who’s asking. Your host application authenticates the shopper and the agent inherits that context; it doesn’t get to decide who the user is. Straightforward in principle, and in practice this is where guest checkout, multiple email addresses on one account, and B2B users buying on behalf of three different ship-to locations all come and find you.
Order and returns state. Anthropic’s shopping agent is designed to answer service questions inside the same conversation as shopping ones (where the order is, how to return something, what the refund policy actually says) rather than dumping the customer on a support page. That’s genuinely the best feature in the release, and it’s also the one that exposes your data model fastest. Full orders are easy. Partial returns, split shipments, exchanges against a replacement SKU, and anything involving a third-party fulfilment partner are where teams discover their order record was never designed to answer a question in natural language.
Account and contract pricing. The repository’s guidance is that the price quoted is the session account’s price. If you sell B2B at all, that single sentence routes your pricing call out of the catalog and into the ERP or CPQ system, and it has to return within a latency budget a person will tolerate mid-conversation.
Memory that survives the session, and doesn’t become a liability. The agent is designed to remember what a customer tells it. Anthropic’s engineering guide treats this as a data-handling problem rather than a storage one, and the recommendations are worth reading in full, but the four that matter: decide up front which categories of fact you’re willing to hold and enforce that with a validator on the write path rather than an instruction in the prompt; give users a way to see, correct and delete what’s stored; wire that deletion into your existing account-deletion and data-request flows; and set a retention period, because a preference from two years ago is probably wrong now.
There’s a fifth recommendation in there that I’d have missed if I hadn’t read the guide carefully, and it applies to the merchant side. Merchant logins get shared between operators constantly: one account, four people on the floor. So memory should be keyed to the person, not the login, and reads have to respect that person’s permissions. A store manager’s agent shouldn’t be able to recall something a district manager said. That’s a small design decision that becomes an expensive retrofit.
What the Claude merchant agent wants from your ERP
The merchant agent’s capabilities ship as five named skills: performance-insights, catalog-listings, inventory-operations, pricing-promotions and marketing-campaigns. Each maps onto a back-office system, and each has a precondition that isn’t about AI at all.
| Capability | System that answers | What has to be true |
|---|---|---|
| Sales performance questions | ERP or warehouse | Revenue, margin and returns defined the same way everywhere |
| Inventory alerts | ERP or WMS | On-hand and committed stock, current, not last night’s extract |
| Pricing and promotion recommendations | ERP, CPQ or pricing engine | Cost data to reason against and floors it cannot cross |
| Campaign drafting | Marketing platform | Campaign calendar queryable by product |
| Listing maintenance | PIM or catalog | Attributes as structured fields, not prose |
Now the design detail that has the biggest operational consequence, and I don’t think anyone has written about it yet.
No merchant write goes live directly in the reference implementation. Every write produces a staged change with a server-generated ID, and applying it requires that ID to have been approved through a real surface, a button in the operator’s portal, a confirmation in the CLI. Fine, that’s the sensible pattern. But the guardrails are re-checked at apply time, against the limits in force then, not the limits that applied when the change was staged.
Think about what that requires of your ERP. Not “can you produce a report.” It’s: can you answer what is true right now, on demand, in the second the approver clicks the button. If your inventory or pricing data lands in the reporting layer on a nightly batch, you cannot support that, and closing the gap is your first sprint, before a single prompt gets written.
I’d rate that as the most common blocker we’ll see in mid-market Odoo and Dynamics estates over the next year. It isn’t glamorous and it doesn’t demo well, but it’s the thing.
The failure nobody plans for
This one I’d put money on.
The shopping agent reads availability from the storefront. The merchant agent reads availability from the ERP. A customer is told an item is in stock. The operations team, looking at the same SKU, sees that stock committed against a wholesale order. Both agents are behaving correctly. They’re reading two systems that have never agreed on what “available” means, and nobody noticed, because until now no two consumers of that number were ever quoted in the same conversation.
The agent didn’t create that contradiction. It made it legible.
That’s why I’d argue hard against building both agents at once, even when the budget exists and the client is enthusiastic. Two conversational surfaces reading through separate data logic will contradict each other in front of a customer within weeks, and when they do, the blame lands on “the AI” rather than on a definition mismatch that predates it by five years. The project gets cancelled for the wrong reason.
Before funding both, five things need one owner and one definition each: product and catalog data, customer identity, commercial rules, action authority, and how you’ll evaluate correctness. If your team can’t name the system of record for all five inside an hour, that reconciliation is the project. The agent comes after.
A trap for integrators specifically
There’s a warning in Anthropic’s engineering guide that I think is aimed squarely at people who do the kind of work we do, and it’s easy to walk straight into.
The rule is that the agent’s tools should call the systems you already run, not reimplement their logic. Your search ranking, your promotion engine, your inventory allocation, those encode years of tuning and see signals a model never will. The tool is where their logic ends and the model’s judgment starts. When the agent calls search_products, results should arrive already ranked; the agent’s job is deciding which of them serve the goal and how to present them.
Where it goes wrong is subtle. The guide describes an availability check that calls the catalog for the SKU, then the inventory service per store, then fulfilment for cutoffs, then applies substitution rules and pickup eligibility, all inside the tool’s own code. Every one of those steps looks reasonable while you’re writing it. What you’ve actually built is a tool carrying domain knowledge that belongs upstream, which will drift out of correctness the moment the business changes a rule, and which nobody will think to update because it doesn’t look like a business system.
The fix is boring and correct: one backend endpoint that answers the question, called by one agent tool.
I’m flagging this because the pressure to stitch missing logic into the tool layer is enormous on integration projects. It’s always the fastest path in the sprint you’re in. It’s also how you end up owning a shadow pricing engine written in a tool wrapper.
A related, smaller point from the same guide: tool results are context, so return the fields the model reasons with and drop the rest. Image URLs on every search row are named as the usual offender. That’s a token cost on every single turn for data the model does nothing with.
Claude Commerce Agents, Agentforce, Claudeforce
Clients ask this as though it’s a choice between three products. It mostly isn’t, and framing it that way leads to bad scoping.
Agentforce is native. Agents run inside Salesforce, on Salesforce data, under Salesforce permissions and governance, and the readiness questions there are different again, which we set out in our guide to choosing an Agentforce implementation partner. If your commerce operation genuinely lives in Salesforce Commerce Cloud end to end, most of the integration work described in this article is already done for you, and the trade is that you work within that ecosystem’s boundaries and its pricing model.
Claudeforce, the expanded Salesforce, Anthropic partnership announced in August 2026, is a different shape again: Claude supplies reasoning, Salesforce supplies the business context and governs the action. We wrote about the distinction separately in Claudeforce vs Agentforce, and it’s worth reading before you assume one replaces the other, because they don’t.
Claude Commerce Agents sits at the far end of that spectrum. You get the harness, the prompts, the skills, the tool contracts and the safety gates; you supply every connection to every system. Maximum control, maximum integration work, no platform lock-in. The same code runs on the Claude API, Amazon Bedrock, Microsoft Foundry or Google Cloud Vertex AI, which matters more than it sounds if you have a cloud commitment or a data-residency requirement.
My honest read: if you’re Salesforce end-to-end, look hard at the native options first and only fork the blueprint if you hit a wall. If you’re running Odoo for ERP and Zoho for CRM behind a custom storefront, which describes a lot of the North American mid-market we work with, there is no native path, and the backend-interface model is genuinely the shorter route, not just the more flexible one.
Where the safety design actually is
Worth understanding before you promise a client this is safe, because the guarantees are real but specific.
Enforcement lives in the harness, in code, not in the prompt. Anthropic’s reasoning is that in commerce the failures are financial and often irreversible, and a prompt rule is one injection away from being skipped. Three mechanisms do most of the work:
Server-issued IDs only. The harness keeps a per-session record of every ID it has handed the model, and that record is the only key any write or render will accept. The cart takes only product IDs the server returned in this session. An ID that arrived any other way, hallucinated, pasted in by a user, planted inside a product review, is refused before your backend ever sees it.
Caps enforced on the resulting state. Limits are checked against what the state would be after the write, so a shopper saying “add two more” three times can’t stack past a per-customer cap, and cart writes within a session are serialised so parallel tool calls can’t combine to exceed it. Merchant changes are checked the same way against caps on price movement, discount depth, restock size and campaign budget, plus a list of protected fields that no change may touch.
Third-party text is sanitised and fenced. In commerce most of your context is written by people who aren’t you, sellers, reviewers, competitors. Every backend read authored by a third party goes through one sanitiser before the model sees it, wrapped in a fence with a fixed label, with control and bidirectional characters stripped and anything imitating a conversation turn or a tool call defused. The prompt carries the other half of the contract: fenced text is material to report on, never to act on.
If you’re presenting this internally to a security or risk function, those three are the answer to “what stops the AI from doing something stupid with money.” The answer is that structurally it can’t, because the checkout interface has no charge method and the write path only accepts approved IDs.
What Claude Commerce Agents cost to run
The code is free. The inference isn’t, and it’s billed however you access Claude. If you are comparing this against a Salesforce-native route, the Agentforce Flex Credits pricing model works on a completely different unit and the two numbers are not directly comparable.
Two things from Anthropic’s engineering guidance belong in front of whoever signs the budget.
First: prompt caching is the dominant cost variable, not model choice. The guide reports that the strongest commerce deployments run at 90, 99% cache hit rates and that this is the range to design for from the start. Cached input reads cost roughly a tenth of fresh ones; cache writes carry about a 1.25x premium, so a cached prefix pays for itself on its second use.
Caching is prefix-based, which means order matters as much as content. Structure the request in three segments by how often they change: global (system prompt, tool definitions, identical every session, your warmest cache), then session (user context and conversation history), then volatile (current time, current page) at the very end. The most common mistake named in the guide is putting a timestamp or the current page at the top of the system prompt, which silently breaks the cache on every single request.
That is a fifteen-minute architecture decision in week one with an order-of-magnitude cost consequence in month six. It’s also invisible in testing, because with low volume nobody looks at the bill.
Second: measure cost per completed task, not per model call. A cheaper model that needs more turns, or fails more often, isn’t cheaper. Anthropic’s starting point is Opus-class for merchant agents, where the work is analysis-heavy, and Sonnet-class for consumer-facing agents, where latency weighs more, then run your eval suite across every model and effort level you’d consider and let the numbers decide. Current rates are at claude.com/pricing.
Testing Claude Commerce Agents, the part that gets cut
Every agent project I’ve seen under time pressure cuts evaluation first, and it’s the wrong cut.
The useful shift in Anthropic’s approach is to evaluate snapshots, not conversations. The API is stateless, so any state a conversation can reach can be constructed directly: build the test state, append the test message, let the agent run, then grade the final state and the rendered response, including the arguments of the last write. They explicitly recommend against grading the path the agent took, because those tests are brittle and over-constraining.
Two things I’d hold teams to:
Most suites are far too heavy on clean-state cases. If a bug only appears after a busy first turn or a contradiction earlier in the session, a test starting from a blank state will pass on every configuration and tell you nothing. Some meaningful share of your cases should start from long, messy, contradictory histories.
And write the negative for every positive. A “should refuse” for every “should serve,” a “should just do it” for every “should ask.” Missing negatives are named as the most common gap in real suites, and it matches what we see, teams test that the agent does the thing, never that it declines to do the thing it shouldn’t.
Fifty to a hundred cases per user flow is the suggested starting point. That sounds like a lot until the first regression ships.
How I’d actually start
Read-only, one workflow, one real system boundary.
The repository supports this directly and it’s the most underrated thing in it. A shopping pilot can implement search and product detail and stub everything else, a stubbed method returns unavailable and changes no prompt bytes. A merchant pilot can implement the read methods and have every write refuse, so digests and analysis run with no write path in existence. And any capability your business simply doesn’t have gets switched off through an enable_* flag, which strips its tools, prompt lines and grounding rules rather than leaving the agent to reason about a system you don’t operate.
That’s enough to answer the only question a first pilot needs to answer, which is whether your data, permissions and definitions can support the workflow at all.
Questions we’re getting
Is it free?
The repository is, under Apache 2.0. Running the agents consumes Claude model usage, billed through whichever platform you access Claude on, the Claude API, Amazon Bedrock, Microsoft Foundry or Google Cloud Vertex AI. Free code, metered inference.
Does it work with Salesforce Commerce Cloud?
Yes, but not out of the box, no platform connectors ship. Commerce Cloud connects through the backend interfaces the same way any other catalog, order or pricing system does, with credentials held server-side by your host application.
Can the agent place an order or charge a card?
No, and not by policy, by structure. In the reference implementation the checkout tool renders the cart for your own checkout to complete, and the backend interface the agent calls has no charge method at all. Every merchant write is staged until a person approves it. Payment is left entirely to your existing checkout or an agentic payments provider.
Do we need Shopify?
No. Shopify announced a reference storefront connecting the blueprint to Shopify stores through Catalog, the Universal Commerce Protocol and Shop Sign-in, but the blueprint itself is platform-agnostic.
Odoo, Zoho, Dynamics?
No prebuilt connector for any of them, and none needed. Each backend method is code your team writes that calls your service server-side, so they integrate exactly like any other system of record.
How long does it take?
The demo runs in an afternoon. A narrow read-only pilot against real systems is weeks, and the timeline is set almost entirely by the state of your product, inventory and customer data, not by the agent code. I’d be sceptical of any estimate that doesn’t start with a data assessment.
What about the results Anthropic published?
Anthropic reports that retailers running shopping agents on Claude have seen carts up to 35% larger and shoppers 60% more likely to complete a purchase. Those are Anthropic’s own figures. The announcement doesn’t publish sample size, test design, retailer mix or attribution method, so treat them as directional vendor evidence and build your own baseline before you commit to a number internally.
Ashapura Softech is a certified Salesforce, Zoho, Microsoft and Odoo implementation partner, based in Irving, Texas with a development centre in Ahmedabad. We’ve been doing CRM and ERP integration work for North American businesses since 2012. If you’re scoping a commerce agent and want a straight answer on whether your data is ready for one, talk to us, the assessment is usually a short conversation.