Anthropic Commerce Agents: The Blueprint

On 1 September 2026 Anthropic pushed a repository called commerce-agents to GitHub, and by the time I looked at it two days later it had more than 560 stars off a single commit. Anthropic Commerce Agents is a reference blueprint for two things a retailer would want: a shopping agent you embed in your own app for customers, and a merchant agent your staff use to run the back office. Apache-2.0, Python, no releases, one contributor. If you skim the README you'll come away thinking it's a demo. Read docs/safety.md and you'll change your mind.

What Anthropic actually shipped

The repository holds seven pip packages, four runnable verticals, eight web apps, and a Claude Code plugin. Retail runs the storefront on port 3000 and the merchant portal on 3100; travel, telecom and entertainment take 3001 through 3003 with portals on 3101 through 3103. Python 3.11+ and Node 22 get you all of it running locally with one script: python scripts/run_demo.py retail brings up the API on 8000 and the storefront on 3000, --merchant swaps in the portal, --all starts both. The scripts/ directory also holds a smoke chat, a screenshot tour, a Managed Agents deploy script and a verify_all.py, which is more operational tooling than most reference repos bother with on day one.

The README opens with a warning worth repeating, because it defines the boundary of the whole thing:

"Every company, brand, product, and person here is fictional; the only company is ACME. Nothing places an order, charges a card, or changes a live listing."

So this isn't a hosted service and it isn't a product you buy. Anthropic Commerce Agents is code you clone, read, and rewrite against your own systems. The examples exist so you can see the shape of a working deployment before you commit to one.

Two agents, five skills each

The shopping agent searches, compares, plans, fills a cart, answers order and policy questions, and remembers what a customer tells it. Those five jobs live as skills on disk: search-discovery, purchase-research, planning-goals, customer-care, memory-personalization.

The merchant agent covers the other side with performance-insights, catalog-listings, inventory-operations, pricing-promotions and marketing-campaigns. Same pattern, different domain.

Underneath each sits an abstract backend you're expected to implement. StorefrontBackend maps onto your catalog, cart, order and policy systems; MerchantBackend onto analytics, catalog, inventory, pricing and campaigns. That pair of interfaces is the actual contract, and everything else in the repo is scaffolding around it.

Standing up all four verticals means eight Node apps plus a Python API competing for ports and memory on whatever machine you happen to be using. That's the first practical reason MoClaw comes up here: a hosted cloud AI computer gives you a second machine to run the demo tour on, so the evaluation doesn't collide with the project you're actually shipping this week.

One definition, three places to run it

The same prompt, skills and tool contracts run on the Messages API, on the Claude Agent SDK, and on Managed Agents. The Messages API version is the reference loop, and the examples are host applications wrapped around it. The SDK version hands the loop to the SDK and ships a console. The Managed Agents version is a manifest plus an MCP server.

You write the agent once. Where it executes becomes a deployment decision rather than a rewrite, which is the sort of thing that sounds obvious and almost never survives contact with a real codebase.

Worth noting for anyone comparing paths: the three runtimes do not enforce identical rules. Grounding, the mechanism that forces a read tool before the model answers certain question shapes, is complete on the Messages API, partial on the Agent SDK, and absent on Managed Agents. The safety doc says so in a table rather than burying it.

The safety document is the real product

Most agent reference code ships a happy path and a note about how you should add guardrails. This one ships the guardrails and documents which file enforces each rule.

Third-party text gets sanitized and wrapped in a fixed-label fence before the model reads it, capped at a configured character limit. Sanitizing strips invisible and control characters, forged turn markers, transcript and tool-call tags, and any copy of the fence marker itself. That's a prompt-injection defence written by someone who has watched the attack work.

Cart writes only accept product ids that a catalog or order tool returned during this session. An add that names a product with options gets held and pointed at its variants instead of guessing. Nothing in the codebase can place an order or charge a card, because StorefrontBackend has no such method; checkout renders the cart and hands it to the host, and a hosted checkout URL comes from checkout_handoff after the model's call, never passing through the model at all.

On the merchant side every write is staged rather than applied. Guardrails run when the change is staged and again at apply time, against the configuration in force at apply rather than the one from when it was staged: items per change, price move size, promotion depth, restock size, campaign budget, protected fields.

And the line I'd put on a poster:

"A preview card approves nothing; an approval typed in chat sets nothing."

