Search for a product, compare the options, drop it in the cart, then answer a question about returns. Any team that sets out to build a shopping agent ends up rebuilding the same foundation from scratch. Anthropic has now released that foundation as code. The repository anthropics/commerce-agents ships two agents, one for shoppers and one for the people running the store, under an Apache 2.0 license.
Two agents, four verticals
The blueprint contains two agents with very different jobs.
The first serves the shopper. It runs inside a merchant's own app or site, searches the catalog, handles requests covering several items at once, compares options and assembles the cart. Questions about order status or returns are answered in the same conversation, without breaking the thread. To adopt it, a team implements a StorefrontBackend against its own catalog, cart, order and policy systems.
The second serves store operations. Staff can ask why sales are flat, receive inventory alerts, request pricing and promotion recommendations, or have campaign copy drafted. Here the connection point is a MerchantBackend.
On top of that, runnable implementations are included for four verticals: retail, travel, telecom and entertainment. With Python 3.11 or later, Node 22 and an API key, the whole thing starts locally, and the same code runs on the Claude API as well as Amazon Bedrock, Microsoft Foundry and Google Cloud Vertex AI. A Claude Code plugin named commerce-builder is included as well, offering commands to scaffold a new agent and to review an existing one.
The decision not to split into subagents
The most debatable technical choice is the shape of the system. Anthropic argues against putting an intent router in front and against standing up one subagent per domain.
The reasoning is straightforward: a shopping conversation does not divide cleanly. The cart contents, the customer's preferences and the history so far all sit with the parent agent, and every handoff drops some of that. Handoffs also multiply token usage and add seconds to the response. The domains overlap in the first place. A single returns question needs order history, the cart and the catalog at the same time.
The alternative is agent skills. Skill instructions load into the agent that already holds the conversation history, so capabilities can be separated without paying the handoff tax. Across several enterprise deployments, Anthropic reports that a single agent with skills beat both the one-big-prompt design and the subagent design on quality, and did so at lower cost and latency. Subagents keep their place for self-contained work such as deep research.
The line between what belongs in the system prompt and what becomes a skill is drawn by frequency. Anything touching roughly a third or more of traffic goes in the prompt; the rest becomes a skill. Safety rules, brand constraints and key user facts always live in the prompt regardless of frequency.
UI components are tools
Most commerce responses are better delivered as interface components than as prose: product cards, itineraries, plan comparison tables.
Rather than prompting the model to emit custom tags, the blueprint defines each component as a tool. Calls such as present_products and present_itinerary carry typed arguments that the server validates before the client renders anything. Because those calls sit natively in the message history, reloading a conversation needs no custom parser. It is also why the agent can resolve a request like "book the first hotel" against what it just presented.
Squeezing latency and cost
The attention paid to perceived speed is concrete. A single response runs 500 to 700 output tokens, which without streaming leaves a spinner on screen for close to five seconds. The blueprint streams components as they form and shows plain-language progress lines, shortening the perceived wait independently of the actual processing time. Dispatching each tool call as its arguments finish streaming reportedly cuts multi-second gaps down to a few hundred milliseconds.
On cost, prompt caching is the main lever. Caching works on prefixes, so requests are ordered from the least volatile information to the most. Putting a timestamp at the top of a system prompt breaks the cache on every request and is avoided. Cached reads cost a tenth of fresh tokens, while cache writes carry roughly a 1.25x premium. Well-tuned deployments are said to reach hit rates of 90 to 99 percent. Memory extraction is pushed out of the conversation into a separate process, which Anthropic measured at 13 percent higher fact recall than saving within the turn.
Money movement, writes and identifier handling all pass through gates in code. The model proposes; the program decides whether the action runs.
Summary
The published blueprint is Anthropic's answer to the structural questions every team building a shopping agent runs into. Do not split into subagents, add capability through skills; type your interface components as tools; stop anything touching money in code. The timing ahead of the holiday shopping season is no accident, but because it is out under Apache 2.0, the material is worth reading for anyone designing a conversational agent, commerce or not.
