- On 28 September 2026 Shopify extended its WebMCP support to the checkout itself, so an AI agent running inside a shopper's browser can read the checkout, change the delivery option and place the order.
- Amazon and Adidas went the other way in the same period and block agents from completing a purchase, so there is no industry default to follow.
- The WebMCP specification says plainly that it contains no explicit user consent mechanism, which is a weaker guarantee than the phrase buyer authorisation suggests.
- An agent order arrives with thinner evidence behind it, which matters on the day you have to defend a dispute.
- You do not need a platform decision to start. Four things are worth doing this month whatever posture you take.
A shopper asks an assistant to reorder the coffee they bought in July. Until recently that sentence ended at your product page, with the assistant handing the shopper a link and the shopper doing the rest. As of late September it can end at your order table instead, with nobody having touched your checkout form.
Shopify extended its WebMCP support to checkout on 28 September 2026, as TechCrunch reported. Three new tools appeared: get_checkout, update_checkout and complete_checkout. An agent working inside the buyer's browser can now read the checkout screen, change the shipping address or pick a different delivery option, and submit the order once the buyer approves. The rollout covers eligible merchants on the platform, which means a lot of shops had this switched on for them rather than by them.
If you sell somewhere else, this is still your story. Platform decisions of this size set the expectation shoppers bring to every other shop, including yours.
What is a browser agent actually doing at your checkout?
It is calling functions your site published, not clicking pixels. That is the whole technical point, and it changes what you can control.
The older way an agent bought something was to take a screenshot, guess where the button was, and click. WebMCP replaces the guessing with a declared list. The WebMCP specification defines a browser interface where a page registers named tools, each with a description and an input schema, which an agent can then call. A tool has a unique name, a non empty description and an optional JSON schema for its inputs. Registration is restricted to the same origin by default, and a site can turn the whole thing off with a Permissions Policy.
That last sentence is the one to underline. The site decides what exists. An agent cannot invent a tool your checkout did not publish. If your platform exposes update_checkout, agents can change the delivery option. If it does not, they cannot.
What the specification does not do is ask the shopper. In its own words it contains no explicit user consent mechanism, and it does not require users to approve individual tool registrations or agent interactions. The spec also concedes that it cannot define precise mitigation strategies for prompt injection, leaving that to the agent and the browser. Consent, where it exists, is something the agent vendor built, not something the standard guarantees. When a press release says a purchase happens with the buyer's authorisation, that authorisation lives in the agent's interface, and you did not write it.
Is everyone opening up, or is the industry split?
It is split, and the split runs through the same week. TechCrunch noted in the same report that Amazon and Adidas block AI agents from buying on behalf of a shopper, at the moment one large platform opened its checkout to any browser agent that speaks the protocol.
There is a third posture that gets less coverage, and for many sellers it is the more instructive one. Rather than admitting somebody else's agent, several large retailers are building their own inside their own app. Modern Retail reported from Groceryshop that Kroger launched a shopping assistant that builds a basket from context a shopper supplies, including a photo of a handwritten list or a family recipe. Giant Eagle put a recipe generator in its grocery app that scans a meal idea and adds the ingredients to the cart. DoorDash is building order modification tools into its own app, for things like finding a substitute when an item is out of stock.
Kroger's Yael Cosset described the assistant as closing the gap between inspiration and basket shopping. Giant Eagle's stated reason is more concrete: the company says its omnichannel shoppers show 30 percent higher lifetime value than single channel shoppers, so anything that moves a shopper from one channel to two pays for itself.
Read those two stories together and the choice is not binary. You can let outside agents transact, you can keep them out, or you can put the assistant inside your own shop where you own every part of the interaction. The third option is the one a small seller can actually implement without waiting for a platform.
How the three models differ for a seller
The word agent covers at least three arrangements that behave differently in your order data. This table lays them side by side on the question that matters to you, which is what you can still see afterwards.
| Arrangement | Where the agent runs | What you publish | Merchant of record | What lands in your records |
|---|---|---|---|---|
| WebMCP in the browser | Inside the shopper's own browser session | Named tools on your checkout page | You | An order with a normal looking session, driven by software |
| MCP server, server to server | On the agent vendor's infrastructure | An endpoint the vendor calls | You | An order with no browser session of the buyer's at all |
| ACP checkout API | Inside the agent product, calling your API | Checkout and payment delegation endpoints | You, by design | An order plus a delegated payment token |
| Your own in app assistant | Inside your shop | Nothing external | You | A normal order, with the assistant's prompts in your logs |
| Marketplace agent purchase | Inside the marketplace | A product feed | The marketplace, usually | A payout line, not a customer |
That fourth column is the one people skip. The Agentic Commerce Protocol README, maintained by OpenAI and Stripe, is explicit that the standard lets agents facilitate a purchase without being the merchant of record, and that businesses keep the direct customer relationship. Its current stable version is dated 2026-04-17, with the first release dated 2025-09-29. Whatever else agent checkout does to your shop, the current crop of protocols is designed so that you remain the seller, with the obligations that carries. Nobody is taking the returns for you. We went through what that means for your policies in our piece on what agentic commerce changes at the checkout.
Does an agent order look different in your order data?
Yes, and the difference shows up exactly when you need the data most. The order itself looks ordinary. What thins out is everything around it.
Think about what you normally have when a customer claims they never authorised a charge. You have a session: pages viewed, time on the page, a device fingerprint, a typing pattern in the address form, an IP that matches the delivery country. Those are the exhibits. When an agent fills the form, several of them describe the agent rather than the buyer. In the server to server arrangement, the buyer's browser was never involved at all.
This is not a reason to refuse agent orders. It is a reason to record something in their place. If your platform marks an order as agent initiated, keep that flag and keep whatever authorisation reference the agent passed. If it does not mark them, you can often still spot them, because agent sessions tend to be fast, linear and free of the browsing that precedes a human purchase. Tag them yourself and watch the cohort separately for a quarter before you change any policy. The same discipline we recommended for reading false declines in checkout fraud scoring applies here: a new order type needs its own baseline before it can be judged.
Should a small shop open its checkout to agents?
For most independent sellers the honest answer this quarter is that the decision is not yours to make yet, and preparing beats choosing. Very few small shops have the traffic to know whether agent buyers convert better or worse, and the platforms are moving faster than any of us can test.
What is worth deciding now is narrower. Are you willing to accept an order nobody looked at with human eyes, for the kinds of goods you sell? A shop selling a fifteen pound consumable and a shop selling a made to measure sofa should answer that differently. Anything configured, personalised or non returnable deserves a harder look, because the shopper who did not read your size guide is now a piece of software that did not read it either.
The second thing worth deciding is what your returns policy says when the buyer claims the agent got it wrong. Most policies were written for a human who changed their mind. None of them contemplate a shopper saying the assistant picked the wrong variant. You can write one sentence now and save an argument later.
What can you do this month?
Four things, none of which require you to pick a side or wait for a platform announcement.
Find out what your own storefront already exposes. If you are on a hosted platform, agent features may be on by default. Look for the setting rather than assume. Shops that run their own code have the opposite problem, which is that nothing is exposed and an agent will fall back to screen reading. Our guide to deciding which AI crawlers to allow or block on a shop covers the robots side of the same question.
Separate the crawler question from the buyer question. Blocking a training crawler and blocking a shopping agent are different decisions with different consequences, and one control often does both by accident. A shop that blocks everything disappears from the assistants people now ask for recommendations.
Learn how to tell a real agent from something wearing its name. Cloudflare's write up on cryptographically recognising agent traffic describes signed agents, which sign each request with a key whose public half is published, so the edge can verify it rather than trusting a user agent string. The classification launched on 28 August 2025. Verification is the part that lets you allow one agent and refuse another instead of choosing between all and nothing.
Write the returns sentence. One line, in your own words, about what happens when a purchase was placed by an assistant on the buyer's behalf. You will need it eventually and you will write it better today than on the phone to an angry customer.
Why the assistant inside your own shop is the underrated option
Everything above concerns somebody else's agent arriving at your door. The grocery stories point at the other direction of travel, and it is cheaper than it looks.
An assistant that lives on your own site answers from your own catalogue, sees your stock, and never has to guess what a variant means. It also leaves every prompt in your logs, which is the closest thing to free customer research a small shop will ever get. The reason Kroger and Giant Eagle are building rather than renting is that the shopper's context, the recipe, the list, the dietary constraint, is worth more inside the shop than outside it.
The failure mode is well known and worth naming: an assistant that invents products, quotes stale prices or promises a delivery date your system cannot honour. That is a grounding problem rather than a model problem, and it is solved by wiring the assistant to your live catalogue rather than by picking a cleverer model. If you are building a storefront where that wiring matters, our AI ecommerce store builder generates the catalogue and the storefront together, so the assistant reads the same data the shop does.
Agent checkout and agent discovery are separate problems. A shop can be invisible to assistants while its checkout is wide open to them, which is the worst of both arrangements. Getting found is still mostly about clean product data and pages an assistant can read.
What does an agent see that a shopper never did?
Your price next to everyone else's, instantly, without the friction that used to protect small sellers. That is the quieter half of this change and it will outlast the checkout news.
A human comparing five shops gives up around the third. An agent does not get bored. When a shop publishes structured commerce data, whether through a declared tool, a feed or an API, it becomes trivially comparable on the fields it published. If the only fields you publish are price and delivery time, you have entered a competition decided on price and delivery time. If you also publish the things that actually distinguish you, the material, the warranty, the fact that it ships from the country the buyer lives in, those enter the comparison too.
This is a content job more than a technical one, and it is the same job that makes a product page rank. Attributes that exist only in your photography or in a paragraph of prose are invisible to a machine reading a schema. Attributes that sit in structured fields get compared. Most small catalogues have five to ten fields filled and twenty empty, which is a decision nobody made on purpose.
There is a related trap with promotions. An agent asked to buy the cheapest option will find a discount code if one is discoverable, including codes you meant for a specific list. Codes that were quietly tolerated as leaky when a human had to hunt for them behave differently when a machine hunts on every order. Auditing which of your codes are public, stacked or open ended is a dull hour that pays for itself the first time it prevents a margin hole.
None of this is speculative. It is the same discipline as keeping a clean product feed, which we covered when we looked at how AI competitor price monitoring reads a catalogue. The difference now is that the reader might also be the buyer.
What to watch next
Three things will tell you how this settles, and none of them is a model release.
The first is liability. Card networks are building agent aware tokens that carry an agent identifier and a session scope, which would let a dispute be attributed to a specific agent rather than to the cardholder's account. Until that is settled and written into scheme rules, the seller carries the risk on an order the seller did not witness.
The second is whether the protocols converge. Right now a shop can face WebMCP in the browser, an MCP server for vendor to vendor traffic and the ACP checkout API, with a platform specific layer on top. Three overlapping standards is a normal stage, and it usually ends with two.
The third is whether shoppers want it. Retail is full of features that worked technically and nobody used. The grocery assistants are the useful test, because they are being measured against a real number, the lifetime value gap between one channel and two, rather than against a demo.
The short version for a seller with no time
An agent can now finish a checkout on a large platform, other large sellers refuse the same thing, and the specification underneath is more permissive than the announcements imply. Your job this quarter is not to pick the winning protocol. It is to know which of your orders were placed by software, to keep whatever record of authorisation exists, to write one sentence about returns, and to make sure that when you do block something you are blocking the crawler you meant rather than the shopper who was about to buy. Shops that already treat a blocked shopping agent as a business decision rather than a security default will find this an easy quarter.