What Agentic Commerce Needs From Your Store

An AI agent completing a purchase for somebody is a different customer from a person with a browser, and it wants different things from your store. If you have read what agentic commerce is, this is the practical follow-up: what an agent actually needs at each step, and which of those things your store probably already fails at.

The useful frame is the journey, from the moment an agent is looking for something to the moment an order exists. There are four steps and they get harder in order.

1. Discovery: your product data has to exist outside your templates

An agent cannot read your product page the way a shopper does. It needs the facts: what the thing is, what variants exist, what each costs, whether it is in stock, and what it may not be shipped to.

If the only complete description of a product lives in the HTML that displays it, you have nothing to give. This is the step most stores fail, and it is worth noticing that failing it also costs you today, in shopping feeds, in search results that could carry structured data, and in your own reporting.

The test: can you get your full catalog, with variants and stock, out of your store as data, with one call you could write yourself? If that takes an export, a spreadsheet and an afternoon, an agent cannot do it at all.

2. The cart: state an agent can hold

A person keeps a cart in a browser session. An agent is not in a browser, and may be working on behalf of somebody who is not currently looking at anything. The cart has to be a thing on the server with an identifier, not a cookie.

Most API-first backends already work this way, because a headless storefront has the same requirement for the same reason. If your cart cannot be created, read and modified over HTTP by something that is not a browser, this step blocks everything after it.

3. Checkout: the hard one

This is where the protocol work is concentrated, and where the honest answer is that nobody has finished. TheAgentic Commerce Protocol, the open standard Stripe, OpenAI and Meta published under Apache 2.0, defines checkout sessions an agent can create and complete, and a way to pass a payment credential between the buyer, the agent and the business so the agent never handles a raw card number.

Two things follow from that. Your checkout has to be drivable from outside a browser, which is the same requirement as step two. And your payment setup has to be able to accept a delegated credential, which is a question for your processor rather than for your storefront.

Worth being clear: dashfordevs does not implement ACP today. There is no agentic checkout endpoint in the API. What exists is the substrate the protocol assumes, which is a checkout your code drives rather than a page we render for you. If that changes it will appear inthe documentation and onthe roadmap before it appears in a post like this one.

4. After the order: telling somebody what happened

An agent that completed a purchase needs to know when it shipped, when it arrived, and if it was refunded. That is webhooks, and it is the step stores tend to have already, because the same events drive their own emails.

If your order lifecycle already emits events something else can subscribe to, this step is done.

What about hosted platforms?

A reasonable question, since most stores are on one. Hosted platforms are adding agentic features, and being on one is not a barrier in itself. The difference is who decides and when: on a hosted platform, agentic checkout arrives when the platform ships it, in the shape the platform chose. On an API-first backend it is work you can do yourself against a public specification. Neither is automatically better, andthe wider comparison is a separate argument.

The part worth doing now

Not much, urgently. The spec is versioned and moving and the number of buyers completing purchases this way is small. But notice what the four steps have in common: every one of them is a headless commerce requirement that predates agentic commerce by a decade.

Catalog available as data. Cart on the server. Checkout drivable by code. Events on the way out. A store that has those is not agent-ready because it prepared for agents. It is agent-ready because those were always the right things to have, and the agent is just the newest client to need them.

That is the whole strategy: do the boring headless work, and arrive prepared by accident. If you want to see what that looks like as an API, thedocumentation is open, andthe developer case covers the design behind it.