What Is the Universal Commerce Protocol (UCP)? How AI Agents Could Transform Online Shopping

The Universal Commerce Protocol (UCP) is an open standard for connecting AI agents, consumer platforms, online businesses, and payment providers through a shared set of commerce capabilities. Instead of every AI shopping platform building a completely different integration with every retailer, UCP provides standardized ways for those systems to communicate across tasks such as cart building, checkout, payments, identity linking, and order management.

The easiest way to understand UCP is this: an AI agent may be capable of helping you decide what to buy, but completing a real purchase requires reliable communication with the merchant's commerce systems. UCP provides a common commerce layer for that interaction.

Its importance is therefore not that it makes an AI model "smarter." UCP addresses a different problem: interoperability between AI-driven shopping experiences and the infrastructure that actually sells, fulfills, and manages products.

What Is the Universal Commerce Protocol?

The Universal Commerce Protocol is an open-source commerce standard originally introduced in January 2026 by Google in collaboration with companies across retail, commerce, and payments.

Google described UCP as a common language for connecting consumer surfaces, businesses, and payment providers across an agentic commerce journey. The initiative was developed with companies including Shopify, Etsy, Wayfair, Target, and Walmart, with support from a broader group of commerce and payment organizations.

Its technical documentation is publicly available through the official Universal Commerce Protocol website.

The problem UCP is trying to solve becomes clearer if you imagine hundreds of AI shopping agents interacting with thousands of merchants.

Without a common protocol, the connections could look like this:

AI Platform A → Custom Retailer 1 Integration
AI Platform A → Custom Retailer 2 Integration
AI Platform A → Custom Retailer 3 Integration
AI Platform B → Another Retailer 1 Integration
AI Platform B → Another Retailer 2 Integration

As the number of platforms and businesses grows, maintaining one-off integrations becomes increasingly complicated.

UCP attempts to replace part of that fragmentation with a shared commerce vocabulary and standardized capabilities.

The intended model becomes closer to:

AI Platform ↔ UCP ↔ Merchant Commerce System

That diagram is intentionally simplified. UCP does not replace every system involved in shopping. Merchants still have their own catalog, pricing, inventory, tax, fulfillment, payment, fraud, and order-management logic.

UCP provides standardized ways for participating systems to communicate with those capabilities.

UCP in 60 Seconds

Suppose you tell an AI shopping agent:

"Find me a lightweight carry-on suitcase under $200 that can arrive before Friday. I want a black one with four spinner wheels."

The AI may be able to discover products and compare their specifications.

But once you want to buy one, several practical questions appear:

Is the exact variant still available?
What is the current price?
What taxes apply?
Which delivery options are available?
What is the final order total?
Which payment methods can be used?
Does the merchant require additional information?
Has the user actually authorized the purchase?
What happens after the order is placed?

Those are not simply language-model questions. They require communication with real commerce systems.

UCP provides standardized building blocks that allow a platform or agent to interact with supported merchant capabilities while the merchant continues to control its own business logic.

A useful mental model is:

Shopping Intent → AI Agent → UCP Commerce Capabilities → Merchant Systems → Payment & Fulfillment → Order

The AI agent can help interpret the user's goal. UCP provides a structured commerce language. The merchant's systems determine what can actually be sold and under what conditions.

This distinction matters:

AI capability ≠ commerce authority.

An agent being capable of selecting an item does not automatically give it permission to spend money or place an order.

Why Does Agentic Commerce Need a Protocol?

Traditional online shopping is built primarily around human interaction with websites and apps.

A shopper visits a store, searches or browses products, selects options, adds items to a cart, enters shipping information, chooses a payment method, reviews the total, and confirms the order.

Software already supports every step behind the interface, but the human usually navigates the workflow.

AI shopping agents introduce a different interaction model.

The shopper might provide the goal once:

"Buy the same dog food I ordered last month, but only if the 30-pound bag is under $70 including delivery."

An agent could potentially interpret the constraints, identify the product, inspect current commerce information, prepare a cart, determine whether the conditions are satisfied, and move toward checkout.

That requires machine-to-machine communication.

An AI system cannot safely rely on guessing what a checkout page means or assuming that yesterday's price and inventory remain valid.

For readers unfamiliar with the broader concept, Mozzim's guide to what an AI agent is explains how agents differ from ordinary conversational AI.

The N × N Integration Problem

One of UCP's core motivations is reducing integration complexity.

Imagine there are 50 AI shopping platforms and 10,000 merchants.

This does not mean there would literally need to be 500,000 completely independent integrations in every real-world architecture. Platforms, commerce providers, aggregators, and APIs can already reduce that complexity.

But the conceptual problem remains: if every platform and merchant exposes commerce functionality differently, interoperability becomes expensive.

A common protocol gives participants a shared contract.

Instead of asking:

"How does this particular merchant represent checkout?"

a participating platform can work with a standardized UCP checkout capability and then use the transport supported by that merchant.

Google describes this as reducing the traditional N × N integration problem toward a more unified integration model.

UCP Does Not Replace the Merchant's Commerce System

This is one of the easiest misconceptions to make.

UCP is not a new universal online store, payment processor, inventory database, or AI model.

A merchant can still use its existing systems to determine:

which products are available;
pricing;
discount eligibility;
inventory;
taxes;
shipping options;
returns;
payment acceptance;
fraud controls;
and order fulfillment.

The business remains responsible for its commerce logic.

In Google's description of UCP, the business remains the Merchant of Record—the party responsible for the transaction with the customer.

That design choice is significant.

Agentic commerce does not necessarily require an AI platform to become the retailer. The platform can facilitate a commerce journey while the underlying business remains the seller.

Think of UCP as an agreed language at the boundary between systems rather than a replacement for the systems themselves.

How UCP Works: Capabilities, Services, and Discovery

UCP is easier to understand when you stop thinking of it as one giant shopping API.

Its architecture is modular.

A business declares the services and capabilities it supports, and a platform can discover those capabilities before deciding how to interact with the business.

1. Services Organize Commerce Functionality

UCP groups related operations into services.

For example, shopping-related functionality can live under a shopping service, while common functionality can be represented separately.

This makes the protocol extensible rather than forcing every possible commerce operation into one fixed interface.

2. Capabilities Describe What the Business Can Do

Within UCP, a capability represents a particular feature that a business supports.

The current UCP specification includes standard capabilities such as:

Cart — supports basket building before a purchase is finalized;
Checkout — supports creation and management of checkout sessions;
Identity Linking — allows a platform to obtain authorization to perform supported actions on behalf of a user;
Order — supports communication about the order lifecycle.

Capabilities can also be extended with additional functionality.

This modular design matters because not every merchant needs to expose exactly the same commerce experience.

One merchant may support basic checkout.

Another may also support discounts, richer fulfillment choices, identity linking, or other extensions.

3. The Business Publishes a UCP Profile

UCP includes a discovery mechanism that allows a platform to determine what a business supports.

A business can publish its UCP profile at a well-known location:

/.well-known/ucp

The profile acts as a machine-readable declaration of capabilities, supported services, transport bindings, payment handlers, and related configuration.

This is an important architectural idea.

The AI platform does not have to assume that every business supports every UCP feature.

It can ask, in effect:

"What commerce capabilities do you support, and how can I access them?"

The merchant's profile provides the answer.

A Simple UCP Checkout Example

Consider an illustrative scenario.

A user tells an AI assistant:

"Find a waterproof hiking jacket under $180 in men's medium and buy the black version if delivery by Thursday is available."

Assume the AI platform discovers a suitable product from a merchant that supports UCP.

A simplified flow could look like this:

The agent interprets the user's requirements.
The shopping system identifies a matching product and variant.
The platform discovers the merchant's supported UCP capabilities.
A checkout session is created with the relevant item.
The merchant's systems calculate current pricing and other checkout state.
Fulfillment information is added or selected.
The platform presents the checkout state to the user through the appropriate trusted interface.
The user reviews and authorizes the purchase.
The checkout is completed.
An order is created and can subsequently receive lifecycle updates.

This example is intentionally simplified. Real transactions may require authentication, address information, tax calculation, inventory checks, payment processing, fraud controls, merchant-specific requirements, or escalation to the merchant's interface.

But it demonstrates UCP's main role:

The protocol gives the agentic shopping surface and the merchant a structured way to coordinate commerce state.

UCP Checkout Is More Than "Click the Buy Button"

A checkout is not a single action.

It is a changing state containing information about what the customer intends to buy and what conditions apply to the transaction.

The official UCP checkout capability supports the creation and management of checkout sessions, including cart-related state and calculations needed during the transaction.

For example, a checkout can involve:

line items;
buyer information;
fulfillment choices;
payment configuration;
totals;
status;
and eventually an order confirmation.

That state can change during the interaction.

If the user changes the quantity, chooses a different shipping option, or supplies information that affects eligibility or price, the checkout needs to reflect the updated state.

This is why a standardized checkout protocol is more useful than telling an AI agent to imitate a human clicking through arbitrary web pages.

Deterministic Commerce Logic Still Matters

UCP's current checkout guidance requires the business logic handling checkout sessions to be deterministic.

That makes sense because the final price, quantity, payment state, and order status cannot depend on a language model improvising an answer.

This gives us another important distinction:

Agent reasoning ≠ transaction truth.

An AI agent may reason about which product appears suitable. The merchant's commerce systems remain the authoritative source for the actual checkout state.

This distinction is especially important when money is involved.

Does UCP Let AI Agents Buy Things Automatically?

Potentially, but not by default in every checkout.

The current UCP checkout specification says checkout must ordinarily be finalized manually by the user through a trusted interface unless the relevant Agent Payments Protocol mandate extension is supported.

That means the normal mental model should not be:

"The AI decides what I need and silently spends my money."

A more accurate default flow is:

Agent assists → Checkout is prepared → User reviews → User authorizes → Transaction completes

More autonomous purchasing requires an additional mechanism for proving that the agent has legitimate delegated authority.

This is where UCP can work with the Agent Payments Protocol (AP2).

Google's UCP documentation describes AP2 support as part of the architecture for secure agentic payments. UCP's payment-related extensions include mechanisms for representing authorization in autonomous-commerce scenarios.

We will examine that distinction more closely later because AI agent checkout involves two separate questions:

Can the software technically perform the transaction?

and:

Has the user authorized the software to perform that transaction?

Those questions should never be treated as the same thing.

UCP vs MCP: They Solve Different Problems

The similarity of the acronyms makes this comparison especially important.

The Universal Commerce Protocol and the Model Context Protocol are not simply two competing versions of the same protocol.

They operate at different layers.

Question	UCP	MCP
Primary purpose	Standardize commerce capabilities and commerce data interactions	Provide a standard way for AI applications to connect with tools and contextual data sources
Domain	Commerce-specific	General AI tool and data connectivity
Examples	Cart, checkout, order, identity linking	Connecting an AI application to supported tools, services, or data
Relationship	Can expose UCP services through multiple transports	Can be one of the transport bindings used to access UCP services

This last row is the critical one.

UCP currently supports multiple transport bindings, including REST, MCP, A2A, and embedded integrations.

So asking "Should commerce use UCP or MCP?" can be the wrong question.

A merchant can expose a UCP-defined commerce capability through MCP.

In simplified terms:

UCP defines what commerce interaction means.

MCP can help define how an AI-oriented client accesses that interaction.

Readers who want the second half of that distinction can see Mozzim's detailed guide to Model Context Protocol (MCP).

UCP Can Also Work Through REST and A2A

MCP is not mandatory.

One of UCP's design goals is transport flexibility.

The same service can be exposed through different bindings depending on the systems involved.

REST

Traditional applications and backend systems can interact through standard HTTP APIs. UCP's REST definitions use familiar web technologies such as HTTPS, JSON, and OpenAPI-described interfaces.

This matters because businesses do not need to convert every commerce system into an AI-specific architecture before participating.

MCP

An AI application that already works through Model Context Protocol can use an MCP binding for UCP services when supported.

This connects a general-purpose agent/tool communication mechanism with standardized commerce semantics.

A2A

UCP can also work with Agent2Agent, or A2A, integrations.

This is useful when the interaction occurs between software agents rather than simply between an application and a conventional API endpoint.

Embedded Integrations

UCP also supports an embedded model in which business-controlled interfaces can participate inside an eligible host experience and handle interactions that are better delegated to the merchant's own UI.

The important takeaway is:

UCP is the commerce layer, not a requirement to use one particular networking or agent protocol underneath it.

Why This Architecture Matters for AI Shopping

AI shopping becomes substantially more difficult when every merchant represents the same concept differently.

One store might call something a cart.

Another might call it a basket.

A third might expose only a checkout session.

