You've probably heard that AI assistants will soon buy things on behalf of shoppers. Maybe someone has already offered to build you an integration for it. Before you spend a single hour on that, there's a duller question to answer first: for your store, in each of your markets, what can actually happen today, and what's documented?

This is an educational series from Verity Score for Shopify merchants. Last time, we looked at what other sources say about your products, and how to ask for one correction with evidence. Today, we turn to what people call agentic commerce, meaning an assistant that doesn't just talk about products, but takes steps toward a purchase. The question isn't whether that's the future. The question is what's available to you, specifically, right now.

We're still following the fictional luggage team. The store, its markets and every status I describe are invented for the example. No real admin screen, account or channel result is involved. And because the documentation on this topic changes, everything I describe from it is dated: we reviewed it on October twenty-second, twenty twenty-six.

The team receives a message from a developer. It says, roughly: AI shopping is here, assistants can now check out on your behalf, let us build your integration so you're ready in every market. The founder is tempted. The team is based outside the US and sells to customers in both the US and the UK. Being early sounds like an advantage.

But the operations lead asks three questions. Which assistant? In which country? And doing what, exactly? Nobody can answer. The message doesn't name a channel, a market or a documented capability. It describes a direction, not a fact.

And there's a cost to building toward a direction. Developer time, of course. But also the team's attention, which is limited. Every week spent on a speculative integration is a week not spent on the product data, answers and policies that any channel would need anyway. If the integration targets a capability that isn't available in their markets, or isn't available to them at all, that time is simply gone.

That's where we slow down. When people say an assistant can "buy," they may mean different capabilities. So before we look at any documentation, let's separate the capabilities. This split is an editorial tool, not an official classification.

The first is discovery. An assistant can find and describe your products when someone asks. Your products might appear, with a price and a link.

The second is handoff. An assistant passes the shopper to somewhere they can complete the purchase. Where they land matters: your own checkout, or somewhere else.

The third is a supported checkout. The purchase is completed through a route that's documented for your store and that channel, with clear rules about who processes the payment and whose policies apply.

These are different capabilities. A channel can offer one without the others. And a technical standard that describes how such a purchase could work is not the same as a service actually adopting it, or your store being eligible for it. A protocol is a specification. Adoption is a fact you have to check.

Let's look at what's documented in the sources we reviewed.

Shopify's help page on selling through ChatGPT describes a specific route. It lists conditions. Selling to customers in the US is one of them. The page also describes the channel as active by default for eligible stores; that is not proof of your own store’s current status. The merchant itself can be based outside the US. The products have to be eligible in Shopify Catalog. There are additional terms to accept, and the store's policies need to be complete. The same page describes the purchase as going through the store's own checkout. So for that route, as documented on that date, the handoff lands on your checkout. That's the description of one route for Shopify stores. It doesn't describe other channels, and it doesn't describe other merchants.

For our team, that means something concrete. They're based outside the US, which doesn't rule them out. They sell to US customers, which is one of the conditions for the store. That requirement alone does not establish the experience available to an individual UK shopper. But are their products eligible in Catalog? Have they accepted the terms? Are their policies complete? Those aren't questions to answer from a podcast. They're questions to check in the admin.

Shopify's documentation on Catalog tells you where to look. In the admin, under Sales channels, then Agentic, then Sources, the Shopify Catalog entry shows either a number of eligible products, or the word Ineligible. If details are temporarily unavailable, that's an unknown. It isn't eligible and it isn't ineligible. Write it down as unknown, with the date.

The same documentation makes another distinction we met earlier in this series: Catalog and web crawling are separate routes. Blocking crawlers in your robots file doesn't stop Catalog from sharing data with the channels you've activated. So if the team's question is "what can an assistant do with our products," the answer depends on which route you're asking about.

And the terms. Accepting additional terms is a business decision, with consequences for your store. It should be made by an authorized person on your team, after reading them, not by a developer, a script or an automated assistant on your behalf.

Now for the UK. Here, I have to be very direct. In the sources we reviewed for this episode, there is no documentation about agentic channels for UK buyers. That doesn't mean nothing exists. It means this episode can't tell you, and you shouldn't take silence as an answer either way. The same goes for Canada, or any other market. For each one, the only acceptable source is the channel's current documentation for that market, read and dated by you.

Check the review date in the show notes and reread the documentation before acting. A description that matched the documentation on that date may have changed by the time you hear it.

The team doesn't reply to the developer yet. Instead, they build a matrix. That's your action this week: build a dated eligibility matrix, market by market and channel by channel, with explicit ineligible and unknown states.

Here's how. The rows are combinations of a channel and a market. For our team: the ChatGPT route described by Shopify, for US customers. The same, for UK customers. And any other channel they're actually considering, for each market they sell to.

The columns are the three capabilities: discovery, handoff and supported checkout. Then record the status of each channel separately from eligibility. Add the conditions: documentation link, date reviewed, Catalog status in your admin, terms accepted or not, and by whom, and policies complete or not.

Each cell gets one of four states. Documented and confirmed in your admin. Documented but not yet confirmed. Ineligible, as your admin or the documentation says. Or unknown. Unknown is a legitimate answer. It's much better than a guess, and it tells you exactly what to check next.

For our team, the first draft looks like this. For the ChatGPT route with US customers, the conditions are documented and the checkout handoff goes to their own store, but their Catalog status and the terms are still to be checked in the admin. For UK customers, every cell is unknown, with a note: no documentation reviewed for this market. And the developer's offer gets a row of its own, with every cell unknown until the developer names a channel, a market and a documented capability.

Then the team makes one decision from the matrix. Nothing gets built until at least one row has documented conditions and confirmed eligibility. Until then, their time goes into what we covered earlier in this series: product data, consistent answers, and policies that are complete and true. Those help in every row of the matrix, whatever the future brings.

The matrix isn't a one-time document. Put a review date on it. When that date comes, reopen the documentation for each row, check the admin again, and update the states. A cell that moves from unknown to documented is real progress. A cell that moves the other way is just as important to see. Either way, the date on the matrix tells you how old your knowledge is.

So: separate discovery, handoff and supported checkout. A protocol isn't adoption, and a pitch isn't documentation. One route, for US customers, is documented by Shopify with clear conditions, as of the date we reviewed it. Everything else needs its own source, market by market. Next time, we'll ask how to measure any of this without pretending to know more than your reports can show.

Sources and review dates are in the show notes. This episode is read by a synthetic voice.