This note has an interactive demo. Try it in the original
I have a hunch I can't shake: when an agent buys things for you, you stop caring where it buys them.
Today you open Amazon out of habit. Your card is saved there, along with the app, the search and the trust that the parcel will show up. But an agent has no habits. It doesn't open the usual app. You ask for something and it looks for the best place to get it. If that happens at scale, a marketplace's biggest asset, being the place where shopping starts, gets weaker.
That's why I think brand stores are coming back. If the agent hunts for the best price, and selling to you directly is cheaper for the brand because it pays no commission, that's where the agent will end up sending you. And someone will have to build those stores. There will be work for developers.
The demo above is a toy for thinking about this: three shops, a simulated agent, and you moving price, commission, shipping, returns and whether the data can be read. Try switching off a shop's readable data and see what happens.
What's already happening
This part is facts, not opinion.
- Meta introduced Muse on September 8, 2026, a personal agent that can do tasks for you, shopping included. According to Meta's announcement, it's rolling out in the US (iOS, Android and the web), checks out with Link by Stripe, and asks you before sensitive actions like making a purchase.
- Google launched the Universal Commerce Protocol (UCP) on January 11, 2026, an open standard for agents to buy from stores, developed with Shopify, Etsy, Wayfair, Target and Walmart. Today the protocol's official site also lists Amazon, Meta, Microsoft, Salesforce and Stripe among its co-developers.
- OpenAI and Stripe have their own protocol, the Agentic Commerce Protocol (ACP), announced in September 2025. Stripe's documentation now describes it as created by Stripe, OpenAI and Meta.
The most telling part is how Amazon reacted. PCWorld reports that it has blocked Muse from its website. And it sued Perplexity over its Comet browser: a federal court in California granted Amazon a preliminary injunction on March 9, 2026, and the Ninth Circuit Court of Appeals vacated it on August 4. The court makes a point of saying it does "not establish a new legal regime governing agentic AI" and that its holding is limited to this case and the record in front of it.
Nobody fights this hard over something that doesn't scare them.
Where I think I could be wrong
"The death of marketplaces" sounds great, but I'm probably overstating it.
Amazon isn't just a search box. It's logistics, no-questions-asked returns and millions of reviews. A good agent doesn't compare price alone: it compares when the thing arrives and what happens if it goes wrong. A marketplace still has a lot going for it there. You can see it right away in the demo: switch the priority to "Get it now" and the marketplace wins even though it costs more.
We might just swap one middleman for another. If the agent decides for you, the agent becomes the new shop window. And whoever controls that recommendation will have a lot of power over brands, just like the marketplace does today.
A small brand won't show up on its own. If the agent can't read your stock, your price and your terms, you don't exist to it, however nice your website looks.
What "machine-readable" means
In practice, it means price, shipping and returns are written down as data, not just inside an image or behind an "ask us". One way to do that today is the schema.org vocabulary in JSON-LD. It's what the demo shows when you open "What the agent reads":
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Wireless headphones",
"offers": {
"@type": "Offer",
"price": 76,
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"shippingDetails": {
"@type": "OfferShippingDetails",
"shippingRate": { "@type": "MonetaryAmount", "value": 4, "currency": "EUR" },
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"transitTime": { "@type": "QuantitativeValue", "minValue": 3, "maxValue": 3, "unitCode": "DAY" }
}
},
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 30
}
}
}
It's not the only piece. Protocols like UCP and ACP go further and cover payment too. But the underlying idea is the same: if a machine can't read your terms, it can't pick you.
What I am sure about
I don't think marketplaces will die. I think they lose their monopoly on the front door, and that alone changes a lot.
And yes, there will be work, but not the usual kind. It won't just be about making pretty pages. A store will have to be easy for a machine to understand: a well-structured catalog, real stock, clear prices, readable shipping and return terms, and a checkout an agent can complete. Getting that right is technical work, and many older stores aren't ready for it.
It's true that agents write code too. But wiring up a business's real stock, its carriers and its returns is still a job someone has to understand and answer for.
If you run a store, my advice is simple: don't leave the marketplace, but don't depend on it alone. Have your own store, with your data in order.
What to keep an eye on
- Whether Amazon, which is already listed among UCP's co-developers, ends up opening its store to other companies' agents or keeps blocking them.
- What commission agents charge per sale.
- Whether agents really recommend the brand or only whoever already has deals with them.
If you're wondering how to get your store ready for this, write to me and we can talk it through.
Richi's opinion, written with AI help.
Sources
- Introducing Muse (Meta)
- Under the Hood: Universal Commerce Protocol (Google for Developers)
- Universal Commerce Protocol (official site)
- Agentic Commerce Protocol (Stripe docs)
- Amazon.com Services v. Perplexity AI, No. 26-1444 (Ninth Circuit, PDF)
- Meta's Muse AI assistant was born to shop (PCWorld, press)
Originally published at richi.codes.
Top comments (1)
The "small brand won't show up" point is right, and nothing below touches it. Stock, price and terms have to be readable before an agent can consider an offer at all. What interests me is the next question, which is what readability buys once an offer is over that floor. Different domain, so discount accordingly: the numbers come from a signed append-only log of agent-to-agent capability offers that I work on, where the goods are services rather than headphones, but the offers carry prices and the buyers are agents.
Readability turned out to be the easy part there. A
pricefield is present on 1,973 of 1,983 signed capability declarations. Of 27 distinct capability types that got declared, 25 were never requested even once, and 1,862 of the 1,865 requests that did arrive named the same single capability string. The supply side was almost perfectly machine-readable and almost entirely unread.The cost structure is what I would watch if I were designing one of those commerce protocols. On that log, publishing a declaration is free, while making a request carries mandatory proof-of-work, and only 3 of 1,988 declaration rows bothered with proof-of-work voluntarily. Anyone worried about an agent-facing catalogue filling up with junk offers should notice which side of the exchange is being charged.
Signing the offer helps less than it looks. The byte-identical body
{"capabilities":[{"name":"transform.text.demo"}]}sits on 6 rows signed by 4 different keys, all 6 verifying, each with a distinct and perfectly valid id (the id's preimage includes the key, so republishing a body always yields a fresh legitimate one). I want to be careful about what that shows. A one-line body like that can be arrived at independently, and those keys may well belong to a single setup, so the finding is only that the signed fields fail to separate those cases. It is no evidence that anyone copied anything.One more trap, for anyone tempted to write an offer-integrity rule. A proposal on that log asked for three things: a declared input type other than "none", an output schema that parses, and a signature covering the schema digest. It qualified 0 of 1,983 rows. The first two conditions passed 850 and 161 rows and are satisfiable by writing better content. The third could never pass, because the signed tag vocabulary on that row type has exactly four names and no slot for a digest. A publish-time rejection citing it would be a message nobody could act on. Positive control:
digestis a name that log does know, with 4 applications, all of them on request rows and none on declarations.Which is why the schema.org Offer suggestion reads as right but incomplete to me. JSON-LD is an unsigned self-assertion, and signing it buys attribution to a key rather than authorship of the offer. The cheap instrument sits on the consumption side: for each offer field you emit, count how many incoming agent requests actually filtered on it, and print that count next to the emit count. Both of the findings above came from putting those two numbers side by side.