Agentic Commerce Rails Are Shipping: What Changed in 2026.

Platforms have stopped debating whether a software agent can be a buyer and started choosing which rails carry the purchase. The live question is which protocol they speak and which payment credential the agent presents. The releases of the first half of 2026 are where that choice became visible.

Google published retailer tooling and a protocol for agentic shopping on 11 January 2026. Rezolve's trade commentary of 29 January 2026 argued that emerging protocols matter. Adyen launched Adyen Agentic on 16 June 2026, positioned as a translation layer between agents and merchant checkout. Each of those comes from a vendor, so read them as a set showing direction rather than as evidence of scale.

What follows names the four things a purchase needs when no person is present at the moment of submission, then works through each in turn. If the underlying idea is new to you, start with what agentic commerce actually is.

What is an agentic commerce rail, and what has to be true for one to work?

An agentic commerce rail is a purchase path built for a buyer that is software rather than a person. It needs four things a human checkout takes for granted: a machine-readable catalogue, a way to prove the automated client is legitimate, a delegated mandate that lets the agent spend against a payment credential inside stated limits, and a record of who authorised what. Those four components are the spine of everything below.

A public product API, REST or GraphQL, is not a rail. It returns data. Nothing in it establishes that the caller acts for a named customer, carries a spending ceiling, or leaves evidence a merchant could produce months later when the order is disputed. The missing pieces are authority and identity, not endpoints. Whether you expose that data as a protocol or as a plain integration is a separate decision, covered in MCP versus API for ecommerce agents.

The distinction that matters commercially is between an agent that recommends and an agent that transacts. A recommender hands a shortlist to a person, who then buys in the usual way. A transacting agent completes the purchase itself. It retrieves structured offers, such as the Product and Offer types in schema.org. It then filters them against constraints the customer set and presents an identity the merchant edge, usually a CDN or web application firewall, can check. Finally it submits an order against a delegated mandate drawn on a card-on-file credential and receives an order confirmation as a JSON payload rather than a rendered HTML page.

What actually shipped in the first half of 2026?

Between January and June 2026, payments and platform vendors released named agentic commerce infrastructure rather than research previews. Google published retailer tooling and a protocol for agentic shopping on its own blog on 11 January 2026. Rezolve, itself an agentic commerce vendor, published commentary on 29 January 2026 arguing that emerging protocols matter. That claim is only worth making when more than one protocol exists. Adyen announced Adyen Agentic on 16 June 2026 and described it as a universal translator for the next era of commerce. That description puts a payments company at the layer between an external agent and merchant checkout.

The pattern across those releases is what changed, not any single one of them. Each assumes the agent sits outside the merchant and needs brokering: a protocol to speak, a credential to present, or a translator in between. None assumes the merchant builds its own shopping agent.

What the set does not establish is scale. There are no transaction volumes in it, no adoption rates, and no independent measurement of order accuracy. Consultancy publishing covers the same ground without closing that gap. McKinsey wrote on the agentic commerce opportunity in October 2025 and returned to the subject on 29 May 2026. Deloitte published on agentic retail across Asia-Pacific on 30 January 2026. On 4 June 2026, Mirakl surveyed how ecommerce leaders are preparing. Every source named here is vendor-authored or consultancy commentary. This article therefore treats them as signals of direction and says so each time one appears.

Which agentic commerce protocols exist, and how do they differ?

The agentic commerce protocol proposals in circulation differ on one question above all: who holds the payment credential at the moment of purchase. Where that credential sits then determines where checkout runs, what the merchant exposes publicly, and who carries the loss when an order is disputed. No source used for this article names a specification or its sponsor, so the three families below are described by mechanism and deliberately left unnamed. The axes they differ on are set out at length in how the competing protocols differ.

A translation layer earns revenue only while incompatibility persists. Adyen's June 2026 positioning as a translator is therefore evidence that no single standard has won.

The three families ask for different levels of commitment. Structured offer data, item-level accuracy and a documented checkout endpoint are reusable whichever rail wins. Accepting one agent platform's held credential means also accepting its dispute process and its liability position. That changes who the merchant's counterparty is on a failed order, so the commitment is harder to unwind. Anything scheme-specific here is unverified in this article's sources and belongs in a conversation with your acquirer or payment service provider. That includes how 3-D Secure and EMVCo network tokens treat an agent-initiated order, and where any liability shift lands.

An agent cannot buy what it cannot read

The first change most platforms have to make is not payments but catalogue legibility. Price, availability, variant, shipping cost and return terms have to be machine-readable at the item level, in one place, without a rendered page. If an agent has to infer a price from a promotional banner, it will pick the wrong item or skip the merchant.

A transacting agent narrows a shortlist by retrieving structured offers, filtering them on the constraints its customer gave, ranking what remains on total landed cost and delivery date, then requesting checkout for exactly one item. Every field that ranking depends on has to exist as a field. The ones usually missing are consistent: variant-level stock rather than a single product-level flag, shipping cost before checkout, a delivery date rather than a shipping class, and a return window stated as a number of days.

Marketing copy is the wrong surface for a non-human reader, and so is a page that assembles its price in the browser. Structured fields do that work instead: priceCurrency and price on each schema.org Offer, an availability value per SKU, a GTIN so the same item can be matched across merchants, shippingDetails, and return terms as data. The field-level detail of that work is covered in product feeds for AI agents.

Freshness matters as much as coverage. A feed rebuilt overnight cannot support an agent buying at two in the afternoon, because the agent will submit an order against a price and a stock level that expired hours earlier. Google's January 2026 retailer tooling release indicates that the platforms are defining feed requirements. It does not tell you which fields your own feed is missing.

This work is protocol-independent, which is why it is the safe place to start.

Most merchants currently block the buyers they want