Payment methods, fulfillment options, discounts, order status, and identity can all be represented differently across commerce systems.

Human shoppers rarely see this complexity because websites translate backend systems into familiar interfaces.

AI agents need an equivalent machine-readable layer.

That is the architectural problem UCP is attempting to address.

It sits within the larger shift toward agentic AI systems that can use tools and complete multi-step tasks, but its scope is deliberately narrower: commerce.

The next step is to look inside the protocol more closely—how cart, checkout, identity, payments, fulfillment, and orders interact; what role AP2 plays in delegated purchasing; and what a realistic end-to-end purchase looks like when an AI agent is involved.

Inside a UCP Transaction: From Shopping Intent to Order

The easiest way to understand the deeper architecture of UCP is to follow a purchase from beginning to end.

Imagine a user tells an AI shopping agent:

"I need noise-canceling headphones for a flight next week. Keep the total under $350, make sure they can arrive by Friday, and I prefer black."

The agent can interpret those requirements and help identify suitable products. But finding the product is only the beginning.

A real transaction may require several distinct layers:

Intent → Product Selection → Cart → Checkout → Identity → Fulfillment → Payment Authorization → Order → Post-Purchase Updates

These layers should not be collapsed into one generic "AI buys something" step.

Each solves a different problem, and different systems may be responsible for each one.

1. Cart: Representing What the Shopper Wants to Buy

The cart capability provides a structured way to represent the products a shopper intends to purchase before the transaction is finalized.

That sounds simple, but a commerce cart can contain more than a list of product names.

The system may need to represent:

the exact product or variant;
quantity;
merchant-specific item identifiers;
current item state;
pricing-related information;
and changes made during the shopping session.

Suppose the AI agent initially adds the black version of a headphone model.

The user then says:

"Actually, get two if the second pair makes the total less than $600."

The shopping state has changed.

The agent should not simply multiply an old displayed price by two and assume the result is valid. The merchant's commerce system may need to recalculate the cart or checkout because quantity can affect discounts, availability, shipping, taxes, or other conditions.

This illustrates a recurring UCP principle:

The agent can request commerce actions, but the merchant remains authoritative for merchant-controlled commerce state.

Cart Is Not the Same as Checkout

These concepts are closely related, but they should not be treated as interchangeable.

A cart primarily represents shopping intent: what the customer is considering or preparing to purchase.

Checkout moves the interaction toward a transaction.

At checkout, additional information becomes important, including fulfillment, payment, totals, buyer details, and transaction readiness.

In simplified form:

Cart = What do I want?

Checkout = Under what final conditions can I buy it?

2. Checkout: Creating a Transaction State

UCP's checkout capability is one of the central pieces of the protocol.

Instead of treating checkout as a web page that an agent must visually navigate, UCP represents checkout as structured state that supported systems can create, inspect, and update.

A checkout session can evolve as the user and merchant exchange information.

For example, the initial state may contain:

a selected product;
quantity;
an initial price;
and basic checkout status.

Later updates may add or change:

buyer information;
shipping destination;
fulfillment method;
discounts;
payment information;
taxes;
and final totals.

This stateful design matters because checkout is not always linear.

A user might change the delivery address.

A shipping method may become unavailable.

An item might sell out.

A discount might become applicable.

The merchant may require additional information.

The final total may therefore differ from the amount visible when the agent first discovered the product.

The Merchant Calculates the Transaction

Suppose an agent finds headphones advertised at $299.

The final transaction might include:

$299 product price;
a merchant discount;
sales tax;
shipping charges;
or other legitimate checkout adjustments.

The AI should not invent these values.

The merchant's commerce systems calculate the authoritative checkout state according to their actual business rules.

That gives us another important distinction:

Product discovery price ≠ guaranteed final checkout total.

A shopping agent can use discovery information to compare products, but transaction-sensitive information should be validated against current commerce state before the user authorizes payment.

3. Fulfillment: Can the Merchant Satisfy the Shopper's Real Constraint?

For many purchases, price and product specifications are not enough.

The user may care about when and how the item arrives.

Return to the original request:

"Make sure they can arrive by Friday."

A headphone model priced at $279 may appear better than another at $299 until the merchant reveals that the cheaper option cannot arrive until the following Tuesday.

For this particular shopper, delivery changes product suitability.

A checkout interaction may therefore need to represent fulfillment choices such as shipping or pickup, depending on what the business supports.

Those choices can affect:

delivery timing;
shipping cost;
tax calculations;
store availability;
and the final transaction total.

This is why agentic shopping is not simply an AI recommendation engine connected to a payment button.

A useful agent needs to evaluate the entire set of constraints that determine whether the offer still satisfies the user's goal at transaction time.

4. Identity Linking: Connecting the User to the Merchant

Some commerce interactions need more than a one-time guest checkout.

A user may already have a relationship with a merchant that includes:

saved preferences;
loyalty benefits;
membership status;
order history;
saved addresses;
subscriptions;
or account-specific offers.

UCP includes an Identity Linking capability for supported scenarios in which a platform needs authorization to interact with a business on behalf of a user.

The important word is authorization.

An AI platform should not simply claim:

"This user is John, so give me access to John's merchant account."

The systems need a trustworthy mechanism for connecting the user's identity and permissions.

Identity linking therefore addresses a different problem from AI personalization.

An AI assistant may know that a user prefers black headphones. That does not automatically prove that the assistant is authorized to access the user's retailer account, loyalty benefits, or private order information.

In simplified terms:

Personal context ≠ merchant authentication ≠ authorization.

Why Identity Matters for Agentic Shopping

Imagine a user says:

"Reorder the same air filters I bought last time."

To fulfill that request reliably, a commerce agent may need legitimate access to the user's relevant merchant history.

Or imagine:

"Use my loyalty points if they save more than the current coupon."

The merchant must know which account is involved and what that account is entitled to use.

Identity linking can therefore make agentic shopping more useful without requiring the agent to treat private merchant-account information as publicly available data.

5. Payments: UCP Coordinates Commerce, but Payment Still Needs Authorization

Payments are where the distinction between technical capability and user authority becomes especially important.

An AI agent may be capable of:

finding a product;
creating a checkout;
selecting a fulfillment option;
and preparing the transaction.

None of those steps automatically means the agent has permission to spend the user's money.

For a standard checkout flow, UCP expects a trusted user interaction before finalization unless an appropriate delegated-payment mechanism is being used.

This protects an important boundary:

Preparing a purchase ≠ authorizing a purchase.

Payment Instruments and Payment Handlers

UCP's payment architecture separates the concept of a payment instrument from the handler that processes or supports it.

At a high level, this allows commerce participants to describe supported payment mechanisms without making UCP itself the payment processor.

The merchant still works within its supported payment infrastructure and remains responsible for transaction processing according to the relevant implementation.

That means UCP should not be understood as:

"Google created one universal payment system for every AI agent."

A more accurate interpretation is:

UCP provides standardized commerce coordination that can work with supported payment handlers and payment protocols.

6. AP2: How Delegated AI Payments Fit Into the Picture

The Agent Payments Protocol, or AP2, addresses one of the hardest questions in autonomous commerce:

How can a merchant or payment ecosystem know that an AI agent is legitimately acting under a user's instructions?

This matters when the human is not manually approving the final checkout at that exact moment.

Imagine a user tells an agent:

"Buy this laptop if the price drops below $1,000 during the next seven days. Do not spend more than $1,050 after tax and shipping."

The user may not be present when the condition becomes true.

If the agent later attempts the transaction, several questions arise:

Did the user really give this instruction?
Which product was authorized?
What maximum amount was allowed?
How long was the authorization valid?
Did the agent stay within those limits?
Can the authorization be verified later?

AP2 is designed around cryptographically verifiable mandates that can represent user intent and authorization in agentic-payment scenarios.

Within UCP, AP2-related payment extensions can be used where autonomous purchasing requires stronger evidence of delegated authority.

Human-Present vs Human-Not-Present Commerce

A useful distinction is:

Scenario	Example	Authorization Pattern
Human present	AI prepares checkout and user approves it now	User reviews and explicitly authorizes the transaction through a trusted interaction
Human not present	Agent buys later when pre-approved conditions are satisfied	Requires verifiable delegated authority appropriate to the autonomous transaction

The second case is substantially more difficult because the system cannot simply ask the user:

"Do you approve this $987 purchase?"

at the moment of transaction.

The merchant and payment ecosystem need evidence that the purchase falls within previously authorized boundaries.

Delegated Authority Should Have Limits

Agentic payment authorization becomes safer when the user's intent is constrained rather than unlimited.

Depending on the implementation, relevant boundaries could include:

maximum spending amount;
specific product or category;
approved merchant;
time window;
quantity;
delivery requirement;
or other conditions that define what the user actually authorized.

The principle is similar to giving a human employee purchasing authority with a budget and policy rather than handing over unrestricted access to a company bank account.

Autonomy works best when authority is explicit, scoped, and verifiable.

7. Order: What Happens After Checkout?

Commerce does not end when payment succeeds.

A completed purchase creates an order with its own lifecycle.

Customers may subsequently need to know:

whether the order was confirmed;
whether it has shipped;
which items are included;
how fulfillment is progressing;
whether part of the order was canceled;
or whether a refund or other post-purchase change occurred.

UCP's order capability provides a standardized model for communicating order state after checkout.

This matters for AI agents because a useful commerce assistant should not necessarily disappear after pressing "buy."

A user may later ask:

"Where are the headphones you ordered for me?"

or:

"Did that order ship yet?"

With appropriate authorization and supported merchant capabilities, the agent can potentially retrieve structured order information rather than scraping a tracking page or guessing from an old confirmation email.

Order State Is Merchant State

If the agent says an order has shipped, that statement should come from current order information—not because a language model inferred that three days have passed and shipping is therefore likely.

Again:

Prediction ≠ transaction state.

For commerce, authoritative state matters.

A Worked Example: Buying a Laptop Through an AI Agent

Now combine the pieces in a more complete hypothetical example.

A user tells an AI agent:

"Find a 14-inch laptop for travel. I need at least 16 GB of RAM and 512 GB of storage. Keep the final cost under $1,300, including shipping. It must arrive before Wednesday. Show me the best two options before buying anything."

Stage 1: Interpret the Intent

The agent extracts several constraints:

product: laptop;
screen size: 14 inches;
RAM: at least 16 GB;
storage: at least 512 GB;
maximum final cost: $1,300;
delivery deadline: before Wednesday;
workflow constraint: show two options before purchase.

The last constraint is especially important.

The user has not authorized autonomous purchasing.

The agent is allowed to research and prepare, but the user wants to make the final selection.

Stage 2: Discover Candidate Products

The shopping platform identifies compatible products from available merchant data.

Assume two suitable options emerge:

Option A: $1,149 laptop with 16 GB RAM and 512 GB storage.

Option B: $1,199 laptop with 32 GB RAM and 1 TB storage.

At this point, those prices should still be treated as discovery information rather than guaranteed final totals.

Stage 3: Present the Decision

The agent compares the two products and explains meaningful differences.

The user chooses Option B.

Now the workflow can move from product evaluation toward transaction preparation.

Stage 4: Discover Merchant UCP Capabilities

The platform checks the merchant's UCP profile.

Assume the merchant supports:

checkout;
shipping fulfillment;
supported payment handlers;
and order updates.

The platform now knows which standardized interactions are available.

Stage 5: Create the Checkout

The platform creates a checkout session for the exact laptop configuration.

The merchant returns current commerce state.

Assume:

current product price: $1,199;
standard shipping: free, arrives Thursday;
expedited shipping: $24, arrives Tuesday;
estimated tax: $72;
total with expedited shipping: $1,295.

Now the agent can evaluate the original constraints.

The standard shipping option fails the delivery requirement.

The expedited option satisfies the deadline, and the $1,295 total remains below the user's $1,300 limit.

Stage 6: Request User Approval

The agent can present something like:

"Option B can arrive Tuesday with expedited shipping. The current total is $1,295 including estimated tax and shipping, which is within your $1,300 limit. Would you like to place the order?"

The user approves.

This approval is not a minor interface detail. It is the boundary between recommendation and transaction authority.

Stage 7: Complete Payment and Checkout

The supported payment flow is used, the merchant validates the transaction, and checkout completes.

The merchant creates the order.

If any critical condition changes before completion—for example, the final total rises above $1,300—the system should not treat the old approval as permission for a materially different purchase.

Stage 8: Track the Order

The merchant subsequently updates the order state.

Later, the user can ask the assistant:

"Has my laptop shipped?"

With appropriate access, the agent can use the current order information to answer.

What If the Merchant Does Not Support a Capability?

UCP is capability-based, so platforms should not assume that every merchant supports the same features.

