Start with a simple shopping request

Imagine a customer tells a shopping agent:

“I need a waterproof running jacket. Men’s medium. Under €200. I have a race on Saturday, so it needs to arrive by Friday. I prefer something lightweight. What would you buy?”

At first, this looks like a better version of product search. But the agent needs more than a list of matching jackets. It needs to know which products are genuinely waterproof, which exact variants are available, what they cost, whether they can arrive in time, and which differences matter for this customer.

If the customer continues with, “The blue one sounds good. Can you get it in medium?” the agent needs current variant information. If the next sentence is, “Great, add it to my cart,” the interaction has crossed another boundary. The agent is no longer just helping the customer discover a product. It is interacting with the catalog data and the commerce system.

The more I work on AI integrations in commerce, the more important this distinction becomes to me. Whether an AI can browse a store is no longer the big question. We already know it can. The more useful question is what the store can reliably tell the agent, and what it will allow the agent to do.

Discovery gets you into the conversation

Complete and effective product data remains the foundation. An agent cannot recommend a product it cannot understand, so feeds, attributes, descriptions, identifiers, variants, and availability all matter.

OpenAI’s current commerce direction is a good example. In March 2026, OpenAI expanded its Agentic Commerce Protocol (ACP) to include product discovery. Merchants can provide richer product information, giving ChatGPT more complete and up-to-date catalog data. One open question to follow is whether checkout will remain primarily owned by stores or whether instant checkout mechanisms, directly integrated into agentic surfaces, will become the dominant solution.

I have written before about making product information detailed enough for an AI to confidently choose among similar products. The challenge is not getting more text into a product description. It is giving the agent the attributes and context that actually help it make a decision.

There is one nuance I would make explicit today. The line between product data and live commerce data is becoming less clear.

The current UCP specification, for example, allows catalog responses to include variant availability. Its fulfillment capabilities can also communicate whether and how a variant can be fulfilled for a particular location.

But discovery information is still not the same thing as a completed transaction. Catalog information does not reserve inventory. Checkout can revalidate the current availability, price, fulfillment options, and other conditions before the purchase is completed.

That is the distinction I find useful:

Discovery helps the agent decide what might fit. The commerce system still has to confirm what can actually happen now.

Ten questions I would ask your store

Before thinking about protocols or AI plugins, I would take ten common customer questions and try to answer them through the systems behind the store.

The important part of this exercise is to answer these questions through your systems, not from your own knowledge of the business.

Wherever the answer becomes outdated, ambiguous, or requires someone to manually connect several systems, you have probably found a weak point for shopping agents.

I would start with customer capabilities, not the entire API

Once you have those questions, the technical architecture becomes easier to reason about.

If I were connecting a shopping agent to a store today, I would not begin by giving it every available commerce API. I would define a small number of operations that correspond to actual customer needs.

From a technical perspective, you might eventually express them like this:

search_products()
get_available_variants()
check_inventory()
get_delivery_options()
get_return_policy()
create_cart()
add_to_cart()
get_order_status()

These names are illustrative. The important part is that each operation has a clear meaning.

Traditional commerce APIs were often designed to let developers work with the underlying data model. That is perfectly reasonable for system integrations, but it does not automatically make an API a good interface for an agent.

Imagine an endpoint that returns 147 jackets with dozens of database fields. Technically, the agent has access to the catalog. In practice, it has to reconstruct the actual shopping operation from a large amount of raw data.

I would rather give an agent ten well-designed commerce capabilities than 200 endpoints and expect the model to work out the business logic itself.

WooCommerce is moving in an interesting direction here. WooCommerce 10.9 introduced its canonical domain abilities for products and orders. The WooCommerce engineering team explicitly distinguishes these from simple REST-shaped wrappers. An ability starts with a meaningful operation and defines its inputs, outputs, permissions, and behavior.

There is an important limitation. The current core abilities are mainly product and order management operations. They are not yet the complete set of shopper-facing capabilities in my example above.

