Your product page has a hero image that took a photographer a day. It has a countdown badge, a reviews carousel, a trust seal row, a sticky add-to-cart and a note that fourteen people are viewing this item.
An AI shopping agent sees none of it.
It sees a price, a currency, an availability flag, a shipping estimate, a variant list and a returns window. Then it compares those fields against four competitors and buys from whichever set of fields wins. No scrolling, no hesitation, no persuasion.
This is not a forecast. OpenAI and Stripe's Agentic Commerce Protocol launched in September 2025 and by early 2026 was processing live transactions for Etsy and rolling out across more than a million Shopify merchants. Google's Universal Commerce Protocol followed in January 2026 with Nike, Sephora, Target, Ulta, Walmart, Wayfair and Shopify brands in the launch group. Payment platforms now advertise support for all of them at once.
The strategic consequence is larger than "add a new sales channel", and almost nobody is talking about it plainly, so here it is:
Agentic commerce is deflationary for persuasion and inflationary for accuracy.
Everything you spend on convincing a human loses value in this channel. Everything you spend on your data being true gains value. That is a complete reversal of where e-commerce budgets have gone for fifteen years.
The three things an agent actually reads
Strip a transaction down and an agent needs exactly three classes of information.
Identity. What is this thing, precisely enough to match it against a request. Title, category, attributes, GTIN or SKU, variant axes. "Blue shirt" is not identity. "Oxford cotton, slim fit, 41cm collar, colour code 04" is.
Commitment. What you are actually promising. Price including tax, in the buyer's currency. Real stock, not a "usually ships" hope. A delivery window with a date in it. A returns policy with a number of days. Any fee that will appear later.
Executability. Whether the purchase can be completed programmatically at all, and under what verification.
That third one is the interesting one, and it is where most integrations will fail quietly.
Declaring what you cannot do is a feature
We build this into our own products, so here is a concrete example from one.
Bronjoy is our appointment booking marketplace for Uzbekistan. In September 2026 it listed 23,727 venues. But most of that catalogue is directory data — real businesses with real addresses and hours, and no online booking. An assistant that assumes every venue is bookable will confidently promise a customer something the platform cannot deliver.
So when we built the marketplace MCP server — the interface that lets Claude and other assistants search and book — every single result carries an is_bookable flag, and the server's own instructions tell the assistant to say plainly when a venue can only be phoned.
That is the design principle most merchants will get wrong. The instinct is to expose everything and let the agent sort it out. The correct move is the opposite: declare your limits in the data, explicitly, on every record. An agent that knows you cannot do something routes around it gracefully. An agent that finds out at checkout produces a failed order, an angry customer and a bad answer about your brand next time.
The verification hole you are about to discover
Here is the other thing we learned shipping that server, and it will apply to you.
Your website is protected by things an agent cannot do. A bot check. A CAPTCHA. A JavaScript challenge. A session built up over several page views. Those controls are not in your business logic — they are in your front end.
The moment you expose a programmatic path to the same actions, all of that disappears.
When we opened Bronjoy's public booking tools, the code-sending endpoint that had been sitting behind Cloudflare Turnstile suddenly had a caller that could not solve a Turnstile. We replaced it with hard limits at the server: 30 requests a minute per caller, 10 phone reveals a minute, 10 verification codes an hour, on top of the existing per-recipient cap. Phone numbers are masked in search results and only revealed through a separate, deliberate call.
And the public server shipped together with a fix to the website. The old guest flow created the appointment first and sent the verification code afterwards — meaning a name and any phone number could put a real booking on a partner's calendar. The verification service now requires the code before anything is written, and the agent tools call that same service. An assistant cannot book on terms a browser could not.
That is the rule worth stealing: the agent path and the human path must enforce identical business rules, in the same place, behind the interface. If your validation lives in your checkout's front end, you do not have validation. You have decoration that has not been tested yet.
What this does to conversion work
Conventional CRO does not die. It moves.
| Where effort used to go | Where it goes now |
|---|---|
| Hero imagery, lifestyle photography | Attribute completeness and accuracy |
| Urgency badges, social proof widgets | Real-time stock and delivery dates |
| Copywriting the product page | Copywriting the product description field |
| A/B testing button colour | Eliminating late-revealed fees |
| Retargeting the abandoner | Not creating the abandonment in the first place |
That last row is not rhetorical. Baymard's 2026 meta-analysis of 50 studies puts average cart abandonment at 70.22%, and the single largest cause among people who intended to buy is extra costs revealed too late, at 40%. An agent does not get surprised by a shipping fee at step four — it reads the total or it does not transact. Every hidden cost you carry is now a structural disqualification rather than a leak. We go through that arithmetic in detail in our piece on checkout.
Meanwhile the same Baymard work finds the average large e-commerce site can gain 35.26% more conversions through better checkout design alone. The overlap between "fixes for humans" and "requirements for agents" is close to total. That is the good news: you are not building two stores.
A field-level readiness check
Protocols are the last 10% of this. Here is the other 90%, as a list you can hand to whoever owns your catalogue.
Identity — can a machine tell your product apart from a similar one?
- A stable identifier that never changes (SKU, and GTIN/EAN where one exists)
- A title that describes the product, not the campaign — "Oxford cotton shirt, slim fit" not "Bestseller! Spring drop"
- The attributes a buyer would filter on, populated on every item, not just the new ones
- Variants modelled as variants of one product, never as separate products
Commitment — is every number you publish actually true right now?
- Price including tax, in the buyer's currency
- Real stock, with a freshness you can state in hours
- A delivery window expressed as dates, not as "fast shipping"
- Every fee that will ever appear, visible before checkout
- A returns window with a number of days in it
Executability — what can actually be completed by a program?
- A flag per item or per venue saying whether it can be transacted or only enquired about
- Business rules enforced on the server, identically for every caller
- Idempotent writes, so a retried request does not create two orders
- Rate limits per caller and per recipient
Work down that list and stop at the first "no". That is your project. In our experience the first "no" is almost always in the second group — the numbers are right on the website because a human is interpreting them charitably, and wrong the moment something reads them literally.
One free diagnostic: export your catalogue to a spreadsheet and sort by number of empty attribute columns. The worst 50 rows are the products an agent will never recommend, and they are usually not the ones you would have guessed.
The uncomfortable economics
Be clear-eyed about what this channel rewards.
If an agent's comparison is over price, availability and delivery date, then in categories where products are genuinely interchangeable, agentic commerce is a margin compressor. You are competing on a spreadsheet, and the spreadsheet does not care about your brand story.
Where it is an opportunity is the opposite case: anywhere the agent's job is matching, not price-shopping. A service with constraints — a time slot, a location, a qualification, a language, an availability window — is not a commodity. The agent's value is finding the one that fits, and the merchant with the richest, truest constraint data wins. That is why booking, local services, specialist retail and anything configured rather than picked off a shelf are the healthy end of this market.
So before you integrate, answer one question honestly: in an agent-mediated comparison, what is the non-price reason you win? If you cannot name one, an agentic channel will accelerate a race you were already losing. Fix the answer first.
What we would build
For most stores the work is unglamorous and sequential: get the catalogue data correct and complete; expose real stock and real totals; make sure every business rule lives on the server, not in the front end; then add the protocol layer.
That is our e-commerce service — headless architecture, a frictionless checkout, an admin your team will actually use, from $499 with a 1–5 week delivery. The catalogue discipline behind it is the same one we apply on Knigopoisk, where a multi-currency checkout only ever offers providers that support the buyer's currency and falls back automatically when one is disabled, and on Finkonkurs, where 120+ scrapers over 40+ providers land in one deduplicated table before anything is allowed to become a fact on a page.
If you want an agent-ready store, the honest first step is not a protocol. It is an audit of whether your product data is true.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Do I need to support all three protocols?
No. Most merchants will get coverage through their platform or payment provider rather than integrating directly — Shopify and the major payment platforms already broker several at once. Your job is the layer underneath: correct, complete, machine-readable product and availability data. That work is protocol-independent and it is the part nobody can do for you.
Will agents kill my brand differentiation?
In commodity categories, yes, partially. In anything with constraints, configuration or service quality, no — those are exactly what an agent needs data about in order to recommend you. The risk is concentrated in businesses whose only differentiator was the shopping experience itself.
Is it safe to let a program place orders?
Only if verification lives behind your interface rather than in front of it. In our own booking marketplace an appointment cannot be created without a six-digit code sent to the customer's own phone or email — valid five minutes, one booking — and the assistant never sees that code. Design for the assumption that the caller is a script, because sometimes it will be.
What about fraud and abuse?
Rate limits per caller, per recipient and per organisation; masked contact data until explicitly requested; idempotent write operations; full audit logging. These are ordinary API hygiene, but most storefronts have never needed them because the browser was doing the work.
How much of this matters for a small store?
The data quality part matters immediately and pays for itself with human customers anyway. The protocol part can wait until your platform offers it. Do not let a big-company narrative talk you into an integration project before your stock levels are accurate.