A business may support checkout but not a particular extension.

Another may expose a feature through a different supported binding.

A particular step may also need to move into a merchant-controlled interface.

This is important because interoperability does not mean uniformity.

UCP standardizes how capabilities can be described and accessed, but businesses can still have different:

products;
policies;
fulfillment models;
payment options;
eligibility rules;
and implementation choices.

A capable agent therefore needs to adapt to what the merchant actually declares rather than hallucinating unsupported functionality.

UCP Is Extensible, Not Frozen Around One Checkout Model

Commerce contains many features that cannot be represented by one minimal checkout schema forever.

Different businesses may need capabilities involving:

discounts;
special fulfillment;
subscriptions;
marketplace sellers;
loyalty;
custom product configuration;
or other domain-specific commerce behavior.

UCP is designed to be extensible so additional capabilities and extensions can be introduced without forcing every participant to implement every feature.

That is an important design trade-off.

A protocol that attempts to encode every possible commerce workflow in one mandatory specification would become extremely difficult to implement.

A protocol that defines too little would fail to create useful interoperability.

UCP's capability model attempts to sit between those extremes.

How UCP Fits Into the Larger Agentic Commerce Stack

At this point, it helps to separate the different layers involved in AI-powered shopping.

Layer	Main Job	Example
AI / Agent Layer	Interpret goals, reason about options, coordinate tasks	Shopping assistant or AI agent
Commerce Semantics	Define standardized commerce capabilities	UCP
Transport / Agent Connectivity	Provide supported ways for systems or agents to communicate	REST, MCP, A2A
Delegated Payment Authorization	Represent verifiable authority for supported agentic payments	AP2
Merchant Systems	Provide authoritative business and transaction state	Catalog, inventory, pricing, tax, fulfillment, order systems
Payment Infrastructure	Process supported payment transactions	Payment providers and networks

This table explains why calling UCP simply an AI shopping protocol can be useful shorthand but incomplete.

UCP does not perform every function in the stack.

Instead, it standardizes commerce interactions so those layers can work together more consistently.

UCP vs Traditional E-Commerce APIs

At first glance, UCP may sound like another commerce API.

There is overlap because both can expose commerce functionality programmatically.

The difference is primarily one of standardization and interoperability.

A traditional retailer API may be designed specifically around that retailer's architecture.

Its endpoints, authentication, object names, checkout behavior, error handling, and data structures can differ from every other retailer.

A platform integrating with many merchants therefore has to understand many different interfaces.

UCP provides shared commerce semantics that participating merchants and platforms can implement.

This does not eliminate merchant-specific business logic.

It reduces how much of that logic must be represented through completely proprietary interfaces.

Traditional API

Platform → Learn Merchant A's API → Build Integration A

Platform → Learn Merchant B's API → Build Integration B

Platform → Learn Merchant C's API → Build Integration C

UCP Model

Platform → Understand UCP → Discover Supported Merchant Capabilities → Interact Through Supported UCP Bindings

The merchant still needs implementation work, and real integrations can still contain platform-specific details. UCP does not magically eliminate engineering.

Its value proposition is that participants can share more of the contract.

UCP vs Browser-Using AI Agents

There is another important comparison.

An AI agent can sometimes interact with a store by using the website itself—opening pages, clicking buttons, selecting options, and entering information much like a human.

Mozzim explains that approach in its guide to computer-using AI agents.

Browser interaction can be useful when no structured integration exists.

But it has different reliability characteristics from a commerce protocol.

Browser-Based Agent	UCP Integration
Interacts with a human-facing interface	Interacts with structured commerce capabilities
May need to interpret changing page layouts	Uses defined protocol schemas and operations
Can be useful when no dedicated integration exists	Requires merchant/platform support for the protocol
UI changes can disrupt workflows	Protocol contract is designed for machine-to-machine interoperability

This does not make one approach universally superior.

A browser-using agent can potentially reach websites that have no UCP integration at all.

UCP, however, can provide a more explicit and structured contract when both sides support it.

That distinction becomes especially important as transactions become more consequential.

Why the User's Original Intent Must Survive the Entire Transaction

The laptop example exposes a deeper design requirement for agentic commerce.

The user's initial instruction contained several constraints:

14-inch laptop, at least 16 GB RAM, at least 512 GB storage, under $1,300 total, arrive before Wednesday, and show two options before buying.

A technically successful checkout is still a failed agentic workflow if it violates one of those important constraints.

For example:

the agent buys a 16-inch laptop;
the final total becomes $1,340;
delivery moves to Thursday;
or the agent purchases immediately without showing two options.

The merchant's checkout system may have behaved perfectly in each case.

The failure would occur at the agent-workflow layer.

This gives us another critical distinction:

Valid transaction ≠ successful user outcome.

UCP can standardize commerce interaction, but it cannot guarantee that an AI agent correctly interpreted the user's goal or made the right purchasing decision.

That responsibility spans the agent, the surrounding application, authorization controls, merchant systems, and ultimately the human-defined boundaries of the task.

The remaining question is therefore not whether UCP can technically connect agents and merchants. It is how reliable, secure, broadly adopted, and useful that model is in practice—and what limitations businesses and shoppers should understand before treating autonomous commerce as routine.

Why UCP Could Matter for the Future of E-Commerce

The potential value of the Universal Commerce Protocol becomes clearer when we look beyond a single checkout.

Online commerce today is fragmented across retailer websites, marketplaces, shopping apps, search engines, payment systems, and increasingly AI assistants. Each environment has its own interfaces and integration requirements.

Agentic commerce adds another layer.

Instead of humans manually navigating every store, AI agents may increasingly interpret shopping goals and interact with commerce infrastructure on the user's behalf.

That creates an interoperability problem.

If every AI platform needs a proprietary integration with every merchant, scaling agentic commerce becomes expensive and complicated.

UCP attempts to create a shared layer between those systems.

Its potential value can be summarized as:

One commerce language → Multiple consumer surfaces → Multiple merchants → Multiple supported transports and payment systems

That does not mean every participant will implement UCP identically or that all commerce will eventually use it.

It means participating systems can share more of the underlying contract instead of reinventing the same concepts independently.

Potential Benefits of UCP for Merchants

For merchants, the strongest theoretical advantage is not simply "getting into AI."

It is reducing friction when exposing commerce capabilities to multiple AI-driven surfaces.

1. Less Dependence on One-Off Integrations

