We wanted AI in every recommendation. Glad we didn't.

An e-commerce business with thousands of products for the home asked us to personalise its recommendations with AI. They wanted shoppers to find what they needed without going through half the catalogue.

The first idea seemed reasonable. Someone opened a product page, we passed the context to an LLM, and it returned a selection of products. A new response for every visit.

As we started working through the product, a question changed our approach: what would the LLM decide that our data did not already tell us? Before choosing how to build it, we had to understand what someone making a purchase needed.

The same coffee machine, two decisions

Someone could be looking at coffee machines to compare models. Someone else had already chosen one and wanted a compatible filter. Both had a coffee machine on screen, but the recommendation had a different job to do.

We separated those situations. On the product page, we showed alternatives; in the basket, complementary items. Once someone had chosen a coffee machine, filling the basket page with more coffee machines made little sense.

Then we looked at the data we already had. If someone had selected a price range, we had to respect it. Adding something to the basket told us more than an isolated page view. And if their last purchase was a vacuum cleaner, we did not want that to outweigh everything they were looking at about coffee.

There was plenty we could handle with code. We started there.

The order of the products came from rules we could adjust, using selected filters and recent actions.

We prepared product relationships in advance and checked price and stock before displaying items. A coffee machine could fit the search perfectly and still be left out because it was unavailable.

For a first-time visitor, we used what they were looking at. Without even that context, we showed a general selection. We called it “Featured products.” We needed to know a little more before saying “Picked for you.”

AI found a job elsewhere

Building those relationships brought us to the product information. Every supplier provided it differently. Dimensions could arrive in separate fields or buried in a paragraph. The same accessory appeared under different names.

Here the LLM had useful work to do. We defined the data each product family needed and used it to extract attributes from supplier descriptions and documents.

We recorded where each piece of data came from and checked it before using it. The merchandising team reviewed compatibility. If a description said nothing about a coffee machine's noise, we left that field empty. We needed a catalogue we could work with, and a clear view of which data was missing.

We did this when a product was added or changed. Afterwards, the attributes were stored and available across visits. Reading the same description again every time someone opened a product page made little sense.

The other place we used the LLM was search. “I need a small coffee machine for an office” did not arrive as a list of filters. The model helped turn the request into a category and conditions we could check against the catalogue.

If someone wanted a quiet machine and we had no noise data, we said so. If “for an office” did not tell us enough, we asked for clarification. The LLM interpreted the request; the products came from the catalogue.

That clarified our approach: AI to understand what arrived open-ended or messy. Once the data was structured, code could work with it.

An open-ended search could need an LLM call. Changing the price filter or opening a product page again did not.

A recommender we could correct

We ended up with alternative and complementary product blocks, open-ended search, and an internal tool for reviewing attributes and relationships. This mattered: if a recommendation was wrong, the team had to understand why.

If an incompatible accessory appeared, they could inspect the relationship. If the same products repeated too often, they adjusted the weights. We recorded the reasons behind each recommendation. When something went wrong, we knew where to look.

Everyday recommendations no longer had to wait for an LLM response. If search interpretation failed, categories and filters were still available. The e-commerce site could keep working when that part failed.

We also started thinking differently about cost. We went from planning a call for every visit to using the LLM for catalogue preparation and search interpretation. That took the LLM out of the everyday shopping flow. To work out total savings, we still had to include data preparation, infrastructure and maintenance.

Before adding another call, we had to explain what it would solve and why that point needed an LLM.

We learned that it mattered where we put AI. The closer it was to a real-time decision, the harder that decision was to understand, correct and maintain. With stored attributes and visible rules, we could trace a recommendation. When something was wrong, we knew what to change.

The next version had to earn its place

The next step was an A/B test between a general selection and the recommender, with randomly assigned visitors. We wanted to compare purchases alongside clicks and see whether it helped people choose.

If the rules reached their ceiling, we would test a ranking model trained on usage data. We would compare it with what we already had, keeping catalogue and stock checks in place.

Someone finds a coffee machine, understands their alternatives and chooses a compatible accessory. If the next version did not make that purchase easier, we did not need a next version.

Sources

• Google Developers: Recommendation systems overview. Updated 25 August 2025.
• Anthropic: Building effective agents. Published 19 December 2024.