Agentic Commerce: What Ecommerce Platforms Must Change.

Supporting an AI agent as a buyer comes down to three changes: letting a machine read the catalogue, deciding which machines are welcome, and letting someone other than the cardholder authorise a payment. Everything else in agentic commerce is a consequence of those three.

Payments and platform vendors shipped products for agent-driven purchasing through the first half of 2026, including Google's January 2026 release of retailer tooling for agentic shopping and Adyen's June 2026 launch of Adyen Agentic. Trade coverage in January 2026 points to more than one competing agent-to-merchant protocol. The live question is no longer whether platforms will support agent-driven purchasing. A dated account of those releases is in agentic commerce rails are shipping.

This article describes what changes and what does not work yet, without recommending a vendor. It concedes at the outset that measured outcome data is not publicly available.

What does a platform actually have to change to let an agent buy?

Three things. The catalogue has to be readable by a machine that never renders a page, bot mitigation has to distinguish a shopping agent from a scraper, and the payment flow has to accept an authorisation the cardholder delegated rather than performed. They arrive in that order as the buying journey moves from discover to access to pay.

Each sits in a system the marketing team does not control: the product data pipeline, the web application firewall, and the checkout and payments stack. That makes each a platform change rather than a marketing change.

An agent's request path differs from a browser's in three ways that matter. It usually executes no JavaScript, so anything a page assembles in the browser is absent. It has earned no session cookie through human interaction, so bot mitigation keyed on interaction signals sees nothing. And it holds no card-on-file of its own, so the credential it presents belongs to a cardholder who is not there.

Making one change without the others fails quietly. A machine-readable catalogue behind a blocking firewall is invisible. A reachable catalogue with no delegated payment path produces an agent that compares, selects, and then abandons at checkout.

The rest of this article takes each of the three in turn, then the protocol question, merchandising, the failure modes nobody has solved, and what to sequence first.

How do catalogues and feeds have to change for an agent to compare items?

An agent needs price, availability, variant, and identifier data it can read without rendering a page. That makes the product feed and the on-page structured data the product experience rather than a copy of it.

Comparing two products requires a stable identifier such as a GTIN or a SKU, a unit price, current stock, variant attributes such as size, colour, and material, and the shipping and returns terms that decide total cost. The schema.org Product and Offer types carry price and availability properties on the page. Product feed specifications carry the same fields in XML or delimited files. Both are parallel machine-readable representations of one catalogue. When they disagree, the agent has no way to tell which is right. It acts on whichever one it read.

Data is effectively absent if it exists only in rendered HTML, in an image, or in a design element. A delivery promise drawn in a badge, a discount applied in the basket, a returns window written into a footer template: none of it reaches a client that reads the feed and the markup. The same discipline that makes a storefront legible to LLM crawlers is what makes it legible to a buying agent.

Freshness is the hard part. A feed refreshed nightly misprices anything that moved today, and an agent will commit a real order at that price.

Attribute completeness becomes the new merchandising surface. An agent filtering on a field you left blank excludes you silently, with no message and no chance to compete on the attributes you did fill in. Which fields those are, and what breaks without each one, is set out in product feeds for AI agents.

On 11 January 2026, Google published tooling for retailers preparing for an agentic shopping era. That indicates where at least one large platform expects this work to sit. Read it as a vendor announcement rather than as proof of a requirement.

How does a platform tell a shopping agent apart from a scraper?

Mostly a platform cannot tell them apart yet, which is why bot policy is the change merchants are least prepared for. The defences built to stop price scraping and credential stuffing block a shopping agent in exactly the same way, for exactly the same reasons.

Bot mitigation keys on request rate, headless browser signatures, missing human interaction signals such as mouse movement and dwell time, and IP reputation. A legitimate shopping agent trips all four. It requests many product pages quickly, runs headless, produces no interaction telemetry, and often arrives from cloud address ranges that reputation scoring treats as suspect.

Four identification options are in current use. A client declares itself in its user-agent string, which anyone can copy. An operator publishes its IP ranges and supports reverse DNS verification, which is checkable but ties the agent to fixed infrastructure. Requests carry a signature the merchant verifies against a published key, which proves origin. Or the merchant allowlists a named counterparty by commercial agreement, which is enforceable and does not scale.

Declaration alone is unenforceable, and that creates an asymmetry. Anyone can claim to be a shopping agent. The cost of a wrong allow is paid in scraped pricing rather than in a failed purchase. Opening a route for agents pulls directly against keeping scraping protection on that same route. The robots.txt file does not resolve this, because it states a preference that only compliant clients read. Deciding which clients you actually let through starts in the same place as reading bot traffic out of your own server logs.

The decision belongs to security and fraud teams before it belongs to commerce, which is the main reason it stalls.

How does payment work when the buyer is an agent rather than a person?

The agent never holds the card. It holds a scoped, revocable authorisation from the person who does. Two questions remain open: who bears the loss when the agent buys the wrong thing, and how the merchant proves the authorisation existed.

Delegated authority is the core idea. The cardholder issues a mandate with limits: a maximum amount, a merchant or category, a time window, and often a single intended purchase. The credential the agent presents is normally a network token rather than a card number, scoped so it cannot be replayed at another merchant.

The merchant receives evidence of that mandate rather than a card number alone, and must be able to record it. The order record has to include whether the order was authorised, by whom, under what limits, and at what time, because the alternative is defending a dispute with nothing.

Liability is unresolved. To a chargeback process, a purchase the cardholder did not directly approve looks much like one they did not make. The available reason codes describe fraud and non-delivery rather than an agent that misread a specification.

