Variants, stock and delivery: what an agent checks before it recommends.
Three facts gate whether an AI agent will recommend a product at all, regardless of anything else about it: does the specific variant exist, is it there right now, and will it arrive in time. Get any one wrong and the rest of the listing doesn't matter.
6 min read
Variant: does this exact version exist
Someone's buying a sofa cover as a birthday gift, needs it in a specific dove-grey to match the recipient's actual sofa, and needs it to arrive before a visit in five days. The product exists. The colour exists, somewhere in the range. Whether this specific colour, in this specific size, is sitting in a warehouse right now and can reach the buyer's address in five days is a different question entirely, and it's the one the agent has to answer before recommending anything.
A listing page for "the sofa cover" isn't the same fact as a listing for "the sofa cover, three-seater, dove grey." Colour, size, material, whatever the product varies by, has to resolve to a specific yes or no for the exact combination being asked about. A general "available in multiple colours" note is not that answer.
Stock: a live number, checked in real time
A static in-stock label says nothing about whether it was true an hour ago or is true right now. What matters is the current count, or at minimum a live check, for the specific variant in question, not a badge that was set once and left. The gap gets harder to ignore the more demand spikes: a retailer running a one-day sale on a popular board game might show the same SKU in stock across three warehouses in the morning and sold out in two of them by lunchtime, with the page's own badge catching up hours later. An agent checking at one o'clock needs the one o'clock number, not the nine o'clock one.
Delivery: tied to the buyer's actual address
"Delivery in 2-3 working days" printed on every product page regardless of destination isn't a fact an agent can rely on for a time-sensitive request. What resolves the question is a delivery estimate calculated against the buyer's actual location and the item's current dispatch status, which is a different number more often than retailers expect.
Where this shows up for a business
Selfe connects these three facts, variant, live stock, real delivery estimate, straight from a retailer's own systems rather than a static product page, so an agent checking a time-sensitive request gets the current answer instead of a generic one that happened to be true when the page was last updated.
Isn't stock and delivery just something a checkout page handles?
By the time a buyer reaches checkout, the recommendation has already happened. An agent needs these facts before it decides what to suggest, not after.
What if our stock levels change constantly?
That's exactly the case a live connection solves. A static page can't keep up; a live check can.
Five questions an agent checks before it'll recommend a product.
An AI agent shopping on someone's behalf doesn't browse a product page the way a person does. Before it will recommend anything, it needs five separate questions answered: does the exact variant exist, is it currently in stock, will it work for this specific case, what happens if it's wrong, and will it arrive in time. A page built to persuade a browsing human answers few of those directly.
What a product feed needs that a product page doesn't.
A product page is written for a person looking at one item. A product feed is what an AI agent reads to compare many at once, and it needs a different kind of precision: structured, decision-relevant fields, not the same copy reflowed into a spreadsheet.
What "buyable" needs beyond stock.
An AI agent has already checked that a product is in stock. Buyable asks more of it than that: is the price the one that'll actually be charged, and can this specific item reach this specific buyer at all. Miss either and "in stock" stops meaning anything useful.