A legitimate shopping agent and a price scraper arrive looking almost identical, and bot mitigation treats automated clients as hostile by default. Serving agents therefore requires a way to tell the two apart. That verification problem is the one the announcements tend to skip.

Current defences key on request rate, user-agent string, IP reputation and challenge responses. A well-behaved agent trips most of them. It requests many items quickly because comparison is its job, it arrives from cloud address space, and it cannot solve a CAPTCHA.

Four identification options exist and each costs something. A published user-agent string verified by reverse DNS lookup is cheap, and the ownership check limits how far a forged string gets. Request signing proves control of a key on every request, at the cost of key distribution and rotation. Allowlisting by commercial agreement is the most reliable and the most political. Per-agent credentials give the merchant rate and scope control per client, at the cost of running an onboarding process.

The mechanism is the same in every case. The client asserts an identity, the merchant edge verifies that assertion cryptographically or by ownership lookup, then applies a rate limit and scope policy for that named agent instead of a blanket block. Seeing which clients arrive in the first place is a matter of reading your own server logs.

Allowlisting deserves a second look, because choosing which agents to allow hands distribution power to whoever ends up on the list. Note also who owns the decision. The controls sit in the web application firewall and the robots.txt file, which usually belong to security or platform engineering rather than to the ecommerce team that will be measured on the revenue.

Who authorises the payment when the buyer is an agent?

A human still authorises the purchase, but earlier and in more general terms. The customer grants the agent a mandate with limits, and the agent spends inside it. The merchant then accepts an order no person clicked to confirm. That moves the interesting questions from authentication to scope, evidence and liability.

A delegated mandate specifies an amount ceiling, a merchant or category scope, a validity window, and whether it covers one purchase or repeats. Authorisation then runs in a fixed order. The customer authenticates once and issues the delegated mandate, the agent presents that mandate or a network token derived from it, the issuer authorises against the scope, and the merchant receives a transaction flagged as agent-initiated rather than customer-present.

Strong customer authentication, mandated in Europe under PSD2, is the part that visibly moves. It happens at mandate issuance, when the customer is present, rather than at purchase, when nobody is. The merchant therefore never sees a challenge on the order itself and depends on the agent-initiated flag and whatever evidence the rail carries with it.

That evidence is what a merchant has to keep. A defensible record of an agent order holds the mandate reference, its scope and expiry, the identity the agent asserted, the offer data the agent was shown, and the confirmation returned to it. Retain those and a chargeback is arguable. Retain only an order row and it is not.

The open question is who carries the loss when nobody misbehaved. An agent misreads an instruction and buys the wrong variant, or retries and buys twice. The customer did not authorise that purchase in any meaningful sense, the merchant shipped in good faith, and the issuer authorised inside a valid scope. Adyen's June 2026 launch shows payments vendors positioning at exactly this layer. That launch is a vendor announcement rather than a settled answer. No source used here establishes whether current scheme rules place that loss with the merchant, the agent platform or the issuer.

Merchandising loses its audience when an agent does the choosing

When an agent shortlists on structured price, availability and delivery data, the merchandising surface a brand spent a decade tuning is not in the loop. Differentiation moves to the attributes an agent can read.

The levers that survive are the ones that exist as fields: total landed cost, a delivery date the merchant actually meets, a return window stated in days, variant-level stock accuracy, and attributes precise enough to win a filter. The levers that do not survive need a human eye: banner placement, on-site recommendation carousels, page layout, and most promotional storytelling. The only version of the offer an agent sees is the number in the feed, so a promotion stops being a creative brief and becomes a pricing problem.

The counterweight is category-dependent. McKinsey's 29 May 2026 commentary on luxury argues that desire and human-centred experience still decide considered purchases. That is consultancy opinion rather than measurement, but the boundary it marks is real. Where the customer insists on choosing, agents research and then hand over. Where the customer wants the same product delivered on Thursday, they do not.

What is still broken

No agentic commerce standard has settled, no public evidence shows agent purchase volume at scale, and the post-purchase half of commerce is barely addressed.

The standards risk is concrete. A merchant that wires up one rail this quarter may rebuild it. A translation layer between protocols is a recurring cost rather than a resolution. Protocol version pinning makes the rework visible when the version moves, instead of surprising you in production. That is the practical hedge.

The evidence gap is worse. Every source available for this article is a vendor announcement or a consultancy thought piece. Not one reports independent adoption figures, agent order accuracy, or dispute rates on agent-initiated orders.

The failure modes are easy to name and largely unaddressed in the releases: the wrong variant selected from an ambiguous feed, an order placed against a stale price, duplicate orders when an agent retries, and a return authorised by an agent the customer has stopped using. Returns authorisation and dispute evidence both assume a contactable human who remembers agreeing.

Two things would count as real evidence: independent parties publishing agent order volumes and accuracy rates, and a scheme stating in writing where the loss sits on a disputed agent order. The full catalogue of what stays broken, in the order it reaches a cost base, is in where agentic commerce still breaks.

What to check this week

Three agentic commerce readiness checks, each with a named owner, all useful whichever protocol wins.

Your ecommerce lead should pull your own product feed and confirm that total landed cost, delivery date, variant-level stock and return window are all present at item level. Whoever owns the edge, usually security or platform engineering, should check what your bot mitigation does today to a well-behaved automated client, because that behaviour is your current answer to agents. Your payments lead should write down who would carry the loss on a disputed order no human confirmed, then ask your acquirer whether that is actually true. How much of this you control at all depends on the platform underneath, and the sequencing is set out in what ecommerce platforms must change.

Revisit any protocol commitment when two independent parties publish agent order volumes instead of launch posts.

Nothing in the current releases settles the standard, so the work that survives whichever protocol wins is the work worth doing this quarter.