Agentic commerce: the architecture, protocols and payments a retailer needs for AI shopping agents

Agentic commerce is shopping in which an AI agent searches, compares and buys on a customer’s behalf, within limits the customer has set. The agent queries retailers’ product data, builds a basket, confirms the total and pays with a credential the customer has delegated, while the retailer remains the merchant of record.

It differs from earlier conversational commerce in one important way: the agent does not just answer questions, it acts. That turns three things retailers have always controlled (how products are presented, how checkout works and who the customer is) into technical interfaces that software has to be able to use.

McKinsey describes three ways the agent and the merchant can meet. Each places different demands on the retailer’s architecture.

Most UK retailers will meet all three within two years. The architecture in this paper is built so that the same product data, commerce services and controls serve every model.

For twenty years retailers have designed for one kind of visitor: a person with a browser. That assumption is breaking faster than most planning cycles allow for.

Sources: McKinsey, “The agentic commerce opportunity”, October 2025; Adobe data reported by TechCrunch, 16 April 2026.

Read together, these numbers describe a valuable new customer arriving at sites that cannot serve it. AI-referred visitors spent longer, viewed more pages and generated more revenue per visit than the average shopper in Adobe’s data, yet a third of product pages are effectively invisible to them. That gap is where market share will move over the next three years.

Search interest tells the same story. Google’s own keyword data shows “agentic commerce” searched tens of thousands of times a month worldwide, up roughly tenfold on a year earlier, with “agentic payments”, “agentic commerce protocol” and “universal commerce protocol” each in the thousands. Boards are asking the question; most technology teams do not yet have an answer.

Take a UK retailer of consumer electronics and home appliances, the kind of business where agents will matter early. Its products are specification-heavy, compatibility questions are common, prices move weekly, and delivery and installation promises decide the sale.

Before designing anything, I would measure. The audit takes three weeks and answers the board’s question with evidence rather than opinion.

The output is a heatmap that shows, by category, where the retailer drops out of the agent journey. In a business like this one I would expect it to look like the exhibit below: reasonable on brand and reviews, weak on structured attributes and offer freshness, and absent on agent checkout.

I design for agents in five layers that mirror the journey in Exhibit 1, with customer identity, commerce operations and governance running across them. The principle is simple: one source of product truth, one commerce layer, many agent channels. Each protocol is an adapter on top, not a separate build.

Agents compare facts, so facts become the product. The PIM holds every attribute a customer might filter on in structured fields rather than prose. A separate live offer service owns what changes by the hour (price, stock by location, delivery and installation slots), and a policy catalogue publishes returns, warranty and delivery terms as versioned data.

The same truth is published wherever agents look: product feeds to the platforms that accept them, server-rendered pages with schema.org structured data for agents that read the web, a protocol discovery profile, and a catalogue search tool exposed over an API or the Model Context Protocol (MCP) for agents that call tools directly. All of it is generated from layer 1, so the channels never disagree.

Checkout is rebuilt as headless services: search, offer, cart, firm quote, order, status and returns. The retailer’s own website and app use the same services, so the rules for price, stock and policy are identical for people and agents. Protocol adapters translate between these services and each agent ecosystem.

The retailer verifies which agent is calling, checks what the customer has authorised, and accepts payment through delegated credentials such as network tokens issued for agents or a payment provider’s shared token. Fraud rules are tuned per agent, because a known assistant with verified users carries a very different risk from an unknown script.

Agent traffic is identified, not filtered. The business tracks visits and orders by agent, how often it appears in answers to its customers’ questions, and every reason an agent journey failed.

Twelve months ago there were no standards for agents buying things. Now there are several, backed by the largest platforms and payment networks. They overlap less than the headlines suggest: each standardises a different part of the transaction.

