Claude Commerce Agents: What Retailers Should Build First

Your engineering team can now clone a working shopping agent and merchant agent before the first architecture workshop. That makes the demo easier, but it does not decide what your retailer should automate first.

Claude Commerce Agents is Anthropic’s open-source blueprint for building customer-facing shopping agents and internal merchant agents with Claude. It supplies reference code, skills, tool contracts, safety gates, and retail examples, but retailers still need to connect their own commerce systems, define permissions, test behavior, and decide where human approval remains mandatory.

The useful question is therefore narrower than “can we build this?” It is which agent should earn the first production budget, based on the bottleneck your customers or store team already experience.

Start here: what does the Claude Commerce Agents blueprint provide?

The Claude Commerce Agents blueprint provides two working reference agents, shared components, example interfaces, safety patterns, and a Claude Code plugin for adapting the setup. It accelerates initial engineering, but it is not a connected retail product. Your team remains responsible for authentication, business rules, system integrations, compliance, and live operational controls.

Anthropic released the blueprint on 2 September 2026. The customer-facing shopping agent can search and compare products, assemble multi-item requests, remember preferences, build a cart, hand it to checkout, and answer order or policy questions. The internal merchant agent can analyze sales, monitor inventory, recommend pricing or promotions, and prepare campaigns.

The distinction between blueprint and product matters. A runnable demo proves that the agent loop, tools, skills, and interface can work together. It does not prove that the agent can interpret your product taxonomy, respect market-specific pricing, recognize the right customer account, or handle a partial return against your order management system.

The open-source repository makes that boundary explicit. No live order is placed, no card is charged, and merchant changes remain staged until a person approves them. It also states that the reference implementation is not maintained and does not accept contributions. Treat it as an architectural starting point whose patterns you own, not a managed application you can switch on.

This also separates the blueprint from the Shopify AI Toolkit adoption question. One provides agent-design patterns; the other concerns controlled access to a Shopify store. A production implementation may need both.

Build the shopping agent first when customer discovery is the constraint

Build the shopping agent first when customers struggle to express a multi-part need through filters, category pages, and site search. It earns priority when the commercial opportunity sits in product discovery, comparison, bundling, or service continuity. Its first pilot should end at a cart or checkout handoff rather than an autonomous payment.

Consider a retailer selling technical outdoor equipment. A customer asking for “a weekend camping setup for two adults and two children in wet weather” is not searching for one SKU. They are asking the store to translate a situation into a compatible set of products, while respecting size, weather rating, availability, and budget. That is the type of request a shopping agent can organize better than a sequence of isolated filters.

Anthropic reports that retailers using Claude shopping agents have seen carts up to 35% larger and shoppers become 60% more likely to complete a purchase. Those figures are promising, but the announcement does not publish the sample size, test design, retailer mix, or attribution method. Use them as directional vendor evidence. Build your own pilot baseline around completed product-finding tasks, cart quality, correction rate, checkout handoff, and customer satisfaction.

A shopping agent is the stronger first route when these conditions hold:

• Customers commonly buy sets, bundles, itineraries, or products with compatibility rules.
• Your catalog attributes are complete enough to support those decisions.
• Product availability and market-specific pricing can be returned in real time.
• Your team can define when the agent must ask a clarifying question instead of making an assumption.
• Checkout already provides the final verification and payment controls.

The catalog is the binding constraint. An agent cannot reason reliably about waterproof ratings, device compatibility, allergens, delivery windows, or B2B pack sizes when those details live in inconsistent titles, PDFs, staff knowledge, and free-text descriptions. Product data work may therefore create more value in the first sprint than prompt work.

Build the merchant agent first when store operations are the constraint

Build the merchant agent first when the store team spends its day gathering data before making routine commercial decisions. It earns priority when planners, merchandisers, and marketers repeatedly combine sales, inventory, pricing, and campaign information by hand. Start with read-only analysis and staged recommendations, keeping approval with the responsible operator.

A seasonal inventory meeting shows the pattern. The merchandising lead exports stock by SKU, checks recent sales in another system, reviews the promotion calendar, and asks marketing which products already have campaign assets. The final decision may take judgment, but much of the work before that decision is retrieval, reconciliation, and formatting.

The merchant blueprint can answer performance questions, flag inventory conditions, recommend pricing or promotions, and draft campaigns. That extends the operational idea covered in Flatline’s article on what Claude changes in enterprise eCommerce operations: the model becomes useful when it can reduce the manual movement of information between systems, while people retain the commercial judgment.

The strongest first workflow has a clear owner, a repeatable decision, and a limited action surface. “Prepare a weekly list of low-stock products affected by next month’s campaigns” is easier to govern than “optimize inventory.” The first can name its data sources, thresholds, reviewer, and expected output. The second hides too many decisions inside one instruction.

Keep write access out of the opening pilot. Anthropic’s reference merchant agent stages changes for human approval, including changes to listings, inventory, pricing, and campaigns. That design lets your team evaluate the recommendation and the proposed resulting state before anything reaches a customer. It also creates a useful audit trail for learning where the agent needs tighter rules.

Choose the merchant route first when:

• Teams repeat the same cross-system analysis each week or each campaign cycle.
• The source systems expose trustworthy sales, inventory, pricing, and campaign data.
• One role already owns the final decision and can review recommendations.
• The first useful output can be delivered without changing live store data.
• Your team can turn accepted and rejected recommendations into evaluation cases.

Build both agents only when the commerce foundation can support both

Build shopping and merchant agents together only when they can rely on the same definitions for products, prices, inventory, customers, orders, and policies. Two agents connected through separate data logic can produce conflicting answers. A shared commerce foundation gives both agents consistent sources, permissions, and rules while keeping their actions distinct.

The apparent efficiency of building both surfaces at once can hide duplicated integration work. The shopping agent may read availability from the storefront while the merchant agent reads it from the ERP. The customer sees an item as available, but the operations team sees constrained stock reserved for wholesale orders. The model is not the source of that conflict. The implementation exposed a definition the existing stack had never reconciled.

Anthropic’s engineering guide to effective commerce agents recommends a single agent loop supported by tools and skills, with specialized delegation reserved for narrow, self-contained work. It also places safety enforcement in the harness rather than relying on the model to remember a policy. That means price limits, protected fields, approval requirements, and write sequencing should be enforced by code around the agent.

For Shopify retailers, the announcement says Shopify is building a reference storefront that connects Claude through Catalog, Universal Commerce Protocol, and Shop sign-in. The repository itself ships no platform connectors. Its backend interfaces are where your team connects the authoritative systems for catalog, cart, orders, analytics, inventory, pricing, and campaigns. The difference between a reference integration and your operating stack needs to remain visible in the project scope.

Before funding both agents, align five foundations:

If you are unsure, start with the smallest useful read-only pilot

The safest default is a narrow, read-only workflow that uses real data and produces an output someone already needs. For a merchant agent, that could be a weekly inventory and campaign digest. For a shopping agent, it could be guided product discovery that creates a cart but leaves checkout, payment, and account changes untouched.

“Read-only” should still mean useful. A chatbot that repeats product descriptions proves little. The pilot should cross at least one meaningful system boundary, such as combining catalog attributes with availability or connecting inventory conditions to the campaign calendar. That is where you learn whether the underlying data, permissions, and tool contracts support the workflow.

Use this decision route:

1. Choose one recurring decision or customer task. Name the person who owns it and the systems they currently consult.
2. Define the terminal action. The agent might present recommendations, create a cart, or stage a change. It should not exceed the authority needed to prove value.
3. List the states that make the answer change. Include market, customer type, inventory position, product restrictions, active promotion, and order status where relevant.
4. Set the handoff rule. State when the agent asks for clarification, routes to a person, or stops because the required data is unavailable.
5. Record accepted, corrected, and rejected outputs. Convert those examples into evaluation cases before adding another capability.

The shortest route from blueprint to production

The shortest credible route to production is to narrow the workflow, connect authoritative data, enforce permissions outside the model, test realistic states, and expand only after the first capability behaves consistently. The blueprint reduces setup work. Production readiness still comes from the retailer’s integration design, operating rules, evaluation suite, and ownership model.

A practical sequence looks like this:

1. Frame the use case. Document the current task, user, business owner, systems, decision frequency, and terminal action. If the task cannot be described without the word “optimize,” narrow it again.
2. Map the authoritative systems. Identify where product data, availability, customer identity, orders, pricing, promotions, and policies live. Resolve conflicting definitions before the agent has to choose between them.
3. Implement the smallest tool set. Connect only the reads and staged actions the pilot requires. The repository supports feature switches, so unavailable capabilities can stay out of the agent’s tools and prompts.
4. Enforce the operational boundary. Put authentication, authorization, state validation, limits, and approvals in the application layer. Treat third-party text such as reviews, listings, and seller messages as untrusted input.
5. Evaluate states, not polished demos. Test low stock, conflicting instructions, partial orders, restricted products, unusual account pricing, unavailable data, and a long conversation with earlier contradictions. Grade the final state and customer-facing result.
6. Measure the task you selected. For shopping, look at task completion, correction rate, cart quality, checkout handoff, and satisfaction. For merchant work, look at time to a reviewable recommendation, correction rate, adoption, and the types of judgment that still require a person.
7. Expand one authority boundary at a time. Add another data source, workflow, or staged action only after the team can explain how the current capability behaves and who owns it.

Key Takeaways

• Choose the bottleneck before the agent. Customer discovery points toward the shopping agent. Repeated internal analysis points toward the merchant agent.
• Treat the blueprint as reference architecture. It supplies working patterns, but your team still owns live integrations, authentication, commercial rules, compliance, and ongoing maintenance.
• Keep the first authority boundary narrow. Cart creation, read-only analysis, and staged recommendations create useful evidence without granting broad write access.
• Resolve the commerce foundation before building both. Shared definitions for products, prices, inventory, identity, orders, and policies prevent the two surfaces from contradicting each other.
• Use real edge cases as the production gate. A polished conversation is a demo. A tested final state, enforced permissions, and named operational ownership make the workflow dependable.

Use this decision tree in the first project workshop. If the team cannot agree on the bottleneck, authoritative data source, terminal action, and human owner, the next step is to clarify the operating model before expanding the agent.