Strong customer authentication regimes, including PSD2 in Europe and the 3-D Secure flows built to satisfy it, assume a human present at checkout who can answer a challenge. An agent buying at three in the morning cannot. The exemptions written for recurring and merchant-initiated transactions were not designed for a third party acting on a one-off instruction.

Adyen announced Adyen Agentic on 16 June 2026 and positioned it as a translation layer between agents and merchant checkout. That is a press release rather than a finding. What it tells you is where a payments vendor believes the bottleneck sits.

Why does it matter that more than one agent-to-merchant protocol exists?

The cost of picking the wrong agent-to-merchant protocol falls on the merchant. Competing protocols mean integration work that may need redoing, which is why translation layers appeared as products before any standard settled.

At minimum, an agent-to-merchant protocol has to specify five things: how an agent queries the catalogue, how it proves its identity, how it places an order, how a payment mandate is handed over, and how order status, cancellations, and returns come back. A protocol that omits one of those pushes it into custom work with every counterparty.

Competing protocols differ on four dimensions rather than on detail. Who holds the payment credential, the agent or the merchant. Whether checkout happens on the merchant's surface or inside the agent's interface. How agent identity is verified, by declaration, by signature, or by agreement. And who owns the resulting customer record, which decides whether the merchant learns anything about the buyer at all.

That last dimension is a commercial question in technical clothing. A protocol that keeps checkout inside the agent's surface keeps the customer relationship there too.

Trade coverage in January 2026 includes a vendor blog, dated 29 January 2026, arguing that emerging protocols matter. That coverage is useful mainly as evidence that more than one protocol exists. Treat it as that and nothing more. The underlying choice between a protocol and a plain integration is the same one covered in MCP versus API for ecommerce agents, and the vocabulary is collected in the agentic commerce glossary.

For a decision-maker, the read is sequencing rather than selection. Do the work every protocol depends on, and postpone anything that encodes one counterparty's assumptions. The four axes the competing protocols actually differ on, and which commitments reverse, are compared in how the agentic commerce protocols differ.

What happens to merchandising when an agent does the choosing?

Persuasion moves out of the interface and into the data. An agent comparing options never sees the hero image, the trust badge, or the urgency banner the merchandising team spent the quarter on.

The levers that survive machine reading are the ones expressible as fields: unit price, total landed cost including shipping and tax, stock position, delivery date, returns window, warranty terms, and structured review markup carrying a rating and a count. The levers that do not survive are layout, imagery, copy tone, interstitials, and most on-site promotion mechanics. A banner is invisible to an agent. A discount already reflected in the offer price is not. Machine-readable terms beat presentation, and a code the shopper has to apply competes badly.

Categories that compete on specification lose little. Categories that compete on brand lose the surface they compete on. Premium positioning is hard to express in a feed field, and an agent optimising on landed cost has no field for desirability. McKinsey raised this tension in a piece on human-centred luxury in the agentic age, published on 29 May 2026. It reads as a question about where brand experience survives rather than as a measured effect.

For category and brand managers, the practical consequence is that attribute coverage stops being an IT chore and becomes a merchandising decision. How much of the work is yours to do at all depends on the platform the store runs on, since a hosted checkout and a managed feed hand you some of it and withhold the rest.

What is still unsolved?

Returns, disputes, order accuracy, and the absence of a settled agent-to-merchant standard are all unsolved in agent-driven purchasing, and none of them has a documented answer. The honest read of current announcements is that the buying path works before the aftermath does.

Returns and cancellations have no agreed owner. Three questions are open: whether the agent initiates the return, whether customer service contacts the agent or the person, and whose account the refund lands in. Each answer implies different work in the order management system.

Disputes inherit the same gap. A chargeback process that assumes a human buyer meets an order no human placed directly, and the reason codes do not describe that situation.

Order accuracy costs money soonest. An agent acting on a stale feed commits a real order at a wrong price, or against stock that is gone. The merchant either honours it or cancels it and absorbs the consequence.

Evidence quality is itself a limit. Nearly every current source is a vendor announcement or a consultancy thought piece, so the volume of coverage overstates how settled this is. Measured data on agent-driven order accuracy, return rates, or dispute rates is not publicly available, and this article does not have it either.

The pattern across all four is that the failures surface after purchase, in the systems least likely to have been changed. Each of those failure modes, and where its cost lands, is set out in where agentic commerce still breaks.

What should a merchant do now, and what should wait?

Do the work that pays off whichever protocol wins, and wait on anything that commits you to one agent payment rail.

Now: shorten the feed refresh interval until it matches how often your prices and stock actually move, fill the attribute fields an agent filters on, and check that the on-page structured data agrees with the feed rather than assuming it does. Also now: decide explicitly which automated clients may reach the catalogue and how they are verified, instead of leaving it to a rule written against scrapers. And name an owner for the agent question across commerce, security, and payments, because it currently falls between all three.

The general test: work that improves machine-readability is durable, and work that encodes one counterparty's assumptions is not.

Where to start

Audit the product feed and the on-page structured data for your top-selling 200 SKUs against four fields an agent cannot buy without: current price, current stock, variant identifier, and returns terms. Separately, ask whoever runs bot mitigation what a declared shopping agent hitting the catalogue today would actually receive. Do it before evaluating any agent payment integration, because a feed that misprices and a firewall that blocks make the integration question moot.

The owner is the person accountable for the product data feed, jointly with whoever owns bot mitigation. The gap between those two people is where this work stalls.

Two of the three changes are worth making now, because they pay off whichever protocol wins. The third is not, and knowing the difference is the whole decision.