Two commerce agents built on Claude: a shopping agent a business embeds in its app for customers, and a merchant agent its staff use to run the back office. Each is defined once (prompt, skills, tool contracts, gates) and runs on the Messages API, the Claude Agent SDK, and Managed Agents; four runnable verticals show both over the same libraries.
Note
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: checkout
renders the cart for the host to complete, and every merchant write is staged until a person approves it. Business rules, authorization, and compliance are the deployment's.
Python 3.11+ and Node 22. Clone, install, add a key, run a vertical:
git clone https://github.com/anthropics/commerce-agents.git && cd commerce-agents
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt # the seven packages and their pinned dependencies
cp .env.example .env # add ANTHROPIC_API_KEY
(cd examples && npm ci) # the eight web apps share one workspace
python scripts/run_demo.py retail # API :8000 + storefront :3000
--merchant
starts the portal instead of the storefront and --all
starts both. The
verticals are retail
(:3000, portal :3100), travel
(:3001, :3101), telecom
(:3002,
:3102), and entertainment
(:3003, :3103); each README lists prompts to try on both surfaces.
The Claude Code plugin scaffolds an agent on these packages against your systems, or reviews one you have. With the repo cloned as above (the plugin reads it as the reference):
claude plugin marketplace add anthropics/commerce-agents
claude plugin install commerce-builder@claude-commerce-agents
claude
/scaffold-commerce-agent a shopping assistant for our store
The command asks about your stack, plays the plan back, and builds the project; /add-commerce-flow
and /author-commerce-evals
continue from there, and /review-commerce-agent
starts from an agent that already exists ( plugins/commerce-builder/). Each command also runs when a request matches its description, so naming it is optional.
The shopping agent searches, compares, plans, fills the cart, answers order and policy questions, and remembers what a customer tells it. Its five flows are the skills in shopping-agent/skills/; a deployment implements
over its catalog, cart, order, and policy systems.
StorefrontBackend
The merchant agent explains performance, maintains listings, acts on inventory and order alerts, prices and promotes, and drafts campaigns; every write is a staged change the host's approval surface applies. Its five flows are the skills in merchant-agent/skills/; a deployment implements
over its analytics, catalog, inventory, pricing, and campaign systems.
MerchantBackend
| Directory | Contents | pip package, import name |
|---|---|---|
commerce-common/ |
commerce-common
, commerce_common
shopping-agent/core/
StorefrontBackend
, prompt, tool contracts, gates, executorshopping-agent-core
, shopping_agent
shopping-agent/runtime-messages-api/
ShoppingAgent
, the turn loop on the Messages APIshopping-agent-runtime
, shopping_agent_runtime
shopping-agent/runtime-agent-sdk/
shopping-agent-sdk
, shopping_agent_sdk
shopping-agent/managed-agents/
merchant-agent/core/
MerchantBackend
, prompt, tool contracts, change guardrails, gates, executormerchant-agent-core
, merchant_agent
merchant-agent/runtime-messages-api/
MerchantAgent
and the analysis delegate on the Messages APImerchant-agent-runtime
, merchant_agent_runtime
merchant-agent/runtime-agent-sdk/
merchant-agent-sdk
, merchant_agent_sdk
merchant-agent/managed-agents/
examples/
demo_common/
), shared web code (web-shared/
)plugins/commerce-builder/
docs/
safety.md
(enforced rules), backends.md
(mapping your systems), deployment.md
(other platforms)tests/
tests/
scripts/
install.sh
, run_demo.py
, smoke_chat.py
, screenshot_tour.py
, check.py
, deploy_managed_agent.sh
, verify_all.py
Messages API. The reference loop; the examples are host applications around it:
from pathlib import Path
from shopping_agent import ShoppingAgentConfig
from shopping_agent_runtime import ShoppingAgent
agent = ShoppingAgent(backend=your_backend, skills_dir=Path("shopping-agent/skills"),
config=ShoppingAgentConfig(brand_name="Your Store"))
async for event in agent.stream_turn(messages, session, state):
... # text_delta, tool_call, ui, cart_update (change_update on the merchant side), turn_complete
await agent.update_memory(messages, session) # memory extraction; this path only
The example hosts take the session id in an X-Session-Id
header.
Agent SDK. The same prompt, skills, and tools, with the SDK running the loop; the host prefetches grounding reads, and nothing runs after the turn:
python shopping-agent/runtime-agent-sdk/main.py --once "a two-person tent under $250"
python merchant-agent/runtime-agent-sdk/main.py # approves staged changes with y/N
Managed Agents. A hosted agent over the same skills and contracts, calling your MCP server:
scripts/deploy_managed_agent.sh shopping-agent/managed-agents/shopping-agent # or merchant-agent/...; --live deploys
Fencing, provenance gates, caps, memory validation, and the merchant approval gate run inside the tool call and hold on all three paths; grounding, the analysis budgets, and memory extraction are runtime features. docs/safety.md lists each rule with its module and paths, and what a deployment adds first; the examples have no authentication and the MCP servers bind to loopback.
| Example | Storefront | Portal |
|---|---|---|
examples/retail/ |
ACME Travelexamples/travel/
present_itinerary
extensionACME Mobileexamples/telecom/
ACME Ticketsexamples/entertainment/
Each example's README has a Try
section: the turns scripts/smoke_chat.py
runs, and single prompts with what a good answer does.
ruff check . && ruff format --check . && pytest && python scripts/check.py
python scripts/verify_all.py # the line above plus deploy dry runs and web builds
python scripts/smoke_chat.py --vertical travel # one live conversation; needs a key
requirements-dev.txt
adds pytest and ruff. CI installs from it on two Python versions,
builds the eight web apps, and checks that the package names stay unregistered on the
public index (the pin files install them from their directories, never from the index). To confirm caching, read
cache_read_input_tokens
from turn_complete
, or the line each model call logs on its runtime's logger: zero on a second turn means the prefix changed.
The runtimes take any anthropic
client as client=
and the SDK runtimes take the platform from the CLI environment; docs/deployment.md covers GCP Vertex AI, AWS Bedrock, Microsoft Foundry, and gateways.
None ship; both agents reach your systems through the backend interfaces. Where an official connector is the source of record, it is the integration target: analytics warehouses (Snowflake, BigQuery, Databricks, Amplitude), finance (Stripe, Square, PayPal, QuickBooks), delivery (Slack, Google Drive, Gmail). A commerce platform's own MCP server for catalog, cart, or checkout is called from a backend method server-side; on Managed Agents the manifest mounts it beside the role's server, and the provenance gates stay in front of every write.
Backend methods. Each one calls your service server-side with the credential your host holds for the session; the model reads only the result. A flow whose steps have a fixed order enforces that order in the backend.Read the backend guide. walks through identity and credentials, ordered flows, checkout, products with options, and figures your platform cannot supply.docs/backends.md
The same interface covers other business shapes. On a marketplace, seller is a search dimension and the merchant agent acts for the operator the session names. With account or contract pricing, the price quoted is the session account's. With no checkout of your own, turn the cart off or hand it to a quote, a purchase order, or a hosted checkout URL.Checkout hands off. The checkout card links to your own checkout route, or to the platform's hosted checkout URL (one per seller on a marketplace). The backend returns the URL and the host renders it; the model never sees it.Start small. A shopping pilot implements search and product details and stubs the rest; a stubbed method returns an unavailable result and changes no prompt bytes. A merchant pilot implements the eight read methods and has the writes refuse; digests and metrics then run with no write path.Switch off what you do not have. A system the business lacks entirely (no cart on a referral surface, no order tracking) is anenable_*
switch turned off, which removes its tools, prompt lines, and grounding rule on every path; park the flows that need it underskills/_staged/
. The merchant config has the same switches for listing edits, inventory, pricing, and campaigns.Add your own. A flow is a directory with aSKILL.md
under eitherskills/
. Domain UI is aPresentationExtension
(the verticals ship seven).brand_name
,assistant_name
, andbrand_voice
on either config set the identity.
Copyright 2026 Anthropic PBC. Licensed under the Apache License 2.0. This is a reference implementation; it is not maintained and does not accept contributions.