Over the past year at Silicon Store, we've built AI shopping agents that handle multi-step purchases on behalf of users — comparing prices across retailers, evaluating reviews, applying coupons, and executing checkout. This post is a description of what's actually inside them.
It isn't a sales post. It's the architecture we've ended up with after a year of getting things wrong and fixing them in production. The pieces are simple individually; the hard part is reliably chaining them together across retailer systems that were never designed for software to read.
If you're building agents in commerce or anywhere adjacent, our hope is that this is useful as a reference architecture — what to build, what to skip, and what we wish we'd known on day one.
What is an AI shopping agent?
An AI shopping agent is software that turns a user's stated goal into a completed purchase, without the user clicking through retailer websites themselves.
That's the one-line definition. The longer one: a shopping agent is a reasoning system, a set of tools that lets it act on the real world, a memory of who the user is and what they want, and an evaluation layer that judges whether the action it just took was actually any good. When all four pieces are present and working, the agent runs in a loop until the goal is met.
The loop looks like this:
The user gives the agent a goal ("find me the best wireless earbuds under £200 with good battery life"). The agent breaks it into a plan — search three retailers, weight reviews above 4.0, compare battery specs, factor in shipping. It executes that plan using tools: search APIs, review aggregators, checkout flows. It evaluates the result against the original goal — does this match the user's request, is the seller reliable, is the price right. If not, it loops: re-plans, re-executes, re-evaluates. If yes, it surfaces the recommendation or completes the purchase.
This loop is what separates an agent from a chatbot. A chatbot returns a response and stops. An agent keeps going until the goal is satisfied or the agent has explicitly given up and asked the user for help.
The reasoning layer
The reasoning layer is where the agent turns a goal into a plan. It's powered by an LLM with a planning loop wrapped around it.
We've found that the quality of the planning step matters more than the quality of any individual tool call downstream. A well-planned search with mediocre data beats a poorly-planned search with perfect data — because the plan determines what data the agent even fetches.
Some concrete things the reasoning layer has to decide:
- What does "best" mean for this user — price, quality, speed, or some combination?
- What information do we already have, and what do we need to go fetch?
- How many tool calls is this query worth? (One call is fast and shallow; ten calls is thorough but slow.)
- Should we ask the user a clarifying question before continuing?
We use a simple pattern here: the agent runs a planning step in plain text before any tool calls. It writes out what it's going to do, what it expects to find, and what it'll do if the result is surprising. That plan goes into the context for the tool calls, and into the evaluation step afterwards.
This is closer to how Anthropic describes their "think" tool than to traditional agent patterns. It's slower than just letting the model call tools directly. But the slowdown buys reliability — the agent makes fewer wrong moves when it's been forced to commit to a plan first.
The tools layer
Tools are how the agent reaches the real world. Without them, the agent is just a chatbot generating plausible product recommendations from training data, which is exactly the wrong thing for commerce.
The tools our agents use:
- Product search APIs across multiple retailers, normalised into a single result schema.
- Real-time pricing endpoints — list price isn't the same as checkout price.
- Review aggregation with authenticity scoring.
- Coupon and discount-code discovery and validation.
- Stock and availability checks.
- Payment and checkout execution.
- Order tracking and return management.
The unlock here is that agents with tools stop being recommendation systems and start being economic actors. They don't just inform — they execute. This is the fundamental shift from search and recommendation into agentic commerce.
We've found that the design of the tools matters as much as the agent itself. Tools that return clean, predictable, well-typed responses are easy for the agent to reason about. Tools that return free-form text with inconsistent fields force the agent to do reasoning work that should have been done at the API boundary. We've also found that giving the agent fewer, more powerful tools beats giving it many narrow ones — the model is better at composing four tools than at picking the right one from twenty.
The memory layer
Memory is what lets the agent feel intelligent instead of reactive.
A stateless agent treats every request as if it's meeting the user for the first time. It asks the same questions, surfaces the same options, and forgets what it learned from the last interaction. That's acceptable for one-shot search; it's poor for agentic commerce, where the next purchase decision often depends on the last one.
Our memory layer tracks:
- User preferences — brands they prefer, retailers they avoid, sizes they wear.
- Budget constraints — per-category limits, monthly caps, savings targets.
- Purchase history and satisfaction signals — which items were kept, which returned, which re-ordered.
- Previously rejected recommendations and why they were rejected.
- User-stated rules — "don't autobuy anything over £100 without asking," "never recommend this brand," etc.
When our agent remembers that a user returned the last pair of Sony headphones they bought, it adjusts the weight of Sony in future recommendations — not to zero, but lower, and only in similar categories. That's not magic; it's memory architecture working as intended.
The evaluation layer
This is the layer most agent builders underestimate. We did, at first.
Evaluation is the agent judging its own results before showing them to the user. Without it, agents confidently surface bad recommendations — the result of an LLM doing its job (generating plausible text) without a check on whether the plausible text was actually correct.
Our evaluation layer asks five questions of every recommendation, before the user sees it:
- Is this within the user's budget?
- Does the product rating meet the threshold the user implicitly or explicitly set?
- Is shipping acceptable for the user's timeline?
- Is the seller reliable based on historical transaction outcomes on our platform?
- Does this recommendation conflict with any of the user's stated rules or past behaviour?
If any answer is "no" or "uncertain," the agent either re-plans or returns to the user with a question. It doesn't push the recommendation through and hope.
This is what prevents the failure mode where the agent confidently buys the wrong thing. Confidence without evaluation is the most expensive bug a shopping agent can have — it's the difference between a wasted minute and a wasted £200.
Stacked together, the four layers look like this:
A tradeoff worth naming
There is a tradeoff: more reasoning steps and more evaluation make the agent more reliable, but they also make it slower and more expensive per query.
A shallow agent might use one LLM call to pick a product. A deep agent might use ten — plan, three searches in parallel, review evaluation, price comparison, evaluation, re-plan if needed. The deep agent is more reliable. It's also five seconds slower and roughly ten times the API cost.
We've ended up running different depth levels for different query types. A simple restock ("buy the same brand of dish soap as last time") gets the shallow path. A novel purchase in a new category gets the deep path. The classifier that picks between them is itself one LLM call — cheap enough that the cost is dominated by whichever path it routes into.
There is no universal right answer here. The right tradeoff depends on how much the agent is allowed to spend on a query, how much latency the user will tolerate, and how high the cost of a wrong answer is in that domain. For commerce specifically, the cost of a wrong purchase is high enough that we err toward more reasoning, more evaluation, more cost.
Multi-agent orchestration
As the system matures, we're seeing the future move toward specialised agents that coordinate rather than one monolithic agent that tries to do everything.
The architecture we're building toward looks like this:
- A price-optimisation agent that monitors prices across retailers in the background, continuously.
- A product-research agent that evaluates reviews, specs, and quality signals.
- A coupon agent that finds and validates discount codes.
- A logistics agent that optimises shipping speed and cost.
- An orchestrator that decomposes the user's request, calls the right specialist agents in parallel, and synthesises their findings into a single recommendation.
The user doesn't see any of this. They say "find me the best deal on a MacBook Pro." Behind the scenes, four specialist agents run in parallel, each doing the part it's best at. The orchestrator takes their outputs and produces one recommendation.
This matches what Anthropic describes in their multi-agent research system — specialisation beats generalisation once the task is broad enough that no single context window can hold everything that matters. It also matches what we've found in production: a single monolithic agent confused about which tradeoff to prioritise tends to make worse decisions than three specialist agents each clear on their own optimisation target.
What we got wrong
Three things we got wrong in early versions that are worth flagging, because they're easy mistakes to make and slow to detect.
We over-indexed on tool count. We thought more tools meant more capability. Instead, more tools made the agent less reliable — it would pick the wrong tool more often than the right one, especially when tools overlapped. We've since cut our tool count by more than half. The agent is faster and more accurate.
We under-indexed on evaluation. Our first agents could plan and act competently but had no internal check on whether the action was good. We learned this the slow way — by watching users override recommendations and digging into why. Evaluation is now its own layer, not an afterthought.
We treated memory as a database. Our first memory layer was a key-value store of "user preferences" that the agent read at the start of each session. That worked for static preferences but missed everything dynamic — what the user just rejected, what they're trying to compare right now, what their budget is for this specific session. Memory is closer to a working set than a profile, and we wish we'd designed it that way from the start.
Looking ahead
There's a temptation when writing about agent architecture to make it sound finished. It isn't. The architecture we have today will look obvious in a year and incomplete in two. The things we're confident about are the broad strokes — that agents need reasoning, tools, memory, and evaluation as first-class layers, and that specialisation beats generalisation as the task gets broader.
The things we're less confident about are the details. How deep should the planning step be? How much should the agent ask versus assume? How do we balance latency against reliability for users with different patience levels? These are open questions in production, and we expect the answers to keep moving.
The gap between agent-as-demo and agent-as-product turned out to be wider than we anticipated when we started. Most of the engineering happens in the parts users never see — the evaluation rubrics, the tool schemas, the memory invalidation rules, the failure-mode handling when a retailer's pricing API returns 503 mid-checkout. That work doesn't show up in launch posts. But it's what separates a system that works in a demo from one that holds up at scale.
We'll keep writing about what we learn. If you're building agents in commerce, we'd love to compare notes — particularly on the parts we got wrong, because those are usually where the next architectural improvement lives.