What Is Agentic Commerce? A Guide For Online Store Owners

Agentic commerce is when an AI agent acts on someone's behalf inside a store rather than just answering questions about it. The customer describes what they need, and the agent searches, compares, builds the cart, and takes them to checkout. Behind the scenes, a second agent reads the store's own data and proposes operational changes for a person to approve.

On 2 September 2026 Anthropic published a blueprint for exactly this: working reference code for two agents, one facing the shopper and one facing the merchant. It is worth understanding properly, because most of the coverage has described it as a product launch, and it is not one.

What is agentic commerce?

Traditional ecommerce assumes a person does the work. They browse categories, open comparison tabs, read reviews, decide, and click buy. Every part of a store, from filters to product photography, exists to help a human make that decision.

Agentic commerce moves that work to software. The customer states an outcome rather than a search term. "I just got a puppy, what do I need for the first week" is not a query a filter can answer, but it is exactly the kind of instruction an agent can act on.

The agent then does what the shopper would have done. It reads the catalog, weighs options against stated needs and budget, assembles a basket, and hands back a cart ready to pay for.

The distinction that matters is between answering and acting. A chatbot that explains your returns policy is answering. An agent that finds the order, checks it against the policy, and starts the return is acting. Agentic commerce is the second thing.

How is this different from the chatbot I already have?

Most stores already have something conversational bolted on, and most of it disappoints. Understanding why is the fastest way to understand what is actually new.

A conventional store chatbot is built from scripted paths. Someone maps the likely questions, writes the answers, and defines the branches. It performs well on the questions that were anticipated and falls apart on everything else, which is why customers learn to type "agent" within about ten seconds.

A chatbot also has no hands. It can tell you the returns policy, but it cannot look up your order, apply the policy to it, and start the return. Every useful outcome ends with instructions for the customer to go and do something themselves.

An agent differs in three ways that matter operationally:

• It reasons rather than matches. An unanticipated question is handled by working from your actual catalog and policies, not by falling through to a generic reply.
• It can act. Searching, comparing, assembling a cart, and starting a return are things it does, not things it describes.
• It holds context. The conversation after the purchase knows about the purchase, so the customer is not asked to repeat themselves.

The tradeoff is that acting raises the cost of being wrong. A scripted bot that misunderstands gives an unhelpful answer, while an agent that misunderstands can take an unhelpful action. That is the reason the serious implementations put a person in front of anything consequential.

What Anthropic actually released, and what it is not

The distinction is where most summaries go wrong, so it is worth being precise.

Anthropic published a blueprint: open source reference implementations of a shopping agent and a merchant agent, licensed under Apache 2.0. In Anthropic's own announcement, it contains "the harnesses, patterns, and guardrails an engineering team needs to get a commerce agent running in days."

An engineering team. Not a switch in your store admin.

The public repository is explicit that it is a reference implementation that is not maintained, every company in it is fictional, and nothing in it places an order, charges a card, or changes a live listing. It is a starting point for developers, not a deployable storefront feature.

What the open source agentic commerce release is, set against what it is not

What it is	What it is not
Open source reference code, Apache 2.0	A product a merchant can turn on
Two working agent designs plus guardrails	A finished storefront integration
A pattern to adapt to your catalog and policies	Something that works on your data out of the box
A signal of where commerce interfaces are heading	Proof that the results generalize to your store

That distinction matters commercially. If you read the announcement as "a product launched," the reasonable response is to wait and see. If you read it as "the pattern is now standardized and free," the reasonable response is to look at whether your product data could support it.

The shopping agent: the customer side

The customer-facing agent covers the full path from question to payment. It searches and compares products, plans a purchase, fills the cart, and hands off at checkout for the store to complete.

The more interesting part is what happens after the sale. The same agent answers order and policy questions and remembers customer preferences, so a follow-up conversation continues with context already attached.

Consider what that removes. A customer who bought a crate that turned out too small does not open a fresh ticket, restate their order number, and wait. The agent already has the order and can size them up or start the return in the same thread.

For most stores, that post-purchase window is where cost sits and where repeat revenue is won or lost. Order status, sizing, delivery timing, and returns arrive constantly, rarely need judgment, and are expensive precisely because they are relentless.

The merchant agent: the side nobody is talking about

The second agent does not face customers at all. It faces whoever runs the store.

It reads the store's own performance data and answers the operational questions an owner actually asks:

• What is not selling, and by how much
• What is running low and needs a restock decision
• What deserves promotion this month
• Which listings are incomplete or inconsistent

The merchant agent also drafts the follow-through: campaign copy, listing updates, pricing and promotion changes. Then it stops.

That stop is deliberate and it is the most instructive design decision in the whole blueprint. Nothing the merchant agent proposes goes live until a person approves it. Anthropic's documentation states that a person approves changes before anything goes live so users get the final say, and the code stages every merchant change behind that approval.

They automated producing the recommendation and deliberately refused to automate acting on it.

Does agentic commerce replace your marketing team?

Not in the way the headline version suggests, but it does change what the work is worth.

The audit of what is underperforming, the call on what to discount, the reasoning behind which product leads the homepage this month: that has been a deliverable. It arrived as a report, a deck, or a monthly call, and it was billable because producing it took skill and hours.

