AI shopping assistant for e-commerce.
An AI shopping assistant that answers from your real catalog — sizes, stock, compatibility, delivery, policy — and hands off to a human when it should. Retrieval over your own data, evaluated before launch, budgeted per conversation.
An AI shopping assistant is a conversational layer over your catalog: a shopper describes what they need in their own words — “something waterproof for a 3-year-old, size 5, delivered before Friday” — and the assistant narrows it to real, in-stock products with real delivery dates. Done properly it replaces a filter sidebar nobody uses and a search box that returns 400 results.
Done badly it invents products. That is the whole engineering problem, and it is why we build these on retrieval over your own catalog rather than on a model's memory. The assistant can only talk about SKUs, attributes, stock levels and policies it has just read from your system of record. Anything outside that set is a refusal and a handoff, not a guess.
We build these as part of our wider AI for e-commerce practice, on Magento, Shopify Plus and Medusa. If the questions you actually get are about orders and returns rather than product discovery, the e-commerce chatbot and customer-service AI page is the closer fit.
Six parts of a shopping assistant that works.
Grounded catalog retrieval
Hybrid retrieval — lexical plus vector — over your live product data, attributes, stock and pricing. The assistant answers from what it retrieved, and cites the products it used.
Conversation design
Clarifying questions where the request is ambiguous, comparison when the shopper is deciding, and a direct add-to-cart when they are ready. Turn count is a metric, not an accident.
Guardrails and refusals
Hard limits on price, stock and compatibility claims. No medical, legal or safety advice. Out-of-scope questions route to search results or a human rather than to a plausible sentence.
Evaluation harness
A golden set of several hundred real queries with expected outcomes, scored on every prompt, model or retrieval change. Nothing ships on a vibe check.
Cost and latency budgets
A target cost per conversation and a p95 latency budget agreed up front, then enforced with caching, smaller models for routing and a hard token ceiling per turn.
Storefront integration
Shipped into Hyvä, Liquid, Hydrogen or a Next.js storefront — inline on the PLP and PDP where intent already exists, not only in a corner bubble.
How we build one.
Ground truth first
We collect real queries from your search logs and support inbox, and agree the correct answer for a few hundred of them. That set becomes the eval, and it is the only reason we can tell whether the assistant is improving.
Retrieval before generation
We tune retrieval against your taxonomy until the right product is in the candidate set. A better prompt cannot rescue a retrieval step that never surfaced the product.
Shadow launch
The assistant runs against live traffic without being shown to shoppers, so you can read its answers next to what your team would have said, at zero risk.
Ramp and tune
Staged rollout by traffic percentage, with the eval re-run on every change and a kill switch that falls back to normal search instantly.
The four numbers we report on.
We report the control-group comparison, not just the assisted number — an assistant that only ever talks to high-intent shoppers will flatter itself otherwise. Client-specific results are shared under NDA on the call; see our work for the engagements we can name.
The stack.
Common questions.
How do you stop an AI shopping assistant inventing products?
By never letting it answer from memory. Every response is generated from a retrieved set of real SKUs with their real attributes, stock and price, and the assistant is constrained to that set. If retrieval returns nothing usable it says so and offers search or a human — a refusal is a correct answer.
Will it work on our catalog, or does it need clean data?
It works better with clean data, and part of the first phase is telling you honestly where your attributes are too thin to answer the questions shoppers actually ask. Where the gap is large we usually recommend fixing product data first — see Akeneo PIM — because an assistant cannot infer a material or a size chart that was never recorded.
What does it cost to run?
We set a target cost per conversation in the first week and design to it: small models for routing and classification, the larger model only for the final response, aggressive caching of retrieval and of repeated questions. You get a per-conversation figure and a monthly ceiling before launch, not after.
Can we switch AI vendors later?
Yes — the model sits behind an interface, and the eval harness is what lets you swap it with confidence. We build on Claude and GPT and have run open models where data residency required it. The retrieval layer, the guardrails and the evals are yours and are not vendor-specific.
How long until it is live?
A shadow launch on real traffic is typically six to eight weeks from kickoff, with the first two spent building the eval set. Full rollout follows once the accuracy and latency gates hold. We would rather spend a fortnight on ground truth than ship in three weeks and guess.
Where to next.
Want to see it against your own catalog?
Send us fifty real search queries and we will tell you which ones an assistant would answer well, which need better product data, and which are not worth automating.