When the buyer is an agent: what it demands of your product data

There is a quiet shift under way in who does the buying. The customer still frames the need, but increasingly an agent carries out the purchase: searching, comparing delivery times, checking stock and placing the order. The customer approves. The agent does the work.

That sounds futuristic until you consider what it means in practice. An agent does not browse. It does not click. It does not care about your hero image or how the checkout is designed. It asks your data questions and takes whatever answer it gets.

What an agent actually asks for

Take a concrete instruction: “black trainers, size 38, under SEK 1,000, in stock, delivered before Friday.”

To answer that, the agent needs five things, and it needs them structured:

• product attributes it can filter on — colour, size, category, not just prose in a description
• stock in real time, not a value cached overnight
• the price including the discounts that actually apply to this customer
• delivery windows and lead times, expressed as data
• return and warranty terms it can read mechanically

Miss any of those and the agent has to guess. An agent that has to guess prefers a store that answers clearly.

This is no longer a design question

The common reflex is to treat this as one more interface to optimise. That is the wrong reflex. The centre of gravity moves from UX to protocols, from pages to APIs — and what decides whether you are seen is not how the store looks, but how legible it is.

One way to think about it: it resembles SEO, except that instead of ranking pages you rank data quality. Completeness, freshness, predictability. A store whose API answers the same way every time gets chosen more often than one that is sometimes slow and sometimes wrong.

That makes the question uncomfortable for a lot of merchants. Product data has been allowed to be approximate for years, as long as the page looked right. An agent never sees the page.

Where it usually breaks

In practice it is rarely the API that is missing. It is what sits behind it.

Attributes that exist only in the product description cannot be filtered on. Stock levels synced on a schedule are not real time, whatever the integration is called. Shipping rules living in a separate system cannot answer “delivered before Friday”. And customer-specific prices calculated at checkout do not exist until something is in the basket — which an agent will not do until it has already decided.

These are the same questions that decide whether your product data holds up and whether the ERP integration is built to answer in real time. Agentic commerce does not create those problems. It makes them visible.

Three things to do now

Make the data machine-readable. Move what lives in prose into attributes. Set completeness rules per channel so a half-finished product cannot publish. That work pays off whether the agents arrive this year or in three.

Audit what is real time and what merely looks like it. Stock and price are the two that cost most when they drift.

Publish your terms structurally. Shipping, returns, warranty. An agent that cannot find the return policy treats it as a risk, not a detail.

There is still a human behind the agent

It is worth ending there, because it is easily forgotten. Agents do not replace your customers. They do the work for them.

The expectations remain human: prices that make sense, honest delivery times, terms you can rely on. The difference is that they now have to be expressed so a machine can verify them — and a store that is careless about it does not get a second chance, because it is never presented in the first place.

We have collected our research on this into a report: what agentic commerce is, what the purchase flow looks like when an agent runs it, and what a platform needs in order to answer. You can download it here.