The architectural direction is still useful. The ability belongs to WooCommerce, while the WordPress Abilities API, MCP, administrative tools, automation, or future agent surfaces can expose that underlying operation.

The difficult parts are usually not the product description

Variants are a good example. Saying that a jacket is “in stock” tells the customer very little if the blue version in medium is sold out. A shopping agent needs to reason about exactly what the customer can purchase.

Delivery gets more complicated. “Can it arrive before Friday?” can depend on the destination, the warehouse holding the stock, the current time, shipping cutoffs, carrier availability, and other items in the basket. A product page may show a general delivery estimate, while the actual answer only becomes known once additional transaction context is available.

Policies have similar problems. “Can I return this jacket after wearing it during a race?” is very different from asking for a link to the returns page. A useful agent needs policy information it can apply to a particular product and situation.

This is an area where UCP has become quite concrete. Its August 2026 specification includes structured policies for areas such as returns and warranties. Policies can apply across a response or target particular products and variants. Human-readable descriptions remain part of the model so a platform can still communicate the policy when it does not understand every structured field.

Then there is identity. The moment the customer asks, “Where is my last order?” the agent has moved from public product information into private customer data. Authentication, authorization, privacy, and consent are now part of the integration.

I wrote about that problem separately because connecting AI to a commerce system does not automatically answer which customer data the agent should be allowed to access.

Reading and acting should not have the same rules

I would separate information retrieval from actions that create consequences.

Searching for products and checking inventory are relatively low-risk. Adding something to a cart changes its state, but the consequences are still limited. Placing an order, canceling one, or initiating a refund deserves a different level of control.

Suppose the customer says, “Yes, get the second one.”

The agent may understand the sentence, but the commerce system still needs precision. It needs the exact product and variant, the quantity, the current price, the delivery details, and confidence that nothing important has changed since the products were presented.

In a custom agent experience, I might have the agent summarize that state before moving forward:

“That’s the blue Salomon jacket in men’s medium for €179, arriving Thursday. Do you want to continue with that?”

The implementation after that confirmation depends on the commerce system and protocol. It is important not to confuse conversational confirmation with authorization to place an order.

Current UCP is explicit about this. Without the relevant AP2 Mandates support, the checkout must be finalized by the user via a trusted interface. The agent can prepare much of the transaction, but standard UCP does not simply treat a spoken “yes” as authorization for an autonomous purchase.

That is a useful principle beyond one protocol. The best shopping agents remove unnecessary friction, but they should not remove deliberate confirmation and authorization when mistakes are costly.

Voice platforms are starting to expose similar controls on the agent side. ElevenLabs, for example, supports fine-grained approval policies for MCP tools, allowing low-risk tools to run automatically while sensitive tools can require explicit approval.

Retries are a boring detail until they charge the customer twice

There is one technical concept I think business teams should know because it becomes important as soon as agents perform actions: idempotency.

In simple terms, an operation should be safe to retry without accidentally doing the consequential thing twice.

Imagine the agent submits an order and the network connection fails before it receives the response. Did the order fail, or did the store create it and the response just disappear?

A badly designed integration might retry and create another purchase. A well-designed one can recognize that the second request represents the same operation.

UCP’s checkout model addresses this explicitly with idempotency keys and defined retry behavior. These details rarely appear in AI commerce demos, but they are exactly the kind of thing that matters once an agent can move money or modify an order.

Most merchants never need to use the word idempotency. Their engineering teams do. Once agents can perform actions, however, details like this directly affect customer experience and financial risk.

Where MCP, UCP and ACP fit

The August 25, 2026 specification of UCP covers commerce capabilities including catalog search and lookup, carts, identity linking, checkout, orders, structured policies, and fulfillment.

UCP can work across different transports and agent systems, including REST, MCP, and A2A.

It is also deliberately independent of the customer interface. The specification explicitly describes UCP as working across modalities, including chat, visual commerce, and voice.

That distinction matters. UCP does not provide speech recognition, voice generation, conversational turn-taking, or interruption handling. It defines commerce capabilities that those interfaces can use.