Approval has to come from the host's approve route or the SDK's host_approve. The model cannot talk its way into applying a price change, which is the failure mode everyone worries about and almost nobody designs against.

There's more of this than fits here. Memory facts are capped at a 64-character key and a 200-character value across three categories, with identifier-shaped values refused by default; extraction reads only the user's and assistant's text from the last exchange, never tool results, and a saved fact carries a digest of the writing session rather than the session id. The analysis delegate's query tool takes a single SELECT with no comments, capped in rows, characters and wall-clock time. The tool list is a function of the deployment config and the executor refuses any name that isn't on it. Identity stays server-side: session start binds a principal to an unguessable session id, later requests carry only that id, and no tool argument ever names a user or a merchant. The reference MCP servers bind to loopback unless an environment variable states that an authenticating gateway sits in front of them.

None of that is glamorous, and all of it is the part a team under a Q4 deadline would otherwise skip.

What you still have to build

The backend adapters, first and largest. Every method on StorefrontBackend and MerchantBackend is yours to implement against systems that already exist and were not designed with an agent in mind. docs/backends.md covers the mapping; it doesn't do it for you.

Then the approval surface. The repo gives you a demo portal with an approve route. Your version has to fit whatever your ops team already uses, and it has to be the only path that marks a change approved.

Evals, third. The plugin includes /author-commerce-evals, which tells you Anthropic expects you to write them and doesn't ship a suite that covers your catalog.

Business rules, authorization and compliance are explicitly the deployment's problem. Anthropic states this twice, once in the README note and once in the safety doc's closing column, and the repetition reads deliberate.

The merchant side also ships a scheduled digest on Managed Agents, which is the second place MoClaw is worth mentioning: a digest that fires at six in the morning needs a machine that was awake at six in the morning, and a laptop in a bag is not that machine. A hosted cloud AI computer is, and it sits alongside whatever you already run locally.

Why it landed the week before Q4

The Claude for commerce page Anthropic links from the repo currently leads with "Win the sprint to holiday season this year" and promises consumer and merchant agents "in your app, connected to your systems, in weeks." Eight live demos sit under it, split evenly between consumer and merchant agents.

That timing is the story. Publishing a commerce blueprint on 1 September, with holiday planning already locked at most retailers, is a bet that a meaningful number of teams will try to ship an agent inside a single quarter. Anthropic Commerce Agents exists to make the "in weeks" claim survivable by handing over the parts that take longest to get right: the injection fence, the provenance checks, the staging and approval loop.

Whether that's enough depends on how ugly your existing catalog API is. It usually is.

For a wider view of where agents are being deployed right now, our 2026 guide to AI agent use cases covers the patterns that keep recurring, and what agent reach means gets at the same question from the access side.

One last practical note. An agent you're evaluating tends to want to keep running: a session that holds provenance state, a staged change waiting on approval, a digest scheduled for tomorrow morning. Running that on the machine you also use for meetings is how evaluations die. Putting it on MoClaw means the runtime outlives the terminal window you started it in, and the approval loop is still there when someone finally gets round to clicking approve.

FAQ

What is an AI commerce agent?

Two different things, usually. A shopping agent faces customers inside a retailer's own app: it searches the catalog, compares options, builds a cart and answers order questions. A merchant agent faces staff: it explains performance, edits listings, reacts to inventory alerts, and drafts pricing or campaign changes for a human to approve. Anthropic Commerce Agents ships a reference implementation of both.

Is Anthropic building a shopping agent?

Not as a product you can buy. It published reference code and a Claude Code plugin that scaffolds one against your systems. The blueprint is deliberately inert: nothing in it places an order, charges a card, or edits a live listing, and every merchant write is staged until a person approves it.

Can I use Commerce Agents in production today?

Not as-is. The repository is two days old with a single commit, no tagged release, and one contributor, and the backend adapters that connect it to a real catalog are unwritten by design. Read the code for the enforcement patterns, then build against your own systems.

What licence is Anthropic Commerce Agents under?

Apache-2.0, confirmed on the repository on 3 September 2026. That's permissive enough to copy the enforcement code into a closed-source deployment, which given how much of the value sits in commerce_common/ is the point.

How do I scaffold my own commerce agent?

Clone the repo, then claude plugin marketplace add anthropics/commerce-agents and install commerce-builder@claude-commerce-agents. The plugin exposes /scaffold-commerce-agent, /add-commerce-flow, /author-commerce-evals and /review-commerce-agent; the last one starts from an agent you already have rather than a blank project.