Commerce agent blueprint ships with every write staged

Anthropic has published commerce-agents, a reference implementation on GitHub that defines two Claude commerce agents, a shopping agent a business embeds in its own app and a merchant agent its staff use for the back office. The repository ships four runnable verticals over the same libraries, and no code path that places an order, charges a card or changes a live listing.

At a glance

• Each role is defined once, as a prompt, a set of skills, tool contracts and gates, then executed by the Messages API loop, the Claude Agent SDK or hosted Managed Agents.
• Four verticals, retail, travel, telecom and entertainment, run over the same libraries, each pairing a storefront on ports 3000 to 3003 with a merchant portal on 3100 to 3103.
• The examples ship with no authentication and their MCP servers bind to loopback, leaving business rules, authorization and compliance to whatever deployment adopts the blueprint in production.

The design choice that carries the most weight is where the checks sit. By putting fencing, provenance and the approval gate inside the tool call rather than in the host application, Anthropic is describing a pattern in which a commerce agent moves between a raw API loop, an SDK and a hosted runtime without the safety surface changing. It reads as an attempt to standardise the boundary that most agent pilots improvise, while leaving authorization and compliance with the deployment.

Every merchant write stays staged until a person approves it

Fencing, provenance gates, caps, memory validation and the merchant approval gate run inside the tool call, and hold on the Messages API loop, the Agent SDK and Managed Agents alike. Grounding, the analysis budgets and memory extraction are runtime features rather than gate logic. The safety document in the repository lists each rule with its module and file paths, and what a deployment should add first.

Checkout never completes in the agent: the checkout card links to the host's own route or to a platform hosted checkout URL, which the backend returns and the host renders, and the model never sees it. On the merchant side, every write is a staged change that the host's approval surface applies.

Seven Python packages and eight web apps carry the four verticals

A shared commerce-common package holds config, fencing, memory, skills, grounding, presentation, the executor frame and events. Above it, shopping-agent/core defines the StorefrontBackend interface over catalog, cart, order and policy systems, while merchant-agent/core defines MerchantBackend over analytics, catalog, inventory, pricing and campaign systems. Each role has five flows, shipped as skills.

The demos need Python 3.11 or newer and Node 22; a single script starts a vertical, putting the API on port 8000 and the retail storefront on 3000, with flags for the portal or both. Travel adds date-bound inventory, telecom server-authored fee disclosures, and entertainment timed holds, waitlists, transfers and all-in fee disclosures.

The runtimes accept any Anthropic client, and the repository's deployment guide covers Vertex AI, AWS Bedrock, Microsoft Foundry and gateways; the SDK runtimes take the platform from the CLI environment. Caching can be confirmed by reading cache_read_input_tokens from the turn_complete event, where zero on a second turn means the prompt prefix changed.

The repository ships no MCP connectors of its own

Both agents reach external systems through the backend interfaces instead. Where an official connector is the source of record, the repository names it as the integration target: analytics warehouses such as Snowflake, BigQuery, Databricks and Amplitude, finance systems including Stripe, Square, PayPal and QuickBooks, and delivery through Slack, Google Drive and Gmail. A commerce platform's own MCP server is called from a backend method server-side.

A Claude Code plugin, commerce-builder, scaffolds an agent on these packages or reviews an existing one, with commands for adding a flow and authoring evaluations. A shopping pilot can implement only search and product details and stub the rest, while a merchant pilot implements eight read methods and has the writes refuse. Missing systems are enable_* switches that remove their tools, prompt lines and grounding rules on every path.

Apache 2.0 with no upkeep

The code is licensed under Apache 2.0, copyright 2026 Anthropic PBC, and the repository states plainly that it is a reference implementation, not maintained and not accepting contributions. Continuous integration installs on two Python versions, builds the eight web apps and checks that the package names stay unregistered on the public index, since the pin files install them from their directories. No roadmap is given.