AI “agents” are increasingly acting autonomously when purchasing on behalf of their humans. For online merchants and marketplaces, this shift raises the strategic question: where in the value chain do you want to sit when software starts owning the customer journey?

Less browsing, more briefs to agents

The core behavioural change is simple. Instead of visiting a website and clicking through categories, the customer briefs an assistant: “find me a pair of running shoes under £120, delivered by Friday, from brands I like”. The agent does the rest—searches, filters, compares, and presents a small set of options, or in some cases simply completes the purchase within pre‑agreed parameters.

That changes the job of the merchant. Optimising human UX is still necessary, but it is no longer sufficient. Agents care less about your beautiful homepage and more about whether they can query your range, prices, stock, delivery promises and policies through clean, reliable APIs. If your catalogue data is incomplete, inconsistent or locked behind presentation logic, you risk becoming invisible to the very entities that are now deciding where demand goes.

For marketplaces, this is amplified. The historic advantage has been aggregated supply and a reasonably good search experience. In an agentic world, the marketplace has to prove it can provide structured, high‑quality data for thousands of sellers and then expose it in a form that agents can consume and trust.  That is a very different optimisation problem.

Protocols are quietly rewiring the stack

Under the surface, a set of protocols is emerging to make agentic commerce interoperable rather than bespoke. Two are particularly relevant for merchants and marketplaces:

– Agentic Commerce Protocol (ACP) focuses on how agents interact with storefronts: discovering catalogues, querying availability and pricing, and invoking checkout flows in a standard, machine‑readable way. It turns what are today idiosyncratic APIs and scraped pages into predictable endpoints that any compliant agent can work with.

– Agent Payments Protocol (AP2) focuses on how agents get permission to pay, using mandates that define which merchants can be paid, for what, and within which limits, then routing those payments across existing rails.

Together, ACP and AP2 change the interface boundary. Instead of designing just for browsers and apps, you are increasingly designing for agents that speak in terms of products, constraints and mandates. That changes where you invest engineering effort and how you think about “being available” in the market.

 Who owns the customer relationship?

 The more decisions agents make, the more they look like a new class of intermediary. If a small number of agent platforms, wallets and super‑apps sit between customers and merchants, they become the gatekeepers to demand—much as app stores and dominant marketplaces have in earlier cycles.

For merchants and marketplaces, the implications are clear:

– Margin pressure in commoditised categories.  Agents can arbitrage small differences in price and service at scale. Where products are substitutable, they will happily switch suppliers when a cheaper or better‑rated option appears.

– Increased dependency on new “platforms”. If most of your high‑intent traffic originates from a handful of agent providers, they will have the leverage to impose data requirements, preferred commercial terms or additional fees.

Payments: orchestration, not revolution

On the payments side, much of the underlying infrastructure remains the same. AP2 and related initiatives are being positioned as orchestration layers that sit on top of existing card, bank and wallet rails rather than replacing them. The pattern is that customers grant an agent a mandate to spend within defined limits (merchants, amounts, time windows), and the agent then uses network or wallet tokens to initiate the transaction when needed.

Issuers and acquirers see additional “agent‑present” signals in the authorisation stream and can adjust fraud controls, apply different risk rules and trigger step‑up authentication via the customer’s wallet or banking app if something looks unusual. For the merchant, the main change is not who processes your payments, but:

– Ensuring gateways and PSPs can handle AP2‑style mandates and tokens.

– Updating fraud and chargeback processes so that agent‑initiated transactions are recognised as a distinct context, not just generic card‑not‑present traffic.

For API‑centric or usage‑based businesses, there is also innovation around HTTP‑native, on‑chain payment protocols (such as x402) that allow agents to pay per request in stablecoins, particularly for micro‑transactions and machine‑to‑machine flows.

Agentic commerce will not replace traditional e‑commerce overnight. But the direction of travel is clear: more discovery, decision‑making and execution will be mediated by software agents. Merchants and marketplaces that treat those agents as real counterparties—entities to be integrated with, negotiated with and measured—will be better placed than those that wait for the new intermediaries to define the rules on their behalf.