Agentic commerce is here: what changes for people who work in e-commerce

Two open protocols already define how an agent buys on behalf of a person, and they sit under different custodians. The standards fight is still open, and the architecture decision starts now.

The conversation about agents that shop on their own left the realm of speculation the moment large companies published open specifications to solve the hardest problem in this chain, which is payment authorization.

The specification defines a checkout API and a delegated payment flow in OpenAPI format, plus data models for feed, cart and orders, authentication and MCP integration. It is worth noticing what that list implies for anyone running a store: the feed and the cart, treated until now as an export format, become a public contract, with a versioned schema and declared breaking changes.

The announcement came out with more than 60 partner organizations, including American Express, Mastercard, PayPal, Adyen, Worldpay, Etsy and Salesforce. The makeup of that list says more than the number: it brings together card networks, acquirers, wallets and merchants, which are exactly the parties that need to agree for a payment authorization to be valid at the end of the line.

What the two agentic commerce protocols have in common

Both start from the same diagnosis. An agent that fills out a form by imitating a person does not settle the question of accountability, because nobody can prove afterwards what was authorized. The answer from both is to make the contract between person, agent and store explicit, with a verifiable record.

The difference that matters is who holds the specification. ACP is maintained by the two companies that also run the assistant and the payment layer it runs on. AP2 left Google’s hands and went to an industry foundation. For whoever is deciding architecture, what changes is mainly the expectation of stability and of the specification being captured over the years, with little effect on the code.

The consequence for anyone running a store is direct. Beyond page content, the catalog becomes a transaction interface, with a data contract that needs to be correct, current and available in a format the agent consumes.

Why authorization is the hard problem in this chain

The technically simple part of this chain is getting an agent to fill out a form. That already works, in a fragile way, and has since browsing bots existed. What never worked is proving afterwards what the person authorized.

The current payment system rests on a premise that both protocols need to replace: that someone clicked buy on a trusted screen. That premise is what supports the liability rule in case of a dispute. When an agent starts the transaction, the click disappears, the screen disappears, and the proof goes with them.

That is why both designs revolve around a signed record, with the interface in the background. The mandate exists to reconstruct, months later, what was requested and what was approved. For anyone running a store, the consequence is that compliance becomes a matter of data integrity in the catalog.

What to do in e-commerce now, with no settled standard

While the two protocols compete for adoption, you can work on what holds for both. The four fronts below do not depend on which standard wins, because they all deal with the quality of the data any agent will consume.

• Product data quality. Price, availability, variants, delivery time and return policy need to be true in real time at the source that feeds every channel. A store with an outdated catalog breaks under any protocol.
• The feed as a first-class citizen. The feed leaves paid media territory and becomes discovery and transaction infrastructure.
• Explicit business rules. Shipping, regional restrictions, per-order limits and cancellation policy need to be documented in a machine-readable way.
• The exposure decision. Define which categories and price ranges the company accepts transacting through agents, before the question arrives from legal and sits in their inbox for a quarter.

None of the four is a bet on a protocol. They are baseline conditions the store would need anyway, and they get much more expensive to fix once the integration is already in production.

What changes for platform stores and for fraud prevention

For stores running on a platform such as Shopify, BigCommerce, VTEX or WooCommerce, integration with either protocol will likely arrive through the platform itself and the payment processor, and the store’s work concentrates on the four fronts above. It is worth asking the vendor, in writing, which protocol is on the roadmap and on what timeline, because that answer defines when the exposure decision stops being theoretical.

In markets where instant payment rails carry a large share of transactions, such as Pix in Brazil or UPI in India, the question about those rails needs to be part of the conversation with the processor. A signed mandate has to work with the authorization and dispute rules of instant payments, and that integration is the point to confirm before any pilot.

Fraud prevention moves for the same reason. With an agent in the middle, the behavior of whoever browses the screen disappears as a signal, and the signed mandate becomes the main evidence in a dispute. Keeping those records with the same discipline applied today to invoices and proof of delivery is part of the preparation. What already exists today to identify and filter AI bots and agents at the site’s entrance is in the AI bots guide.

Where SEO fits in agentic commerce

The question that structures the work changes shape. Beyond finding out whether the page shows up in search, it becomes worth finding out whether the offer is understandable and transactable by an agent. Structured markup, consistency across channels and clear policies become operating requirements. On the site side, WebMCP is the proposal that takes this logic to the page itself, with actions exposed as tools an agent can call.