When an agent drafts that continuously and at almost no cost, the scarce part is no longer writing the recommendation. It is knowing which recommendation is right for this business, this season, and this margin, and which one looks sensible and would quietly lose money.

The cost of being wrong is why the approval gate exists. Anthropic built it because being wrong about a price or a listing is not cheap, and a system that acts confidently on a bad inference is worse than no system.

So the honest read is not that the work disappears. It is that the value moves from producing analysis to owning the decision, and pricing that assumes the analysis itself was the product will come under pressure.

Where the 35% and 60% numbers come from

Anthropic's announcement states that retailers running shopping agents on Claude have seen carts up to 35% larger and shoppers 60% more likely to complete a purchase.

Those numbers are being widely repeated. Before you plan around them, note what is missing: no methodology, no named retailer, no sample size, no independent verification, and no study attached anywhere in the announcement. You can read the source and check for yourself, which is the point.

They may well be real. They are also a vendor describing its own product, which is the weakest form of evidence there is. "Up to" is doing quiet work in that sentence too.

Treat them as directional marketing rather than a forecast for your store. Anyone presenting them to you as a projected return should be asked where the measurement came from.

Who is actually using this

The announcement named a number of well known companies, and the list has been repeated loosely enough that it is worth separating who is doing what.

Anthropic describes enterprise customers including Shopify and Priceline as having agents. Those are the clearest examples of the technology in production.

Visa and Mastercard appear in a different role. They are payment partners collaborating on the blueprint, with Mastercard describing its work as helping merchants build their own agents. They are enabling the rails, not running store agents themselves.

A third group, including Klaviyo, Intuit, Wix, and Square, are building with Claude in adjacent ways: campaign personalization, customer experiences, and tools that watch sales, labor, and inventory. Wix reported that its engineers had a working commerce agent taking prompts within fifteen minutes.

The distinction is not pedantry. "Five major brands already run shopping agents" and "two run agents, two are payment partners, and several are building related tooling" support very different conclusions about how mature this is. The second version is what the source actually says.

What can go wrong

Any honest assessment has to cover the failure modes, because they are the reason careful teams move deliberately here.

Confidently wrong answers. An agent grounded in incomplete product data will fill the gaps with plausible inference. A confident wrong answer about compatibility or delivery timing is worse than no answer, because the customer acts on it.

Margin erosion by automation. A merchant agent optimizing for conversion can recommend discounting that lifts volume and lowers profit. Without margin data and constraints, the recommendation looks good and costs money.

Stale context. Stock, pricing, and promotions change while conversations are in flight. An agent working from a cached view can sell what is no longer available.

Policy drift. When the agent effectively applies your returns policy, ambiguity in that policy becomes an inconsistent customer experience that is hard to audit after the fact.

None of these argue against the technology. They argue for grounding it in accurate data, constraining it with real business rules, and keeping approval with a person where the cost of error is high.

What this actually means for your store

Whether or not you ever deploy an agent, the underlying shift is already reaching you, because customers are increasingly asking AI tools to shortlist and compare before they ever land on a site.

Three consequences follow.

Your product data becomes your storefront. An agent cannot be persuaded by photography or layout. It reads attributes, prices, stock, and policies. Whatever is missing or contradictory becomes a wrong answer or a skipped product.

Your policies become executable text. Returns windows, shipping thresholds, and warranty terms stop being pages nobody reads and start being rules an agent applies. Vague policy language produces confidently wrong outcomes.

Being legible to machines becomes a distribution channel. This is the same shift already underway in search, where a court has now held that an agent directed by a user is treated as the user visiting your site. We covered that ruling in what the Amazon and Perplexity decision means for your website.

How to prepare without rebuilding anything

None of the useful groundwork requires you to adopt an agent. It is the same work that makes a store easier to run.

1. Fix product data first. Complete attributes, accurate stock, consistent naming, real specifications. This is the single highest-value step and it pays off in ordinary search too.
2. Write policies as rules, not prose. State the returns window, the conditions, and the exceptions in language that resolves to a yes or no.
3. Add structured markup. Product, offer, and FAQ schema make the same facts machine readable without changing your design.
4. Audit your top twenty questions. The questions your team answers repeatedly are exactly what an agent would handle, and they show you where documentation is thin.
5. Decide your approval boundary now. Before any automation touches operations, define what a system may do alone and what always needs a person. Anthropic drew that line at the change going live, which is a reasonable default.

Notice that the first four are worth doing even if agentic commerce stalls entirely. That is the test of a sensible AI investment: it should leave you better off in the world where the technology underdelivers.

The realistic timeline

A blueprint is not adoption. What was published needs developers, integration with real catalog and order systems, and testing against the awkward cases that make commerce hard: partial refunds, mixed baskets, regional pricing, and stock that moves while a conversation is happening.

What the release does tell you is that the pattern is now standardized and free to copy, and that payment networks and platform companies are building around it. That usually shortens the distance between demonstration and default.

The stores that will handle it well are not the ones that deploy an agent first. They are the ones whose product data, policies, and internal decisions were already clear enough for a machine to work with.

If you are weighing what a conversational layer would actually take on your store, our AI chatbot development work starts from the same place: accurate grounding in your real data, a clean handover to a person, and measurable outcomes.