Without shared standards, a merchant may need separate technical work for each commerce platform.

A common protocol can reduce how much of that integration must be redesigned every time.

This does not eliminate implementation costs. Merchants still need reliable commerce systems, authentication, payments, inventory, fulfillment, security, and monitoring.

But standardized capabilities can make the boundary between merchant and platform more predictable.

2. Merchant-Controlled Business Logic

UCP does not require the AI platform to become the merchant's pricing, tax, inventory, or fulfillment engine.

The business remains responsible for authoritative commerce state.

This matters because a retailer may have complex rules involving:

regional pricing;
inventory allocation;
promotions;
membership benefits;
shipping restrictions;
taxes;
fraud controls;
and fulfillment.

An external AI model should not attempt to recreate those rules from product-page text.

The protocol allows the merchant's systems to remain the source of transaction truth.

3. Access to New Shopping Interfaces

If consumers increasingly begin shopping inside AI assistants, merchants may want their products and transaction capabilities to participate in those environments.

A standardized commerce layer can potentially make this easier than building a separate proprietary experience for every AI platform.

However, UCP integration alone should not be interpreted as guaranteed product visibility or sales.

Technical interoperability ≠ recommendation priority.

An AI system can still determine that another product better satisfies the user's requirements.

4. A Path Beyond Product Discovery

Traditional merchant feeds primarily help platforms understand what products are available.

UCP extends the concept further into commerce actions.

The system can potentially move from:

"This merchant sells the product."

to:

"This merchant supports a structured checkout workflow for the product."

That is a significant architectural shift.

Mozzim's guide to optimizing an online store for AI shopping agents covers the product-data side of this transition. UCP addresses a different layer: what happens when an agent needs to interact with actual commerce capabilities.

Potential Benefits for AI Platforms

AI platforms face the opposite side of the integration problem.

A shopping assistant may need to interact with thousands of businesses.

If every business exposes checkout differently, the platform needs substantial merchant-specific integration logic.

Standardized capabilities can make merchant discovery and interaction more predictable.

A platform can inspect a merchant's UCP profile and determine which supported capabilities and transports are available.

That can answer questions such as:

Does this business support UCP checkout?
Does it support cart operations?
Can identity be linked?
Are order updates available?
Which payment handlers are supported?
Which protocol binding should be used?

This is better than assuming every merchant supports the same workflow.

Potential Benefits for Shoppers

From the customer's perspective, protocols are mostly invisible.

People do not normally care which API or schema created their checkout.

They care whether the shopping experience works.

If agentic commerce becomes reliable, a shopper could potentially express goals rather than manually perform every step.

Instead of:

Search → Open 10 tabs → Compare → Check stock → Check shipping → Create account → Add to cart → Enter details → Pay

a shopper might increasingly use:

Describe Goal → Review Options → Approve Transaction

For appropriately delegated tasks, some workflows could become even more automated.

For example:

"Reorder these filters every three months, but only if the total remains below $60."

or:

"Buy this camera if it falls below $900 before my trip."

The appeal is not AI for its own sake.

It is reducing repetitive shopping work while preserving the user's constraints and authority.

But UCP Does Not Solve Every Agentic Commerce Problem

A protocol can standardize communication.

It cannot guarantee that every decision made through that communication is correct.

This distinction is essential.

UCP Does Not Guarantee Good Product Recommendations

An AI agent can still misunderstand what the user wants.

Suppose the shopper asks for:

"A compact camera for wildlife photography."

The agent may incorrectly prioritize physical size while underestimating autofocus performance or lens requirements.

The resulting UCP transaction could be technically perfect.

The wrong product would still be purchased.

Protocol correctness ≠ decision correctness.

UCP Does Not Guarantee Accurate Merchant Data

A standardized schema cannot make incorrect data true.

If a merchant's system contains:

incorrect inventory;
wrong product specifications;
outdated delivery estimates;
misconfigured pricing;
or inaccurate return information,

UCP can communicate those errors efficiently.

The underlying data still needs to be reliable.

UCP Does Not Eliminate Fraud

Agentic commerce creates new security challenges alongside familiar commerce risks.

Attackers may attempt to:

impersonate platforms or agents;
steal authorization credentials;
manipulate transaction instructions;
redirect payment flows;
exploit merchant integrations;
or abuse delegated purchasing authority.

Protocol-level security mechanisms can reduce specific risks, but no commerce standard makes fraud impossible.

UCP Does Not Eliminate Merchant-Specific Experiences

Some transactions cannot be represented entirely through a generic checkout flow.

A merchant may require additional interaction for:

regulated products;
custom configurations;
complex financing;
special eligibility;
unusual delivery requirements;
or other business-specific workflows.

UCP supports escalation and handoff mechanisms for situations where the transaction needs to move into a merchant-controlled experience.

That is a useful design principle:

Standardize what can be standardized, but provide an escape path for what cannot.

Security: What Makes UCP Safer Than Letting an Agent Click Anything?

There is an important architectural difference between giving an AI agent unrestricted control of a browser and allowing it to interact with a defined commerce protocol.

With a protocol, supported actions can be explicit.

The system can know that an operation means:

create checkout;
update checkout;
retrieve checkout;
complete checkout;
cancel checkout;
or retrieve supported order information.

This is different from giving an agent a general instruction such as:

"Click around until you successfully buy the product."

Structured capabilities can make authorization boundaries easier to define and audit.

However, the existence of a structured API does not automatically make an implementation secure.

Transport Security Still Matters

For example, UCP's REST binding requires HTTPS and currently specifies TLS 1.3 as the minimum transport-security version.

The REST specification also defines mechanisms such as request signatures, request IDs, and idempotency keys.

These solve different operational problems.

A request signature can help verify message authenticity and integrity.

A request ID supports tracing.

An idempotency key helps prevent the same operation from being unintentionally performed twice during retries.

That last point is particularly important in commerce.

If a network timeout occurs after an order request, the platform should not blindly retry in a way that creates two purchases.

Authentication and Authorization Are Different

A merchant also needs to distinguish:

"Which platform is calling me?"

from:

"What is this platform allowed to do for this particular user?"

Those are separate security questions.

A legitimate AI platform should not automatically have unrestricted authority over every customer's account.

UCP's identity-linking model uses OAuth 2.0-based authorization for supported account-linked actions, while delegated autonomous payments can require additional mechanisms such as AP2 mandates.

AP2 Helps Answer the "Who Authorized This Purchase?" Question

