Discuss your project
Commerce and AI

AI commerce agents: designing a reliable, measurable shopping journey

A commerce agent must neither invent a product, change a price nor trigger an ambiguous payment. Here is how to connect conversation, catalog and checkout while retaining control.

Architecture contrôlée d’un agent IA pour la recherche, le panier et le checkout e-commerce.

On September 2, 2026, Anthropic published an agentic commerce blueprint including reference implementations for a shopping agent and an agent for merchant teams. The vendor describes an architecture built around a model, skills, business tools and an evaluation suite. The announcement comes as platforms seek to move search, comparison and cart building into a conversation. Yet the real challenge is not producing convincing dialogue: it is preserving catalog accuracy, cart state, consent and responsibility for payment.

Key takeaway: a commerce agent should reason freely but act through narrow, deterministic interfaces. The catalog, prices, stock, terms and cart remain external sources of truth. The agent proposes and orchestrates; business services validate, persist and confirm.

1. What a commerce agent actually covers

A shopping agent helps a customer articulate a need, search for products, compare options, build a coherent selection and pass a cart to checkout. It can also answer post-order questions about tracking, returns or the refund policy.

A merchant agent serves the company's teams. It analyzes sales and stock, flags a risk of shortages, suggests a promotion or prepares a campaign. External actions—price changes, publication or supplier orders—must remain subject to explicit approval.

These two agents sometimes use the same data, but their permissions differ. The customer agent reads the catalog and modifies the session's cart. The merchant agent may access aggregates, margins and broader inventory data. Combining them under a single identity needlessly increases risk.

Anthropic reports that some users of its agents have observed carts up to 35% larger and a 60% higher likelihood of purchase. These figures are presented by the vendor and are not a guarantee applicable to every sector. They should be treated as a hypothesis to test, with particular attention to selection effects, margins and returns.

Success cannot be reduced to cart size. An agent that pushes unsuitable products may increase the immediate amount while damaging trust, the return rate and customer value.

2. A simple architecture before multiplying subagents

Anthropic's technical guide proposes a main model in an agentic loop, equipped with skills and tools. It advises against creating a subagent for each domain when the conversation, preferences and cart need to stay consistent across turns.

This recommendation is pragmatic. Every delegation requires transferring context, adds latency and creates a risk of state loss. A request such as “replace the jacket with a cheaper option but keep Friday delivery” combines search, comparison, the cart and logistics; it does not divide neatly into silos.

Skills allow procedures to be loaded at the right time: return policies, compatibility guides, comparison methods or style rules. Tools perform deterministic operations: searching, checking stock, creating a cart, calculating delivery or reading an order.

A subagent remains useful for a large, self-contained task, such as in-depth research whose summarized result alone is returned to the orchestrator. It may also be justified when a regulated domain has its own agent, identity and compliance process.

The rule is not to confuse code modularity with multiplying agents. Business services remain modular; the conversation can retain a single owner as long as context needs to be shared.

3. Keep the catalog, prices and stock as sources of truth

The model must never invent the product listing. It receives structured results from a search engine or catalog API: identifier, variant, current price, availability, specifications, terms and canonical URL.

The displayed response must be traceable to these objects. When the agent states that a product is available, the interface shows when it was checked. Before adding it to the cart and before checkout, the service checks the price and stock again.

Tools enforce strict schemas. The agent can request search_products with a need and allowed filters, but it does not compose an SQL query or an internal URL. It can request get_offer for a variant identifier without supplying the expected price itself.

Comparisons must distinguish facts from assessments. Weight, warranty and composition come from the catalog. “Better suited to a weekend with two children” is a recommendation produced by the agent and must be justified by the stated criteria.

Commercial rules remain deterministic. Discounts, eligibility, fees and quantity limits are calculated by existing services. The model may explain the result, but it does not rewrite the policy.

This architecture follows the preparation described in our article on agentic commerce and exposing the catalog and checkout.

Controlled architecture of an AI agent for e-commerce search, cart management and checkout.
The agent orchestrates search, the cart, orders and payment around sources of truth and explicit confirmations.

4. Make the cart idempotent and explainable

The cart is a transactional object, not a paragraph of conversation. It has an identifier, a version and a state retained by the commerce system. Each change uses an idempotency key so that a network retry or repetition by the model does not double quantities.

Tools must express intent: add a particular variant, change a quantity, remove a line or apply an option. The service checks the cart version and rejects a write if another channel has modified it in the meantime. The agent then rereads the state and explains the conflict.

Before a significant change, the interface presents the consequences: product, variant, quantity, unit price, total and any substitution. Confirmation is required when the agent changes an essential characteristic, replaces several items or exceeds a stated budget.

Retain the provenance of each line. Customers must know what they explicitly requested, what the agent suggested and what they confirmed. This distinction makes support easier and prevents a recommendation from being perceived as a definite user choice.

Plan for rollback. Until checkout has begun, an inverse operation must be able to restore the previous version. Changes are logged without needlessly storing the entire conversation.

5. Separate recommendations, confirmation and payment

