Agents in a shopping app: reorder, track, return

Almost everything written about conversational commerce is about the phone. Systems that answer calls, take orders on a line, deflect a support queue. That is a real business and it is not this one.

This is about the agent inside the app the customer already installed, signed into, and used last Tuesday. That difference changes the design problem completely: the agent knows who is asking, what they bought before, and what your API can do about it.

Start with reorder, and check whether you have the traffic for it#

Reorder is the strongest first feature in retail for a boring reason. The user knows exactly what they want, the app already has it on file, and the only work is navigation.

How much that is worth depends on your catalogue, and it is worth measuring before building. A 2025 paper by Liu and colleagues on next-basket recommendation reports the average repeat ratio across three public datasets: the share of items in a user’s next basket they had bought before was 0.60 on Instacart data, 0.43 on Dunnhumby, and 0.21 on TaFeng.

That spread is the useful part. If you sell consumables, most of a basket is a repeat and reorder is your highest-volume request. If you sell furniture, the same feature serves almost nobody. The query that tells you which you are is one pass over your own order history.

What a reorder request actually does#

The mechanics are less exotic than the framing suggests. A request resolves into calls you already expose.

The agent finds the previous order, resolves any substitution against the catalogue, checks availability, and then stops. Nothing is ordered. It draws one card showing what it is about to do, and waits.

That pause is doing most of the work. The three things that go wrong with an agent in a shopping app are stale state, ambiguous references, and silent substitution: the item sold out since the order history was read, the user said “last week” when there were two shops, or a close-enough product was quietly swapped in. Every one of those is visible on the card and invisible everywhere else.

Tracking and returns, which are support costs wearing a product costume#

The second and third features earn their place differently. Nobody enjoys asking where an order is, and the answer is almost always already in your system.

Both tasks share a shape worth noticing. They are questions with a definite answer that the user cannot easily reach, which is what makes them ideal for an agent and unsuitable for a chatbot that only produces text.

Delivery apps get a stronger version of this. A courier’s arrival window changes while the customer is doing something else, so the question is asked repeatedly and the answer is different every time. An agent that reads live dispatch state can answer it in a sentence and draw the map underneath. A help-centre article about delivery windows cannot answer it at all, which is why so much of that traffic ends up in a support queue that was never designed to hold it.

The self-service literature explains why that distinction matters. Gartner’s August 2024 survey of 5,728 customers found only 14 percent of service issues fully resolved through self-service, with 43 percent of failures caused by people not finding content relevant to their issue. An agent that can call get_order_status does not have that problem. An agent that can only search a help centre has exactly that problem with a better voice.

The answer has to survive being drawn#

A spoken answer that contains six facts is an answer the user has to memorise. This is where a retail agent either works or becomes a novelty.

The rule we hold ourselves to: the spoken answer must stand alone, because someone will hear it with the phone in their pocket. Everything else, the amounts worth checking and the actions worth taking next, goes into native components the app already ships.

The tools are the actual design work#

The temptation is to expose your REST API to the model and let it work things out. Anthropic’s engineering guidance on writing tools for agents, published in September 2025, argues against exactly that, recommending “a few thoughtful tools targeting specific high-impact workflows” over wrapping every endpoint, and consolidating related operations so the model makes one call rather than orchestrating four.

For a shopping app that means writing tools around the request rather than around your service boundaries. A single reorder_previous that takes a reference and an optional substitution is a better tool than three tools the model has to sequence correctly under time pressure. The same guidance asks for error messages that say what to do next, which matters more here than usual: an out-of-stock response that names two in-stock alternatives lets the agent recover inside the turn instead of surfacing a dead end.

Namespacing helps once you pass a handful of tools. orders_get, orders_reorder, catalogue_search reads unambiguously to the model in a way that get, reorder and search do not.

What this does not fix#

Checkout abandonment is mostly not an interface problem. In Baymard’s abandonment research, unexpected extra costs account for 40 percent and slow delivery for 20 percent, against 17 percent for a checkout that was too long. An agent cannot make your shipping cheaper, and a customer hearing the total spoken aloud is no happier about it. What the abandonment research actually supports is worth reading before anyone promises a conversion number.

First purchases are also out of scope. A new customer with a new address and a new card is doing exact data entry, which is the task speech is worst at. The agent’s territory is the second purchase onwards.

And this is a different thing from the agentic commerce the card networks are building. Visa’s Intelligent Commerce programme is about AI agents helping consumers discover products and complete parts of the purchasing journey across merchants, with delegated credentials and spending limits. That is an agent shopping on the customer’s behalf out on the open web. This is your app answering its own customer. The two will meet eventually; today they are separate problems with separate risks.

The order to build in#

Reorder first, if your repeat ratio supports it. Order status second, because it is the highest-volume support question in most retail apps and the cheapest to answer well. Returns third, because the policy logic is fiddly and worth getting right in a place where a human can take over.

Keep the catalogue of components the agent can draw small and audited. Keep one confirm card in front of anything that charges a card. And measure task completion per intent rather than engagement, because an agent that gets asked a lot and finishes nothing will look excellent in analytics.

The catalogue of widget kinds covers what the answer layer can express. What typing costs on a phone covers the input side of the same argument.

Sources#

• Liu, Y., Li, M., Aliannejadi, M., & de Rijke, M. Repeat-bias-aware Optimization of Beyond-accuracy Metrics for Next Basket Recommendation, 2025. Repeat ratios reported per dataset. Accessed 12 September 2026.
• Baymard Institute. 49 Cart Abandonment Rate Statistics. Accessed 12 September 2026.
• CX Today. Only 1 in 7 Customer Service Queries Resolved With Self-Service, Gartner Study Finds. Gartner survey of 5,728 customers, August 2024. Accessed 12 September 2026.
• Visa. Visa Intelligent Commerce. Accessed 12 September 2026.
• Anthropic. Writing effective tools for agents, 11 September 2025. Accessed 12 September 2026.