Commerce Agents: Sales Lift Without the Token Bill
Shopping agents can lift cart size and conversion. Here is how to keep the inference bill flat at high traffic, using model tiering and open-weight models.
Do AI shopping agents actually increase sales? The published evidence says yes, with a caveat worth understanding before you budget for one. Anthropic reports that "retailers running shopping agents on Claude have seen carts up to 35% larger and shoppers 60% more likely to complete a purchase" (Anthropic, September 2026). That is a meaningful commercial result. It is also a result measured on a specific frontier model, which matters the moment somebody asks what this will cost at a million sessions a month.
This article covers both halves: what a commerce agent does that lifts conversion, and how to stop the inference bill scaling linearly with your traffic. The mechanism for the second is a tiering decision we call the Tier Test, and the short version is that most calls inside a commerce agent do not need the model that produced the headline numbers.
What a commerce agent actually does
A commerce agent is not a chatbot bolted onto a storefront. The difference that produces the lift is that it acts against your systems rather than answering questions about them.
In practice it reads the catalogue, understands a request expressed the way a person would express it, narrows a large assortment to a defensible shortlist, explains trade-offs between options, checks live availability and price, and assembles a cart. The reason this moves cart size is that it does the job a good floor assistant does: it surfaces the complementary item the shopper did not think to search for, and it does so at the moment of intent rather than in a post-purchase email.
Completion moves for a subtler reason. Most carts are abandoned over unresolved uncertainty — will this fit, will it arrive in time, can I return it. An agent that can query the real answer removes the reason to leave and think about it.
The published numbers, read carefully
Two things about that statistic deserve stating plainly, because they change how you should plan.
**"Up to" is doing real work.** Thirty-five percent is the top of an observed range, not an expected value. A serious business case assumes materially less and treats the upper figure as the ceiling of what a well-executed deployment achieved.
**The result is model-specific.** These figures come from retailers running on Claude. They are not a general property of "adding an AI agent", and they do not automatically survive substituting a different model. This is exactly the point at which cost optimisation goes wrong: a team reads the lift, budgets for it, discovers the token bill at production traffic, swaps in a cheaper model everywhere, and quietly loses the thing they were buying.
The correct response is not to pick one model. It is to notice that a commerce agent makes many different kinds of call, and that they do not all carry the conversion.
Where the money actually goes
At low volume the bill is irrelevant and nobody optimises. At high volume the shape of the problem shows: one shopper conversation is not one model call. It is a sequence — intent parsing, query construction, retrieval, ranking, several tool calls, a response, then often another turn.
Most of those calls are internal machinery the shopper never sees. They are classification, extraction, routing and reformatting. They are also, typically, the majority of tokens consumed. The customer-visible reasoning — the part that actually earns the larger cart — is a minority of the spend.
That asymmetry is the opportunity. You are usually paying frontier prices for a lot of work that does not need frontier judgment.
The Tier Test
Five questions, asked of each distinct call your agent makes. They sort the call into the tier that should serve it.
Does this call touch the conversion path?
If its output is what persuades — the comparison, the recommendation, the explanation of a trade-off — it is on the conversion path and belongs on your strongest model. This is the smallest category and the one never to economise on. The published lift was earned here.
Is the output customer-visible prose?
Anything a shopper reads carries brand risk and needs the fluency and instruction-following of a strong model. Anything the shopper never sees — a JSON extraction, a category label, a reformatted query — does not.
Does it require multi-step reasoning, or is it a transformation?
"Decide which three of these forty items suit a beginner on a budget" is reasoning. "Extract size, colour and budget from this sentence into fields" is a transformation. Transformations are where smaller and open-weight models perform close to frontier models at a fraction of the cost, and where the accuracy difference is measurable rather than a matter of taste.
What does a mistake cost?
A wrong extraction produces a slightly worse shortlist. A wrong price or stock claim produces a broken promise. Weight the tier by the blast radius of an error, and note that some of these calls should not be model calls at all — price and availability should come from your systems, not be generated.
Can it be cached, batched, or precomputed?
A surprising share of agent traffic is repeated work. Product summaries, category descriptions and comparison text for popular items can be generated once and reused. The cheapest token is the one you do not spend at request time.
Where open-weight models earn their place
A precise word first, because it affects procurement. Most models described as "open source" are more accurately open-weight: the parameters are published under a licence, but the training data and process are not. The Open Source Initiative maintains a formal definition of what open source AI requires (OSI), and the distinction matters when your legal team reviews the licence, because some popular licences carry usage conditions that a genuine open source licence would not.
With that said, the practical case is strong. Categories two, three and five of the Tier Test — non-visible transformations, structured extraction, and precomputable content — are where a self-hosted open-weight model changes the unit economics, because you move from paying per token to paying for capacity you control. At high, steady traffic that trade favours you. At low or spiky traffic it does not, because you pay for idle GPUs.
Be honest about what self-hosting adds: inference infrastructure, capacity planning, model version management, evaluation harnesses, and an on-call rotation for a component that is now yours. For a retailer already operating at scale, that cost is bounded and worth it. For one running a pilot, it is a distraction that will delay the thing that actually earns money.
Do the cheap things before you change models
Before re-architecting anything, the techniques Anthropic documents alongside the blueprint are lower-effort and lower-risk: prompt caching, tool iteration limits so an agent cannot loop expensively, and guardrails that constrain products and prices to your catalogue data rather than letting the model produce them (Anthropic).
That last one is a cost and a correctness control at once. An agent that must read price from your systems cannot invent a discount, and grounding it there is cheaper than asking a model to reason about pricing.
Caching and iteration limits alone often remove a large share of the bill, and take days rather than a quarter. Do them first, measure again, then decide whether a tiering programme is worth starting.
Measure cost per completed order, not cost per token
Cost per token is the wrong denominator: it makes every model swap look like a win, including the ones that quietly reduce conversion.
The number that matters is inference cost per completed order, set against the margin on that order. A model that costs more per call but converts better can be the cheaper option on that measure. Instrument the funnel so you can see both, and treat any tiering change as an experiment with a conversion guardrail rather than a deployment. If cost falls and completion falls further, you have made the business worse with a smaller invoice.
Frequently asked questions
Can we just use an open-weight model for everything?
You can, and at genuinely high volume some retailers should for the non-visible tiers. What you should not do is put one on the conversion path and expect the published lift, because that lift was not measured there. Move the machinery first, keep the persuasion on your strongest model, and let the funnel data tell you whether to move more.
How much of the bill is realistically avoidable?
That depends on your conversation shape, so treat anyone quoting a fixed percentage with suspicion. What is predictable is the order of operations: caching and loop limits first, then precomputation, then tiering, then self-hosting. Each step is cheaper to try than the one after it.
Does this need a multi-agent architecture?
Usually not at first. A single agent with well-chosen tools handles most retail journeys, and multi-agent designs add coordination failure modes that are hard to debug in production. We set out when the extra complexity pays for itself in our guide to multi-agent systems in the enterprise.
What has to be true before we start?
A catalogue an agent can query reliably, live price and stock available through an API, and an owner for the evaluation set. The first two are ordinary integration work. The third is the one teams skip, and it is what lets you tell a model change from a seasonal change.
How does this relate to personalisation we already run?
Recommendation and personalisation predict what to show. An agent acts on a stated intent in the moment. They complement each other, and the shared prerequisite is clean product data — the subject of our piece on AI in ecommerce and retail.
Getting the economics right the first time
The commercial case for commerce agents is now evidenced rather than speculative, and the engineering question has moved on from whether they work to whether they work at your traffic and your margin. That is an architecture question, and it is answerable before you commit: run the Tier Test across the calls your journey would make, and you will know within a week whether your volume justifies a tiering programme or whether caching and guardrails get you there.
We build and cost these systems end to end, from AI agents and intelligent automation through to the ecommerce platforms they plug into, and we work with retail and commerce businesses on exactly this trade-off. If you want a straight answer on what an agent would cost against your own traffic and margin, start a conversation — bring your session volume and your average order value, and we will tell you whether the numbers work before anyone writes code.