Payment is a boundary. Anthropic states that its blueprint leaves payment to the merchant, through the existing checkout or an agentic payment provider. This separation must be preserved even when the experience appears continuous.

The agent can prepare the cart, collect delivery preferences and explain the terms. A deterministic service calculates the final total, taxes, delivery and promotions. The user sees a complete summary before confirming.

Confirmation must be recent and specific. It includes the merchant, amount, currency, address, delivery method, items and main terms. An earlier phrase such as “yes, get them” must not be reused after the cart changes.

Payment data must not enter the model's context. It is entered in a provider component and tokenized. The agent receives only a status and a nonsensitive transaction identifier.

When there is ambiguity, the state remains payment_pending rather than paid. Webhooks are processed idempotently and the displayed status comes from the backend. An agent never infers success from a mere visual change in the browser.

Apply the same logic to merchant actions. A proposed price reduction or campaign is a draft. An authorized person validates the object, scope, date and impact before publication.

6. Personalize without crossing the boundary of consent

Personalization can improve relevance, but it quickly brings together stated preferences, history, behavior, budget and context. Users must understand which data is used and be able to correct or delete a preference.

Distinguish session memory from persistent memory. The former serves the current journey and expires. The latter is created only for a clear purpose, with a legal basis and a management interface. An inferred preference must not be recorded as a fact without validation.

Avoid sensitive categories or inferences that could lead to discrimination. An agent must not adjust prices or service quality based on an assumed vulnerability. Recommendation rules must be audited and consistent with commercial policy.

Anthropic states that its blueprint aims to constrain suggestions to real products and prices and avoid manipulative upselling. The organization must turn this objective into testable controls: respect the budget, show cheaper alternatives, explain commissions, avoid creating fictitious scarcity and never hide a relevant option.

Also measure post-purchase effects: cancellations, returns, complaints and satisfaction. Responsible personalization optimizes relevance over time, not pressure at checkout.

7. Test a nondeterministic system with business evaluations

An evaluation suite must cover reasoning, tools, the interface and the transactional outcome. Start with representative scenarios: requests for multiple products, strict budgets, incompatibility, shortages, ambiguous variants, urgent delivery, returns and order questions.

Add adversarial cases: a malicious instruction in a product description, contradictory prices, a slow tool, stock changing during a task, a repeated webhook and attempts to obtain another customer's data. Check that policies remain enforced regardless of the model's response.

Measure task completion rate, product and price accuracy, cart consistency, number of turns, latency, cost, requested confirmations, transactional errors and human interventions. For commercial quality, track conversion, margin, cart size, satisfaction, returns and value at thirty or ninety days.

Offline evaluations are not enough. An A/B pilot can compare the agent with conventional search, but must retain a control experience and identical safeguards. Results are segmented by request type, device and complexity.

Review failed conversations using a taxonomy: misunderstanding, incomplete catalog, tool error, unsuitable choice, blocking policy or confusing interface. This analysis guides improvements better than an ever-longer prompt.

Whenever the model, a skill, a tool or the catalog changes, rerun critical scenarios. An agent is an evolving system; its certification is never final.

8. Deploy a pilot in ninety days

During the first thirty days, choose a bounded, noncritical journey: one product category, one country, volunteer users and an existing checkout. Expose the catalog for reading, build the cart in a test environment and define the evaluations.

From day 31 to day 60, open the pilot with reversible cart writes. Keep explicit validation before any transition to checkout. Measure errors, latency, cost and abandoned requests. Fix the data and tools before increasing autonomy.

From day 61 to day 90, gradually add order tracking or a few read-only merchant functions. Price and campaign recommendations remain drafts. Run an incident exercise: an unavailable catalog, duplicate confirmation, degraded model or incorrect return policy.

Scaling criteria must be defined before the pilot: zero tolerance for amount errors, a minimum task completion rate, a latency ceiling, cost per session, satisfaction, return rate and no policy deviations. Increased conversion does not compensate for lost transactional integrity.

Plan a degraded mode. If the model or a tool is unavailable, users return to conventional search, the cart and support without losing their state. The agent enriches commerce; it must not become a single point of failure.

Conclusion

Commerce agents can reduce friction between intent and purchase, particularly for complex requests combining multiple products, criteria and steps. Their value depends less on the model's eloquence than on the architecture around it.

The catalog, prices, stock, cart and payment must remain deterministic and verifiable. The agent orchestrates narrow tools, requests precise confirmations, respects consent and is evaluated on the lasting quality of the transaction. Partitech supports commerce businesses in designing these architectures, integrating them with existing systems and building measurable, reversible pilots.

References checked on September 3, 2026

  • Anthropic — “Building commerce agents with Claude”, September 2, 2026: https://claude.com/blog/claude-for-commerce-agents
  • Anthropic — “A guide to the anatomy of effective commerce agents”, September 2, 2026: https://claude.com/blog/the-anatomy-of-effective-commerce-agents
  • Anthropic — Commerce Agents reference repository: https://github.com/anthropics/commerce-agents

Share this article