How I Built a Product Feed an AI Agent Can Actually Read

Last time I wrote about the first thing I got wrong: I treated agent data like a human feed, and a checkout broke in front of me. This post is the other half — what I actually built after that, and how I structure a product feed an agent can read without tripping.

No theory this time. Just the shape that worked.

Start from the agent's questions, not your database

My first version was a dump of my product table. Wrong instinct. An agent does not want your schema. It wants answers to a short, blunt list of questions.

So I started by writing the questions down:

What is this item, exactly?
Is it in stock right now?
What does it cost, and in what currency?
What variants exist (size, colour), and which are available?
Where can it ship, and by when?
Can it be bought right now — yes or no?

Then I built the feed to answer each one. Every field earns its place by answering a question an agent will actually ask. If a field answers none, it does not go in the agent feed. It can live on the marketing page instead.

The shape I landed on

Each product is a small, flat object. Plain facts, clear names, no cleverness. Something like this:

id — a stable identifier that never changes.
title — short and literal. Not the marketing headline.
price and currency — as numbers and a clear code, never "from $20".
availability — in_stock, out_of_stock, or limited. One of a fixed set, not free text.
variants — each with its own availability and price.
shipping — where it ships and a realistic time.
purchasable — a simple true/false. The single most important field.
updated_at — when this record was last checked against the real store.

Two of those did the heavy lifting: purchasable and updated_at. Everything else is detail. These two are the difference between a smooth buy and a broken one.

Fixed values beat free text

A small lesson that saved me a lot of pain: give the agent fixed choices, not prose.

"availability: limited" is something an agent can act on. "Only a few left, order soon!" is not — it is marketing noise dressed as data. So anywhere a field has a known set of answers, I use that set. The agent never has to guess what my words mean.

Freshness is a feature, not a chore

Here is the part most guides skip. A perfect feed that is an hour stale will still break a checkout. Agents act on what you told them, instantly, with no human to catch the mistake.

So I treat freshness as a first-class feature:

Every record carries updated_at.
Stock and price are checked against the live store often, not on a slow nightly job.
If I am not sure a fact is still true, I would rather mark the item not purchasable than let an agent promise it.

A smaller, honest feed beats a big, stale one every single time. I would rather show an agent 500 products I can stand behind than 5,000 I cannot.

How the agent gets the feed

The format matters less than people think, as long as it is machine-clean. I serve the feed as plain structured data (JSON), at a stable endpoint, and I also expose it as tools an agent can call through MCP — so an agent can either read the whole feed or ask "is item X purchasable right now?" and get a straight answer.

The checkout protocols (ACP, UCP) have their own feed shapes too, and I keep my core feed clean enough to map onto either without a rewrite. That is the same lesson I keep relearning: keep your own data independent, then translate to whatever protocol the customer brought.

The short version

If you are building a product feed for agents:

Build it around the agent's questions, not your database.
Use fixed values, not marketing words.
Make purchasable and updated_at your two most important fields.
Keep it fresh, and keep it honest — a smaller true feed wins.

This is exactly the kind of boring, load-bearing work we are building into Sarvex, because when the feed is right, everything above it gets easier. Get the feed wrong, and no protocol will save you.

Next time: what happened when I let an agent run checkout end to end.