One-click magic: a multi-agent item recommendation copilot for chat support

On Shopee, a buyer eyeing a listing will often message the shop before they commit, and a customer service agent answers on the shop's behalf. But one agent stands in for a catalog of thousands of items, and cannot possibly know it by heart. So every question turns into lookup work: if the buyer is asking about the item, the agent reads through its description to reply; if they want something else, the agent digs through the shop's listings for a closer match by hand. And that's pretty slow.

Ops wanted to fix this by hardcoding the suggestions: a fixed rule pairing each item with a pricier one in the same category. I thought that was backwards. It does not scale, and it ignores the most useful thing in the chat, the question the buyer just asked. So I pitched the opposite: let an AI read the conversation and do the digging.

I showed ops a rough feasibility demo on our internal low-code AI builder (kind of like Coze), they bought in, and I built the real thing with a PM in under three weeks: one button inside the agent's chat window. The agent taps it, and half a minute later finds up to three product cards waiting, each with a short reply ready to send.

Intent is the whole game

The system does not recommend a product to everyone. Pressing the sell button feeds the buyer's transcript to a supervisor agent whose only job is to read intent and route, and almost all of the usefulness lives in getting that routing right.

There are four real cases and one honest non-answer:

• Same item. The buyer wants to know something about the product in front of them ("is there a warranty for this?"). This routes to an agent that reads the item's own description and writes a contextual answer. No recommendation, just a good reply.
• Upsell. They are circling a better version of the same thing. For an iPhone 16, it surfaces the iPhone 17 as the higher-value step up.
• Cross-sell. They ask for something that completes the purchase ("do you have a charging brick for this?"), and it suggests up to three complementary items with a short reason for each.
• Substitute sell. They are looking at one option, but a close alternative at a similar price might suit them better. Looking at a $1,000 fridge with a top freezer, it can surface a $1,000 fridge with a bottom freezer: same budget, different form.
• Unclear. If it cannot tell what the buyer wants, it tells the agent no recommendation was found and gets out of the way.

That last case mattered more than it looks. The easy version of this tool recommends something every time, and agents quickly learn to ignore it. Returning nothing on a weak signal is what kept the panel worth glancing at.

Under the hood this is a small crew of models, not one big prompt. The routing runs on a lightweight model, since it fires on every click and has to be cheap. The judgment work goes to a frontier model: writing the same-item answers, and scoring candidate items against the product's description so it recommends at most three, and only when relevance clears a high bar. Splitting it this way kept each prompt narrow enough to stay reliable and the per-click cost sane.

Why 30 seconds of latency was fine

The full chain runs in about 20 to 30 seconds. For a system a person waits on, that would be a dealbreaker. The decision that made it work was to build something the agent does not wait on.

The sell button is fire-and-forget. The moment an agent taps it, they are free to switch to another chat, and the draft is ready when they circle back. So the thing that would normally be a latency problem became the exact behavior we wanted to encourage: less time parked on one conversation, more chats handled in parallel. I braced for latency to be the hard constraint. Framing the tool as asynchronous made it irrelevant.

The friction was human, not technical

The models behaved. People needed a beat to learn the tool. The sell button is meant to be pressed at the buyer's question, so the AI drafts the reply the agent then sends. Early on, agents would read the question, type their own reply, and then press the button, which is backwards: they had already answered, so the draft had nothing useful to add. There was real confusion in the first few days. It cleared up within about a week, once people understood the AI's draft was meant to be the reply, not a second opinion on one they had already written.

What it moved, and where I stopped

The build itself was fast in a way that surprised people. My half was the agents: the supervisor that reads intent and routes, and the two task agents. The PM, who came from a software-engineering background, built everything around them, the sell button and the Chrome plugin that calls the agentic workflow. We had it working in roughly a week and a half, plus about a week of testing and grading responses alongside the ops team. A two-person build with no formal sprint cycle moving that fast was not the normal shape of a project here, and the speed was part of why it got taken seriously.

And it earned the next conversation, which is the whole point of a PoC. With the copilot in the loop, agents handled meaningfully more chats without a drop in order conversion, a productivity lift in the low single digits across multiple regions. The "no conversion hit" half mattered as much as the productivity half: a tool that makes agents faster but quietly costs sales is not worth scaling, and being able to say it did neither is what made the result credible.

So when ops asked us to build the full production feature, we said no. Getting the latency from 20-30 seconds down to a couple, and pushing response accuracy higher, is failsafe engineering work that belongs with a proper software team, not a two-person PoC. The promising numbers became the justification for a proposal to the feature PM who owns scaling it. Knowing where the PoC ended and the real build began was its own kind of result.