Anthropic's Claude Commerce Agents blueprint is open source under Apache 2.0, and the demo runs in an afternoon. That part is genuinely easy. The part nobody writes about is that the blueprint deliberately stops at your systems, and everything past that line is your ERP, your CRM and your data model.
We implement CRM and ERP integrations for a living, so this is the list we actually walk through with a client before quoting anything. Twelve things. Nine of them have nothing to do with AI.
What your CRM has to give it
1. Session identity resolved by your host application. The agent inherits an authenticated shopper. It never decides who the user is. Guest checkout, two email addresses on one account, and B2B users buying for three different ship-to locations all have to resolve to one answer before the agent says anything account specific.
2. 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. Anthropic's shopping agent is designed to answer service questions in the same conversation as shopping ones, which is the best thing in the release and also the thing that exposes your data model fastest.
3. Account and contract pricing resolvable per customer. If the agent can only see list price, it will quote list price to a customer sitting on a negotiated rate. In B2B that is not a bug report, it is a phone call from your largest account.
4. Memory scoped, with a written retention rule. What the agent may remember between sessions, for how long, and how a customer gets it deleted. Decide this before launch, not after the first request.
What your ERP has to give it
5. Revenue, margin and returns defined the same way everywhere. Two systems that disagree on margin produce an agent that confidently reports the wrong number, in a sentence, with no visible sign it is wrong.
6. 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.
7. Cost data to reason against, and price floors it cannot cross. The floor belongs in your system, enforced server side. Not in a prompt.
8. Product attributes as structured fields. Size, material, compatibility, voltage. As fields, not buried in a paragraph of marketing copy.
9. A campaign calendar queryable by product. Otherwise the agent recommends a discount on something you are already promoting.
What has to be true across both
10. Every merchant write staged for human approval. The reference implementation is built this way. Keep it that way when you extend it.
11. Credentials held server side in the host application. The agent calls your backend methods. It does not hold keys to your ERP.
12. 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 contact with real customers.
The honest read
There are no platform connectors in the blueprint. Not for Salesforce Commerce Cloud, not for Odoo, Zoho or Dynamics, and none are needed: each backend method is code your team writes that calls your service server side. Which means the timeline is set almost entirely by the state of your product, inventory and customer data, not by the agent code.
If you cannot tick nine of these twelve today, the first phase of a Claude Commerce Agents project is a data and integration project, not an AI project. Be sceptical of any estimate that does not start with a data assessment.
The long version, with the capability-to-system mapping, the failure mode nobody plans for, what it costs to run and how we would sequence a pilot, is here: https://ashapurasoftech.com/blog/claude-commerce-agents-erp-crm-requirements/
Top comments (0)