The practical reading for an architect: ACP and UCP are competing front doors for checkout, AP2 and the card-network programmes sit underneath them for payment, MCP is how tool-using agents reach your catalogue, and Web Bot Auth is how you know who is knocking. Visa’s Intelligent Commerce Connect, announced in April 2026, already accepts payments started through several of these protocols with one merchant integration. That is the direction of travel, and the design should anticipate it. For a detailed comparison, including what happened to ChatGPT Instant Checkout and which protocol to build first, see ACP vs UCP.

UCP makes capabilities discoverable through a JSON manifest at a well-known address. A trimmed version for this retailer shows the idea: one service, a checkout capability with extensions, and the payment handlers it accepts. Field names follow the published UCP samples; values are the retailer’s own.

The manifest is generated from the same configuration that drives the commerce services, so it can never advertise a capability the retailer cannot honour.

The flow that matters most is the one that turns an agent’s recommendation into a confirmed order without a human clicking through pages. Whichever protocol carries it, the retailer’s commerce services run the same steps.

The single most important design decision is that the retailer returns a firm quote: a priced basket including delivery, installation and every mandatory fee, held for a short window and signed by the retailer. It is what ACP calls a checkout session and what AP2 calls a merchant-signed cart. It stops the classic agent failure, a price that changes between recommendation and payment, and it gives the retailer evidence for every dispute.

Three details make this work in production. Amounts are integers in pence, so nothing is lost to rounding. Policy references are versioned, so the retailer can prove which returns terms the customer saw. And every write call carries an idempotency key, so an agent that retries after a timeout can never create a second order.

Agents recover from failures they understand. Every non-success response returns a machine-readable reason and, where possible, a way forward.

Agentic payments raise a question cards were never designed for: the person paying is not the one pressing the button. Three mechanisms have emerged, and a UK retailer should be ready to accept all three through its payment service provider rather than build any of them itself. Each is covered in depth in agentic payments explained.

AP2’s mandate chain is worth understanding in detail, because it is the clearest model of delegated authority so far, and the evidence it creates is exactly what a retailer needs when an agent order is disputed.

UK payment rules still require strong customer authentication (two of: something the customer knows, has or is) for most online card payments, and they assume the customer is present. Agent journeys therefore lean on three approved patterns: authenticate the customer once when they link a card to the agent, so the issued token carries that authentication; use exemptions such as trusted beneficiaries, where the customer has whitelisted the retailer with their bank; and step up with a secure link when risk or value requires it. Liability for an agent buying the wrong thing is not yet settled in UK guidance, which is another reason to keep mandates, quotes and logs that show exactly what was authorised.

Most retailers today cannot tell a customer’s shopping agent from a price-scraping bot. Both arrive as automated traffic, and most bot defences treat them the same. Blocking all of it makes the retailer invisible to agents; allowing all of it invites scraping, fraud and denial of service.

The emerging answer is cryptographic identity on every request. Web Bot Auth, adopted as an IETF working group draft in September 2026, is a thin profile of HTTP Message Signatures (RFC 9421). The agent signs each request with a private key and publishes the public key in a directory at a well-known address. Visa’s Trusted Agent Protocol and Mastercard Agent Pay build on the same foundation, adding payment credentials on top.

The edge verifies the signature against the key published at /.well-known/http-message-signatures-directory on the agent’s domain, checks the timestamps, and maps the verified agent to an access tier. A valid signature proves who sent the request; it does not prove the agent is benign. That decision stays with the retailer’s policy. The implementation detail, including Visa’s Trusted Agent Protocol, is in Web Bot Auth and the Trusted Agent Protocol.

This section is for the architects and engineers who would build it: the product data contract, the data model, offer freshness, latency and capacity. Numbers given here are design starting points to be confirmed in the pilot, not platform limits.

The biggest single lever is the set of attributes every product must carry before it is published to agents. I would define it per category, enforce it in the PIM, and refuse to publish incomplete products to agent channels. A product an agent cannot filter is a product an agent will not recommend.

Published to an agent feed, one product looks like this. Every field is typed and has units; nothing an agent needs is left in prose.

