A new product launches at the exact moment demand is highest and its product data is thinnest, and that gap is why AI shopping agents can't see it.
A new product reaches the market at the moment its product data is thinnest.
A SKU, a price, and a placeholder title, with no attributes, relationships, or context an agent can read. This is what we call a skeleton SKU. Demand intent is high and marketing spend is committed, but the record itself is close to empty. For a shopper browsing the site, that gap closes within a few days as a copywriter and a merchandiser fill it in. For an AI shopping agent, the product may as well not exist.
Definition
Skeleton SKU is the record a new product launches with: a SKU, a price, and a placeholder title, with no attributes, relationships, or category context an AI shopping agent can read.
This is the cold-start problem in agentic commerce, and it runs against how most teams historically think about product data. The working assumption is that enrichment is ongoing optimization, something you improve over time once a product is established. A skeleton SKU has nothing to improve yet. It launches invisible and stays invisible across Research, Find, and Buy until someone, manually and late, gives the answer engines something to read. New products get the most attention from shoppers, but AI shopping agents can barely read them.
AI shopping agents interpret, include, and recommend products from product data: structured attributes, relationships, and category context. A skeleton SKU supplies none of it, and there is no corroborating data elsewhere for an agentic shopping engine to cross-reference. The product isn't ranked low. It is absent from consideration, because there is nothing for the engine to consider.
The standard fix makes the timing worse. A description gets written by hand, attributes get keyed in one at a time, and the richest version of the record arrives days or weeks after launch. For a catalog turning over hundreds of new SKUs a week, or a brand building toward a dated drop, the gap is structural, not occasional.
It's assembly. New products aren't invisible because no one wrote the copy; they're invisible because no one assembled the data. The attributes an answer engine needs almost always exist inside the business already, in the parent SKU, the category, the spec sheet, the design file, the product photography. They are scattered and unstructured, so they never get assembled into a machine-readable record before the product goes live.
Teams read this as "we need to write the copy," which is why it happens late and by hand. The real task is "assemble and structure what we already own," which can happen the moment a SKU is created. That distinction is the heart of Agentic Commerce Optimization (ACO): the discipline of preparing product data so AI shopping agents can interpret, include, and recommend a product. For a new SKU, ACO is not a polish step applied after launch. It is the work of making the product interpretable on day one, from data the brand already holds. The setup process does not publish on its own: it produces recommended product data the team reviews and accepts before the product goes live, so people stay in control of what ships.
New products aren't invisible because no one wrote the copy. They're invisible because no one assembled the data.
Questions and answers are a clear example of data worth assembling. When a shopper asks an agent whether a jacket is warm enough for winter or whether a formula is fragrance free, the answer engine needs product data structured as questions and answers to respond well. This is some of the most useful data for how shoppers research and find, and it is also the least practical to write by hand for every SKU. Assembling it from existing specs and attributes is exactly the kind of work that does not scale manually but does through ACO.
Because it's being judged by the wrong reader. When a brand looks at enriched skeleton data and says "you just reworded what we had," it is judging machine output by a human standard. But a skeleton SKU has no copy to reword in the first place. The real test is not whether the description reads well to a person; it's whether an answer engine that could not previously categorize, include, or recommend the product now can. Those are different readers with two different bars, and conflating them is why this work gets dismissed as cosmetic.
There is also a sequence to this work. The first and largest win is surfacing data the brand already owns but has never exposed in a structured form. External corroboration matters, but it is the second move, not the headline: surface internal first, source external second.
Item setup has to happen at SKU creation, not after launch, and the team's role shifts from writing the record to reviewing it.
A product launch is a discoverability event: the product data has to be ready before the product is live, not assembled in arrears once the launch window has closed. Brands that treat item setup as a back-office task keep paying the same cost: their newest products, with the most intent behind them, are the ones AI shopping agents cannot see.
Frequently asked
Short answers for merchandising, catalog, and growth teams launching new products.
A skeleton SKU is the record a new product launches with: a SKU, a price, and a placeholder title, with no attributes, relationships, or category context an AI shopping agent can read. It is the state most products are in on day one, before a human writer or merchandiser has filled in the record.
AI shopping agents interpret, include, and recommend products from structured attributes, relationships, and category context. A skeleton SKU supplies none of it, so there is nothing for the agent to consider. The product isn't ranked low; it is absent from consideration entirely.
Yes. Optimizing a live page is ongoing refinement of an existing record. A skeleton SKU has no existing record to refine, so the work is assembling a machine-readable record from data the brand already owns, before launch, rather than improving one after the fact.
Because the attributes an answer engine needs almost always exist inside the business already, in the parent SKU, category, spec sheet, or product photography. They are scattered and unstructured. The task is assembling and structuring what the brand already owns, not writing new copy by hand.
Teams should review a system-assembled, structured product record before launch, the same way they review price: is it interpretable by an AI shopping agent, built from internal data first, and judged by whether an agent can now categorize, include, and recommend it, not by whether the copy reads well to a person.
Complex catalogs, structured APIs, and the case for making product data perform wherever buyers now begin their journeys.
New benchmark adds an agentic readiness layer to the Top 1000, revealing which retailers are positioned to compete as AI shopping agents reshape...