Autonomous payments introduce a problem that ordinary checkout rarely faces in the same form.

If the user is present, the system can show the final transaction and ask for approval.

If the user is absent, the transaction needs another way to demonstrate that the agent is acting within previously granted authority.

UCP's AP2 mandate extension supports cryptographically verifiable authorization artifacts.

The current UCP reference describes mechanisms including merchant authorization and a checkout mandate that can provide evidence that the checkout terms are authentic and that the user authorized the checkout.

This helps create a verifiable chain between:

User Intent → Merchant Terms → User Authorization → Agent Action

It does not mean every UCP purchase uses AP2.

The normal UCP checkout model requires the user to finalize the transaction through a trusted interface unless AP2 mandate support is available.

That limitation is important because it prevents "agentic commerce" from being interpreted as unrestricted autonomous spending by default.

What Happens When Something Goes Wrong?

Reliable commerce architecture needs failure paths, not only success paths.

Consider several realistic problems.

The Product Goes Out of Stock

The agent found the product ten minutes ago, but inventory changed before checkout.

The merchant should return current transaction state rather than allowing the agent to assume the old availability remains valid.

The Final Price Changes

If a user approved a purchase under $500 and the current total becomes $525, the workflow should not silently reinterpret the original authorization as permission to spend more.

Material changes may require renewed user review or must remain inside a previously defined delegated authorization.

The Checkout Needs Human Attention

The current UCP checkout specification includes a requires_escalation state.

When escalation is required, the merchant provides a continue_url so the interaction can move to an appropriate merchant-controlled experience.

This could be useful when a generic agent workflow cannot safely or correctly finish the transaction.

A Request Is Retried

Network failures happen.

A platform might send a request and fail to receive the response even though the merchant successfully processed it.

Retry protection such as idempotency is therefore important for avoiding duplicate side effects.

A robust commerce protocol must assume imperfect networks and partial failures rather than treating every request as a clean one-time event.

UCP Adoption: What Is Actually True in 2026?

UCP should be described as real infrastructure that is still developing—not as either a theoretical proposal or a universal commerce standard already used by every retailer.

Google publicly introduced UCP in January 2026 as an open-source standard developed with Shopify, Etsy, Wayfair, Target, and Walmart, with support from more than 20 additional organizations across commerce and payments.

The protocol has continued evolving after its initial release.

Current UCP documentation available in 2026 includes newer versioned specifications beyond the original January release and defines capabilities and bindings for modern agentic-commerce implementations.

That is evidence of active technical development.

It is not evidence that every participating or supporting company has deployed every UCP capability across all of its customer experiences.

Those claims should remain separate.

Supporting a standard ≠ implementing every feature ≠ using it for every transaction.

Should Online Stores Implement UCP Now?

The answer depends heavily on the merchant.

Small Stores

For most small online stores, implementing UCP directly is unlikely to be the first AI-commerce priority.

Start with:

accurate product information;
structured product data;
clean variants;
current inventory;
reliable pricing;
clear shipping and return policies;
and high-quality merchant feeds where relevant.

If the store's commerce platform later provides UCP support, adopting it through the platform may be substantially easier than building a custom implementation.

Commerce Platforms and SaaS Providers

UCP may be more immediately relevant to companies that provide infrastructure to many merchants.

A commerce platform can potentially implement standardized capabilities once and make them available to a larger merchant base.

That can create significantly more leverage than thousands of small businesses implementing the protocol independently.

Large Retailers

Large retailers with mature APIs, product feeds, identity systems, and checkout infrastructure are better positioned to evaluate direct UCP implementations.

They may also have more to gain if AI shopping platforms become an important distribution channel.

But even for large businesses, implementation should be driven by measurable commerce requirements rather than fear of missing a technology trend.

A Practical UCP Readiness Checklist for Businesses

Before asking whether your business should implement UCP, ask whether the underlying commerce infrastructure is ready for machine-driven transactions.

Catalog: Can your systems reliably identify products and variants?
Pricing: Is current authoritative pricing available programmatically?
Inventory: Can availability be checked accurately?
Checkout: Is checkout logic deterministic and accessible through structured systems?
Fulfillment: Can shipping or pickup options be calculated programmatically?
Identity: Do you have appropriate authentication and authorization architecture?
Payments: Can supported payment methods be integrated safely?
Orders: Can order lifecycle state be exposed reliably?
Security: Are authentication, signatures, authorization, logging, and abuse controls mature?
Recovery: Can a transaction safely escalate to a human-controlled experience when automation fails?

If the answers to several of these questions are "no," implementing an agent protocol may not be the highest-value first step.

Fixing the underlying commerce infrastructure will usually create broader benefits.

UCP vs MCP vs A2A vs AP2: The Simple Version

These acronyms are easy to mix together, so here is the practical distinction.

Protocol	Main Purpose	Relationship to UCP
UCP	Standardize commerce capabilities	The commerce layer being discussed in this guide
MCP	Connect AI applications with tools and contextual resources	Can serve as a binding for UCP capabilities
A2A	Support communication between agents	Can be used as another UCP integration path
AP2	Support verifiable authorization for agentic payments	Can extend UCP payment flows for delegated transactions

The important lesson is that these technologies can complement each other.

They do not all compete to solve the same problem.

UCP vs Proprietary Commerce APIs

UCP also does not imply that proprietary commerce APIs disappear.

Businesses may continue to maintain APIs for specialized capabilities that UCP does not cover.

Platforms may also need custom integrations for merchant-specific features.

A realistic architecture could therefore contain both:

Standard UCP capabilities + Proprietary extensions or APIs

This is common in technology standards.

Standards tend to be most useful where participants benefit from agreeing on common behavior. Specialized features can remain differentiated.

What UCP Could Change About the Online Store

For decades, the website has been the primary interface between an online merchant and a customer.

Agentic commerce introduces the possibility that some customers may increasingly interact with merchants indirectly.

The relationship could become:

Customer → AI Agent → Merchant Systems

rather than always:

Customer → Merchant Website → Merchant Systems

This does not mean websites disappear.

People still need rich browsing experiences, branding, education, visual exploration, customer service, and merchant-controlled interfaces.

Some purchases are enjoyable precisely because people want to browse.

But repetitive or constraint-driven shopping may be particularly suitable for agentic interfaces.

Examples could include:

reordering routine supplies;
finding a product under a strict budget;
replenishing business inventory;
booking standardized services;
finding compatible replacement parts;
or purchasing when predefined conditions become true.

