Agentic commerce on a marketplace: who is actually selling when an agent buys
OpenAI’s product feed spec asks a marketplace for something it never asks of a single store: separate the seller from the place of purchase. The seller_name and marketplace_seller fields must differ. What follows for data quality, take rate and seller onboarding, on fields checked at source on 30 September 2026.
If you run a marketplace, preparing for agentic commerce is not the same job it is in a store. A store answers for its own offers and its own data. A marketplace answers for other people’s data that it earns on, and has to tell the model the offer is not its own.
Key takeaways
- OpenAI’s product feed spec treats a marketplace as a separate case. The seller_name field names the seller supplying the offer and marketplace_seller names the place where checkout happens, and the two must stay distinct. A single-brand store never faces the problem.
- On a marketplace your weakest seller sets the level, not your average. An agent reads an offer rather than a category, so one supplier with missing availability and a placeholder for a name degrades results for every category they appear in.
- Eligibility is two-stage and can be lost quietly. The is_eligible_search field switches on visibility and is_eligible_checkout adds purchase, but only where visibility is on too. Turning the first off turns both off.
- Take rate defends itself less easily under an agent. A buyer who never browses listings is not paying for the convenience of browsing. A marketplace has to be able to say what the commission buys, rather than assume it buys access to attention.
What to do inside a single store we covered in our piece on preparing your store for agentic commerce. This article is its counterpart for multi-vendor platforms, and it starts with a field that exists only for them, because a single-brand store has nothing to separate: the seller, the catalogue owner and the party taking the payment are one and the same, so the question of who is actually selling never arises.
The spec already separates the seller from the place of purchase
OpenAI’s product feed spec marks nine fields as required on every offer. One of them, seller_name, names the seller supplying that particular offer, and the spec asks for a real brand and seller name rather than a placeholder.
A third-party offer adds a second field. marketplace_seller identifies the marketplace where checkout occurs, and it has to stay distinct from seller_name. A third field, seller_url, should point at the specific seller’s page on a marketplace offer rather than at the platform’s front page.
| Field | Requirement | What it describes |
|---|---|---|
| seller_name | required | The seller supplying the offer. A real name, not a placeholder. |
| marketplace_seller | conditionally required on third-party offers | The marketplace where checkout occurs. Must differ from seller_name. |
| seller_url | optional | The seller’s page. On a marketplace offer: that specific seller’s profile. |
| item_id, title, description, url | required | A stable identifier per variant, plus the basic description of the offer. |
| brand, image_url, availability, price | required | Brand, main image, stock status and regular price. |
| gtin, mpn | optional | Manufacturer identifiers. With many sellers of the same thing, these are what join the offers. |
OpenAI product feed specification, checked at source 30 September 2026.
That is the whole difference in one sentence: a store tells the model "this is mine", a marketplace has to say "this is not mine, but you buy it here". Without that separation the model receives an offer with no credible owner.
One field, and the whole structural difference sits in it.
The gtin and mpn fields are optional, but on a marketplace they do a job they never do in a single-brand store. When ten sellers list the same thing, the manufacturer identifier is the only signal that this is one offer in ten price variants rather than ten different products.
Your weakest seller sets the level for the whole category
In a single-brand store data quality is a function of one team. On a marketplace it is a function of the worst supplier who landed in the same category as your best ones.
An agent does not browse a category, it reads an offer. It compares a handful of specific items and discards the ones it cannot say anything certain about. An offer with blank availability, a seller called "Shop 4521" and no manufacturer identifier is not a worse offer. It is an unreadable one, so it drops out of the comparison.
- Blank or stale availability. The spec allows five states, one of which is "unknown". That state reads as "I am not sure I have this", and an agent picking one item does not pick that one.
- A placeholder instead of a seller name. The spec asks for a real name explicitly. An internal platform identifier in that field breaks a requirement rather than a cosmetic convention.
- No manufacturer identifier on duplicates. Ten offers of the same product with no gtin look like ten different products with suspiciously similar descriptions.
- A returns policy that lives only in the terms page. The accepts_returns and return_deadline_in_days fields are optional, but they carry the information that settles the risk of buying something nobody looked at.
The operational conclusion is an uncomfortable one: a data standard stops being advice to the seller and becomes a condition of being in the catalogue. A marketplace that does not enforce it subsidises the weakest sellers at the expense of the best ones’ visibility.
Eligibility can be lost quietly
Visibility and purchasability are two separate switches in the spec, and the dependency between them runs one way only.
| Field | Requirement | Behaviour |
|---|---|---|
| is_eligible_search | optional | True enables search eligibility. False disables both search and checkout eligibility. |
| is_eligible_checkout | conditionally required | Opts in to purchase, but only where search eligibility is true as well and checkout is enabled. |
OpenAI product feed specification, checked 30 September 2026.
On a marketplace those two flags are set by machine, often by import logic nobody reviews after launch. Switching visibility off across a whole group of offers raises no alert in your admin, because from the platform’s point of view nothing broke: orders still arrive, sellers still list, the sales reports look normal. All that disappears is a channel you are not measuring, and the longer you fail to measure it, the harder it becomes to notice it ever existed.
Practical conclusion: treat eligibility like stock, not like a setting. Something with a report and an alert, rather than something configured once and forgotten.
Take rate defends itself differently under an agent
The classic justification for marketplace commission runs like this: we give the seller access to buyer attention. The buyer arrives, browses, compares and buys, and the platform takes a percentage for having brought them here.
The agent breaks that story at one point. It does not browse. It asks, receives a few offers and picks. It builds no attachment to the interface, returns out of no sentiment, and pays nothing for the convenience of browsing, because it never used it.
That does not mean commission stops making sense. It means it has to attach to something that still works when the buyer never sees the page: settlement, returns handling, guaranteed fulfilment, seller verification. How to set that rate we break down in our piece on marketplace take rate.
Commission for traffic stops defending itself, because there was no traffic.
The second effect is subtler. If an agent compares offers on price and availability, and your platform adds commission that shows up in the final price, you lose to the channel where the same seller sells direct. That is the old price-parity problem, only now settled in a fraction of a second and with no mercy for the brand.
What to do this quarter
The order matters, because the first two items are what make the rest worth doing.
- Separate seller from platform in the data. Check that seller_name carries the real seller name and marketplace_seller carries yours. If both fields hold the same string, the model does not know who it is buying from.
- Make data quality the entry bar. Availability, a real name, a manufacturer identifier and a returns policy as a condition of publishing an offer, not as a request in a welcome email.
- Put measurement around eligibility. A daily "how many offers lost visibility" report and an alert on any step change. Five lines of query, and it catches failures invisible from the admin.
- Check whether models fetch your catalogue at all. Without that the rest is theory. How to measure it from your own logs we described in our piece on measuring AI crawler traffic.
- Recalculate the commission assuming nobody browses. If the rate is justified by traffic rather than by settlement and guarantees, the rate needs a new story.
The technical layer, meaning structured data and what the model actually sees on an offer page, we collected separately in our pieces on structured data for AI and on what an AI agent sees in your store.
Where we sit in this
We build marketplace platforms inside the BEAM framework: Blueprint settles the business model and the data standard before any code exists. On marketplace projects we almost always open with the same question this article opens with: who is the seller, and can your data say so. The scope of that work is described on our marketplace platforms page.
An honest caveat, because this subject invites promises: nobody knows what share of purchases will run through agents, or when. We do not hold that figure and will not guess it. Everything above rests on what the specification requires today, not on a forecast.
If your revenue comes mainly from Amazon or Allegro today rather than from your own platform, this is a conversation about a different problem and a different firm. That is the work of our sister brand, Amazonway. If you are building a catalogue from nothing, our piece on the marketplace cold start problem will be more use.
Want to know how your catalogue looks from the model’s side? Start with the two-field audit described above, and if you would rather we walked it with you, book a Blueprint. We promise no citations and no assistant traffic; we check whether your data lets a model say who is selling at all.
FAQ
How does agentic commerce on a marketplace differ from agentic commerce in a store?
By one distinction the spec enforces directly: in a store the seller and the place of purchase are the same party, on a marketplace they are two. That is why a third-party offer names the seller in seller_name and the platform in marketplace_seller, and the two must differ. Every other difference follows from answering for data you did not create. The single-store version we covered in our piece on preparing your store for agentic commerce.
Which fields are required for an offer to enter the feed at all?
Nine: item_id, title, description, url, brand, seller_name, image_url, availability and price. A third-party seller offer conditionally adds marketplace_seller. The manufacturer identifiers, gtin and mpn, are optional, but where several sellers list the same thing they decide whether the offers get joined or treated as separate products.
Does a marketplace commission still make sense when an agent is buying?
It does, on a different justification. Commission for access to buyer attention defends itself poorly when the buyer never browses listings. Commission for settlement, returns handling, seller verification and guaranteed fulfilment holds up, because those work the same regardless of who is clicking. How to set the rate we break down in our piece on take rate.
How do you lose visibility in an assistant’s search without noticing?
By setting is_eligible_search to false during an offer import. That field disables not only visibility but purchasability too, and your admin reports no error, because from the platform’s point of view nothing broke. That is why eligibility is worth reporting daily like stock rather than treating as a configuration setting.
Where do I start with a marketplace that has hundreds of sellers?
With an audit of two fields across the whole catalogue: does seller_name carry the real seller name, and is marketplace_seller different from it. That is one database query, and it usually shows the problem sits with one group of sellers imported through a single channel rather than across the platform. Only then is it worth working on availability and manufacturer identifiers.
Journal
Co-founder of Seedlight · eCommerce platforms, AI, SEO and GEO
Newsletter
The Journal, straight to your inbox
New articles and lessons from real builds, every now and then. No spam, unsubscribe with one click.