Overnight feeds are the most common reason agents stop trusting a retailer. The design moves to event-driven publishing: when a price, stock level or slot changes in a system of record, change data capture emits an event, the live offer service updates its cache, and a publisher pushes a delta to every agent channel. The checkout always re-reads the live offer, so a stale feed can never cause a wrong price at payment; at worst it causes a re-quote.

An agent comparing several retailers will not wait. Some platforms set their own timeouts; the retailer should assume it has well under a second for search and a little more for a firm quote. Budgeting each hop makes the trade-offs explicit.

Agents generate more requests per order than people do, because they compare. A simple model is enough to size the first release:

The numbers are modest for a modern platform. What breaks first is not raw throughput but slow dependencies, chatty integrations and bot defences that challenge legitimate agents. That is why the latency budget and the access tiers matter more than server count.

Being agent-ready is necessary; being chosen is the goal. The discipline that grew out of search engine optimisation for AI answers, variously called generative engine optimisation (GEO), answer engine optimisation or LLM SEO, applies here, but for commerce it rests on data more than content.

Agents are not consistent about how they rank, and their methods are not published. What every audit shows is that they favour retailers whose facts are complete and verifiable, whose prices match what the agent sees at checkout, and whose policies (delivery, returns, warranty) are explicit. Reviews and brand reputation matter too, but they cannot rescue a product the agent cannot filter. The full playbook and measurement method are in generative engine optimisation for ecommerce.

Letting software spend a customer’s money raises fair questions from the board, the risk committee and the regulator. The answer is not to block agents; it is to model the new threats explicitly and design a control for each.

Selling through an agent does not change the retailer’s obligations; it changes how they are met. These are the rules I would take to legal on day one. This is a design checklist, not legal advice.

Agent commerce does not fit neatly into ecommerce, marketing, IT or payments. In most retailers each owns a piece and nobody owns the outcome. I would create a small permanent team that owns the agent channel end to end, the way marketplaces were handled a decade ago.

Category teams stay accountable for their own product data. The central team sets the standard and reports the gaps; it cannot fix 18,000 products on its own, and it should not try.

The case for acting rests less on new revenue than on demand the retailer will lose if agents cannot use it. The model below frames it. The starting values are working assumptions for a business of this size; replace them with your own and the result updates.

Two points usually change the board conversation. First, most of the spend (product data, live offers, headless commerce services) improves today’s website, apps and marketplaces too, so it is not a bet on agents alone. Second, waiting compounds: agents learn which retailers answer reliably, and early leaders are likely to keep that position.

Ten questions, two minutes. Answer for your business as it is today; the score shows where you sit on the maturity scale and what to fix first.

The order matters. Agent checkout on top of unreliable product data is the fastest way to lose an agent’s trust, so each phase has a gate the leadership team must pass before the next one starts.

Run the readiness audit. Define the data contract for the three categories with the most agent interest (large appliances, TVs and laptops), close the gaps, and stand up the live offer service with event-driven price and stock. Start measuring agent traffic and share of answer so there is a baseline.

Publish feeds to the main agent platforms, make product pages fully readable without scripts, publish the protocol discovery profile and a catalogue tool server, and switch the edge to verify signed agents instead of blocking them. Extend the data contract to every category.

Build the gateway and the quote and order services, go live on the first protocol for a limited set of categories, then add network agent tokens, mandate verification, a second protocol and loyalty linking.

Agentic commerce is where marketplaces and mobile once were: the volumes are still small, the growth is steep and the standards are not settled. That is exactly when foundations are cheapest to build and advantage is easiest to win.

Most of the work is not exotic. Clean, structured product data, offers that are right to the minute, checkout built as services rather than pages, and a clear policy on which agents you trust. All of it makes every channel better, whether or not a customer ever sends an agent.

If I had to leave a retail chief executive with one question, it would be this: if a customer asked an AI assistant tonight for the best product in your strongest category, would it find you, trust your price and be able to buy? Ask it. The answer is the start of the plan.