The store therefore may increasingly have two audiences:

Humans who need an excellent interface

and

software agents that need reliable structured capabilities.

What Remains Uncertain About UCP

UCP is still young enough that several major questions remain open.

How Broad Will Adoption Become?

An open standard becomes most valuable when enough relevant participants implement compatible versions.

Strong launch partners and continued specification development are meaningful, but they do not guarantee universal adoption.

Which Shopping Tasks Will Consumers Delegate?

People may be comfortable delegating a $20 household reorder while insisting on personally reviewing a $2,000 laptop purchase.

Autonomy may therefore develop differently across product categories and transaction values.

How Will AI Recommendations Be Monetized?

If conversational shopping becomes a major commerce channel, platforms will need clear ways to distinguish recommendations influenced by advertising, sponsorship, commercial relationships, or other incentives.

Trust can weaken if users cannot understand why a particular merchant or product was presented.

How Will Disputes Be Handled?

Suppose an AI agent purchases an item that technically fits an authorization mandate but clearly misunderstands the user's broader intention.

Determining responsibility among the user, agent provider, merchant, and payment participants can become complicated.

Technical transaction validity does not automatically resolve every customer dispute.

Will One Standard Dominate?

Commerce standards can coexist.

UCP may gain broad adoption, coexist with other standards, integrate with them, or evolve substantially over time.

Businesses should therefore distinguish preparation from prediction.

Building high-quality commerce infrastructure is useful regardless of which protocol ultimately becomes most widespread.

Frequently Asked Questions

What is the Universal Commerce Protocol?

The Universal Commerce Protocol, or UCP, is an open standard for interoperable commerce between consumer platforms, businesses, payment providers, and AI-driven shopping systems. It defines standardized capabilities such as cart, checkout, identity linking, and order interactions while allowing businesses to retain control of their underlying commerce logic.

Who created UCP?

Google introduced UCP in January 2026 in collaboration with companies including Shopify, Etsy, Wayfair, Target, and Walmart. Google also announced support from more than 20 additional organizations across retail, commerce, and payments.

Is UCP owned only by Google?

UCP was introduced by Google with industry collaborators as an open-source protocol. Its specifications are publicly available. That is different from a private API accessible only through a proprietary Google service.

Is UCP the same as MCP?

No. UCP defines commerce capabilities and semantics, while Model Context Protocol is a more general protocol for connecting AI applications with tools and contextual resources. UCP can use MCP as one of its supported bindings, so the two can work together.

Is UCP the same as A2A?

No. A2A focuses on communication between agents. UCP focuses on commerce capabilities. A2A can be used as one integration mechanism for UCP.

What is the difference between UCP and AP2?

UCP standardizes commerce interactions such as checkout and orders. AP2 focuses on verifiable authorization for agentic payments. UCP can use AP2 mandate extensions for supported autonomous-payment scenarios.

Can an AI agent automatically buy products through UCP?

Not automatically by default. The current UCP checkout model requires manual finalization through a trusted user interface unless the AP2 Mandates extension is supported. Autonomous purchasing therefore requires appropriate delegated authorization rather than merely giving the agent access to checkout.

Does UCP process payments?

UCP itself should not be thought of as a universal payment processor. Its checkout architecture can work with supported payment handlers and payment infrastructure while standardizing how payment-related information participates in the commerce workflow.

Does a store need MCP to use UCP?

No. UCP supports multiple integration approaches. MCP can be one binding, while REST and other supported mechanisms can also be used.

Does UCP replace an online store?

No. UCP provides machine-readable commerce capabilities. Merchant websites and apps can continue to provide browsing, branding, customer service, product education, account management, and other human-facing experiences.

Should small businesses implement UCP immediately?

Not necessarily. Many small merchants will gain more immediate value from improving product data, inventory accuracy, structured data, merchant feeds, shipping information, and checkout reliability. Direct UCP implementation becomes more relevant when the merchant's platform supports it or when agentic-commerce traffic justifies the investment.

Is UCP already widely used everywhere?

No. UCP is a real, actively developed open commerce protocol with major industry collaborators, but that should not be confused with universal deployment. Adoption and feature implementation can vary across businesses and platforms.

Conclusion: UCP Is a Commerce Language for an Agentic Web

The Universal Commerce Protocol addresses a problem that becomes increasingly important as AI agents move from answering shopping questions to participating in real commerce workflows.

An AI model can understand:

"Find me a laptop under $1,300 that arrives before Wednesday."

But understanding that sentence is not enough to complete the transaction.

The agent needs structured ways to interact with merchants, maintain checkout state, evaluate fulfillment, work with payment infrastructure, respect user authorization, and follow the resulting order.

UCP provides a common commerce layer for those interactions.

Its architecture is modular. Businesses declare supported capabilities. Platforms discover them. Commerce operations can be exposed through supported bindings such as REST or MCP. Identity linking can establish authorized account access. AP2 can support verifiable delegated payment authority in appropriate autonomous scenarios. The merchant remains responsible for authoritative transaction state.

The broader architecture can be summarized as:

User Intent → AI Agent → UCP → Merchant Commerce Systems → Payment & Fulfillment → Order

But the protocol does not remove the need for judgment, security, accurate data, or human control.

UCP can help ensure that systems speak the same commerce language.

It cannot guarantee that the AI chose the right product.

It cannot make incorrect inventory accurate.

It cannot eliminate fraud.

And it cannot turn an unauthorized purchase into an authorized one.

That distinction may ultimately be one of the most important lessons of agentic commerce:

Standardizing an action is not the same as deciding when that action should happen.

As AI shopping evolves, the businesses best prepared for this shift will likely be those that combine machine-readable commerce infrastructure with accurate product information, deterministic transaction systems, clear authorization boundaries, and reliable human fallback mechanisms.

Whether UCP becomes the dominant commerce standard or one important piece of a larger ecosystem remains to be seen. But the problem it addresses is already clear: if AI agents are going to participate meaningfully in commerce, they need something more reliable than guessing how every website works.

Continue Learning

Start with What Is Agentic AI? to understand how autonomous AI systems can plan and perform multi-step actions.

Then read Model Context Protocol (MCP) Explained to understand why MCP and UCP operate at different layers and how they can work together.

For the practical merchant side, continue with How to Optimize Your Online Store for AI Shopping Agents to prepare product data, structured information, feeds, and commerce infrastructure for AI-driven discovery.