MCP solves a related but different problem. It provides a common way for AI systems to discover and invoke tools and access resources.

ACP connects merchants with OpenAI’s shopping experiences, with OpenAI currently putting substantial emphasis on richer product discovery.

I would pay attention to all of them, but I would not design a store around whichever acronym receives the most attention this quarter.

First, make sure the underlying commerce capabilities work. Then expose them through the relevant protocols.

What I would do on a WooCommerce store today

There are some things merchants can do without waiting for the protocol landscape to settle.

The first one is straightforward: connect your catalog to Google Merchant Center.

For a WooCommerce store, Google for WooCommerce is the obvious starting point. The extension automatically synchronizes WooCommerce product data with Merchant Center, including the product information Google uses for its shopping surfaces.

Google itself describes Merchant Center as the central place where merchants should prepare their product data for Google’s AI experiences and UCP onboarding. Google is also introducing AI shopping performance reporting around surfaces such as AI Mode, AI Overviews, and Gemini.

A clean Merchant Center feed already helps Google understand your products. It also means that if your business becomes eligible for Google’s agentic commerce experiences, you are not starting with a broken or incomplete catalog.

Voice makes weaknesses much harder to hide

Now imagine that the original jacket conversation happens through voice.

The underlying commerce requirements are familiar. The agent still needs products, variants, prices, inventory, delivery information, policies, and eventually actions.

What changes is how quickly weaknesses in those systems become visible to the customer.

A website can display ten jackets at once. A voice agent has to decide which few are worth mentioning and explain the differences clearly enough that the customer can keep them in their head.

A website can grey out an unavailable size. A voice agent needs to react naturally:

“Medium just sold out in blue. Black is still available, or I found another lightweight jacket in blue that can arrive Thursday.”

Latency also changes character. A two-second backend request on a website might show a loading indicator. During a spoken interaction, the same delay becomes part of the conversation.

Modern voice platforms can manage that waiting period with mechanisms that can help the conversation handle a tool call gracefully, but they cannot make the commerce system itself respond faster.

This is the connection I find particularly interesting:

Backend performance becomes part of conversational design.

Error handling does too.

If a commerce API responds with “variant unavailable,” the response may be technically correct but not very useful to an agent.

If it instead tells the agent that blue in medium is unavailable, while black in medium remains available, the agent has somewhere useful to take the conversation.

Ambiguity becomes more visible as well. When someone looking at a screen clicks the wrong jacket, they may spot the mistake before buying. When someone says, “Yes, that one,” there is no cursor showing which product they mean. The agent needs to accurately maintain product context, variant context, and the state of the conversation.

I do not see this as a separate voice commerce architecture.

I see it as the next stress test for shopping agent infrastructure.

The commerce capabilities can remain largely the same. Voice puts tighter requirements on latency, context, error recovery, and the quality of the information returned by each tool.

What happens when the store can answer back?

Let’s return to the original request:

“I need a waterproof running jacket. Men’s medium. Under €200. I need it before Friday. What would you buy?”

Understanding that sentence is only one part of the problem.

The store still needs to provide enough reliable information for the agent to determine which products fit, which exact variants are available, which can arrive in time, what the customer will pay, and which policies apply.

If the customer wants to proceed, the integration also needs a safe way to move from advice into action.

Product discovery gets your products into the conversation. Good commerce capabilities determine how useful the shopping agent can become once it gets there.

There are practical things merchants can do already. Clean up the product data. Connect WooCommerce to Merchant Center. Keep inventory as close to real time as the business requires. Make shipping and return information accessible. Keep your payment stack current. Test the ten customer questions above against the actual systems behind the store.

Voice raises the bar again because those same systems now operate inside a live conversation. Slow responses, vague product state, ambiguous actions, and poor errors stop being backend details. The customer experiences them directly.

That boundary between shopping agents, voice, and the systems running a real store is the part of AI commerce I find most interesting right now.