Anthropic's Claude Blueprint Boosts Retailer Carts by 35% With Shopping Agents

Anthropic has published a production-tested blueprint for building shopping and merchant agents on Claude, including a reference repository, four vertical demos across retail, travel, telecom, and ticketing, and a Claude Code plugin that scaffolds an agent against your own backend. It comes paired with an engineering write-up on architecture, latency, caching, memory, and safety patterns from teams that have shipped these systems to real customers.

The numbers behind the pitch are worth taking seriously. Retailers running shopping agents on Claude have seen carts up to 35% larger and shoppers 60% more likely to complete a purchase. The code is on GitHub and deploys wherever you already use Claude, including the Claude API, Amazon Bedrock, Microsoft Foundry, and Google Cloud Vertex AI.

What's in the repo

The blueprint ships two working agents built on the Messages API, the Agent SDK, or the Claude Managed Agents beta. The shopping agent integrates with catalog, cart, checkout, customer preferences, and order history, leaving payment to your existing checkout or an agentic payments provider. A customer can submit a messy request like needing a tent, sleeping bag, and stove for a weekend trip with two kids, and the agent plans the multi-item cart from there.

The merchant agent targets store operators. It answers questions about sales performance, tracks inventory, proactively flags problems like an item about to sell out before a promotion starts, recommends pricing and promotions based on the store's own sales history, and drafts marketing campaigns to move slow products. Every write is staged behind human approval before hitting production.

Skills beat subagents

The engineering guide's most opinionated architectural claim is to resist splitting a commerce agent into a fleet of domain subagents. A commerce conversation is one tightly coupled session across multiple intents and turns that requires considerable shared context. In a subagent architecture, the orchestrator holds the cart, staged changes, user preferences, and conversation history, and every handoff loses state.

Agent skills solve this by loading per-domain instructions into the main agent, which already holds the entire history. Across several enterprise deployments, a single agent with skills consistently outperformed both the one-prompt-for-everything design and the subagent design on quality, often at lower cost and latency per task. The practical rule for what goes where: anything relevant to a third or more of your traffic goes in the system prompt, the rest goes in skills, and critical safety, legal, and brand rules always stay in the prompt.

UI components as tool calls

Rather than prompting Claude to emit custom XML tags that a client parses, the model calls something like present_products or present_itinerary with structured arguments, the server validates, and the client renders. Tag definitions live in the system prompt, so every new component bloats context and every edit risks regressions elsewhere in the prompt. Nested custom tags also degrade reliability because the model is better trained on tool calls than on your markup. Past conversations stored as custom tags end up in a format only your parser can read, while tool calls give you a native record of what was on screen when the user says something like "the third hotel." For token-level streaming instead of buffered top-level arguments, set eager_input_streaming: true on the tool definition to skip buffering and the server-side schema guarantee that comes with it.

Latency, cost, and the caching floor

Task completion latency breaks into fewer turns, faster tools, and faster tokens. One of the more useful techniques is eager dispatch: tool arguments stream out of the model like any other tokens, so the harness can execute each tool call as its arguments complete, processing the result while the model streams other parallel tools. This compresses multi-second gaps into a few hundred milliseconds and is on by default in the Claude Agent SDK.

Prompt caching is where the cost story lives. The best commerce deployments achieve 90 to 99% cache hit rates, and that range is worth designing for from the start. The structure that unlocks it orders each request into three prefix segments by change frequency:

• Global: system prompt and tool definitions, byte-identical across sessions
• Session: per-user context and conversation history
• Volatile: anything that changes within a session, like the current time or page, pinned to the very end

The most common mistake is placing a timestamp or the current page at the top of the system prompt, which silently breaks the cache on every request.

Safety enforced in the harness

Commerce failures are financial and often irreversible, so the guide treats a prompt rule as one injection away from being skipped. Every safety rule ships as enforced code. No model tool call moves money or changes the business state directly. Order placement, payments, refunds, price changes, and campaign launches all end in an action the harness controls.

A few specific patterns from the guide:

• The harness keeps a per-session record of every ID the server has handed the model; that record is the only key any write or render will accept. Hallucinated or user-pasted IDs are rejected before the backend sees them.
• Quantity caps are enforced against the resulting state, not the request, and cart writes are serialized so parallel tool calls in one turn cannot stack past the limit.
• Every tool result authored by a third party, including listings, reviews, policies, seller messages, and stored memory, is sanitized and wrapped in a fence with a fixed label before the model sees it.

Memory as an async extractor

Long-term memory runs as a separate system with its own store. Writes happen asynchronously: at the end of each turn, or every few turns in a long session, an agent in a separate thread or process reads the conversation and creates, updates, or deletes facts in the store. This adds nothing to conversation latency and achieved 13% higher fact recall on Anthropic's internal commerce memory eval suite. Reading is layered: a small fixed set always in context, relevant facts pre-fetched per turn, and everything else behind a lookup tool.

Evals that survive production

The evals section argues against grading multi-turn conversations with a simulated user. Because the model's API is stateless, what the agent outputs is a function of the system prompt, the tools, and the messages array. You can construct any state directly, append the test message, and grade the outcome as a snapshot, which is faster and more precise than simulation.

The guide also flags that most eval suites are too clean. A bug that only surfaces after a busy first turn or a contradiction earlier in the session will pass on every configuration when the test starts from a fresh state. For every positive case, write the negative counterpart: a "should refuse" for every "should serve," a "should just do it" for every "should ask."

Who's already running it

Priceline runs its Penny agent on Claude. Shopify is building on the blueprints with a reference storefront that connects to a merchant's store through Catalog, UCP, and Shop Sign-in. Wix reports engineers had a working commerce agent taking prompts within fifteen minutes. Zomato and Fetch both got the blueprint running locally in under an hour.

Visa, Mastercard, and Accenture are listed as ecosystem partners, positioning the blueprint as the foundation for agent-native checkout flows. If you're building anything customer-facing on Claude, the repo is worth cloning for the harness patterns alone.