AI shopping agents: will they show your products?

AI shopping agents are assistants that search, compare and shortlist products on a buyer's behalf. A buyer describes what they want in plain language; the agent finds candidate products, filters them against the request, and returns a small set worth considering, often with reasoning attached. ChatGPT's shopping answers, Microsoft Copilot and Perplexity all do a version of this today, and buying agents are being wired directly into marketplaces and checkout flows behind them. Buyers use them the way they once used a knowledgeable shop assistant: describe the need, receive a shortlist, and rarely look beyond it.

The definitional ground is well covered elsewhere, so we will spend one sentence on the shared part: these systems work from product data rather than from your brand's storytelling, however good the storytelling is.

The more useful question, if you sell products for a living, is not what agents are. It is whether they will show your products when a buyer describes exactly what you sell. That question has a mechanism behind it, and the mechanism behaves differently from the search visibility you may have spent years optimising. The rest of this post walks through it.

They read structured attributes and filter them against the buyer's request. The matching happens on data, not on brand prose.

Take a request like "show me yellow shoes between £50 and £100". To evaluate any product against that, an agent needs a colour field, a price field, and enough category structure to know it is looking at shoes. If the colour only exists inside a free-text description ("a cheerful summer shade"), there is nothing to filter on. The product does not fail the comparison. It never enters it.

That mechanic has an uncomfortable consequence for brands whose differentiation lives in copy. A premium jacket with beautiful storytelling and incomplete specifications can read as interchangeable with a cheaper competitor whose technical data is complete. The waterproof rating held in a structured field transfers; the same claim held in a paragraph of brand voice often does not. Years of investment in copywriting can carry surprisingly little weight in a comparison that runs on fields.

Thin attributes narrow your audience even before agents enter the picture. A catalogue that lists a model number but not the voltage, size and brand a buyer reasons with is quietly assuming the buyer already knows exactly what they want, which tends to attract price shoppers comparing on number alone. Agents raise the stakes on a discipline that was already worth having.

Two honest caveats before the argument hardens. First, attributes are not the whole story: assistants also draw on reviews, community discussion and general web presence, and there is a real feed and protocol layer (structured feeds, schema markup, agent access) deciding what a system can technically read. All of it feeds the answer. But a feed can only carry attributes that exist, and the property layer sits underneath everything else: your website filters, your marketplace listings, Google Shopping, and now agent answers. Second, exposure varies by category. Spec-heavy categories such as electronics, industrial equipment and specialist apparel feel this first, because an agent needs complete attributes before it can compare products at all.

Often because they could not be evaluated at all. Across customer catalogues we see the same shape: products with complete structured attributes appear; products without the attributes an agent needs to match a request are left out of the consideration set entirely, not shown further down the list.

That may read as too stark, and in fairness these systems are young; behaviour varies by assistant and by category, and nobody outside the model providers knows the selection logic precisely. But the pattern has repeated often enough across the catalogues we see that it is worth treating as the working assumption.

That distinction is worth sitting with, because it behaves differently from everything ecommerce teams have learned about visibility. Search degrades gracefully. Weak content ranks lower, position 4 becomes position 9, the graph drifts, somebody notices and investigates. Agent selection is closer to in-or-out. Either the data lets the agent evaluate the product against the request, or the product is not part of the comparison. There is no position 9.

It also helps to name what changed for the team. Search ranking is mostly a Google question: authority, links, content, technical health. AI inclusion is mostly a data-alignment question: does the product data make it clear that this product aligns with what the user is looking for? Different job, often a different owner, and the second one has quietly become part of visibility. In practice it means the person who owns rankings and the person who owns product data are now both working on discoverability, whether the org chart says so or not.

Now the genuinely uncomfortable part. Nothing tells you any of this is happening. There is no error message. No report flags the absence, and no position graph drifts downward, because there was never a position to lose. The listing is live, the stock is in the warehouse, the price is right... and the traffic never arrives. In the cases we hear about, discovery happens by accident: someone finally asks an assistant the kind of question their buyers ask, watches three competitors come back, and sits with that for a moment.

Which suggests a cheap diagnostic. Ask ChatGPT, Copilot or Perplexity what they would recommend in your category, at your price point, with your key specifications. Vary the wording; ask as a buyer would. If competitors come back and your products do not, you have learned more in five minutes than any report could currently tell you. Right now, that conversation is the closest thing to a dashboard this problem has.

More attributes, not less, in structured machine-readable fields an AI can read, filter and analyse. When we discuss AI inclusion internally, that is the whole frame: make the data make it clear that your products align with what the user is looking for. It runs against the minimalist instinct to keep listings lean and put the richness in the description, because the richness in the description is precisely what an agent struggles to use.

In practice this is product data enrichment work, and it has a sequence:

1. Define what complete means, per product type. A jacket needs different fields from a power tool. Completeness rules in a PIM (product information management system) encode that per product type, so every gap surfaces as a work item instead of waiting for someone to run a manual audit.
2. Populate the decision-relevant attributes first. Not every conceivable field: the ones buyers reason with, such as voltage, fabric, fit, certification, compatibility. Start with the products carrying your revenue and work down the catalogue from there.
3. Review attributes before anything is generated from them. AI can help populate values, but keep a human review between population and everything downstream. An error caught at the attribute stage is one correction. The same error amplified into descriptions across five channels and three languages is a clean-up project.
4. Generate content from properties, not prompts. Once attributes are complete and reviewed, descriptions can be generated from them in every language you sell in. We have written before about why your AI content tool is not the problem: the quality ceiling is set by the attribute data underneath. The useful consequence here is that one round of attribute work feeds two outcomes at once, content humans want to read and data agents can evaluate.
5. Launch complete rather than thin. Listing fast and enriching afterwards used to be a sensible trade, because search rewarded the head start and forgave the gaps. With AI systems, the trade looks less forgiving: a product first read with three attributes may go on being judged through those three attributes, and how quickly an enriched product gets a second look is not something anyone can promise yet. Where you can choose, let a new product enter the corpus with its data complete.

Notice what is not on the list: nothing about gaming the agents. There is no trick layer here. These systems are trying to match products to requests, and the entire play is making your products easy to match. If you already maintain structured attributes for marketplace listings, you have a head start: the same fields, extended per product type and kept complete, are most of the job.

This sequence is what we built OneSila around: completeness rules per product type, attribute review inside the workflow, content generated from properties, and the channels, including the agent-facing ones, fed from the same record. You could assemble the same discipline on other tooling; the sequence is the point. But if you want it in one place, that is the shape of the platform.

In most categories, agent-driven purchases are still a small share of traffic today. The reason to act early is that the fix is the same enrichment work your existing channels already reward, and the return grows as the share does. That is the encouraging part: none of this is speculative work that only pays off if agent shopping takes over. It improves your filters, your conversion rate and your marketplace listings now, and agent visibility is one more return on it, possibly the biggest one. The difference is timing: search gave you years to improve gradually, while agents either can evaluate your products today or they cannot. Buyers are already asking. Run the five-minute test this week. Your products cannot be picked from a shortlist they never reached.