Agentic Commerce Protocols: How MCP, A2A, ACP, UCP and AP2 Work Together

Agentic Commerce is not limited to an AI system finding products or recommending a few options to a user. In a true agentic commerce experience, the agent must be able to access the right source, understand what the merchant is capable of, delegate tasks to other agents when necessary, process product and cart data in a shared structure, preserve the limits of user authorization and record payment outcomes in a verifiable way.

Each stage of this chain solves a different technical problem. For this reason, treating protocols such as MCP, A2A, ACP, UCP and AP2 as direct competitors or alternatives to one another is often misleading.

A better approach is to divide the Agentic Commerce architecture into layers:

1. Discovery and machine readability: How will the agent find the brand, product and commercial information?

2. Connectivity and coordination: How will the agent access tools and communicate with other agents?

3. Commerce semantics: In what shared language will products, carts, checkout and commercial capabilities be represented?

4. Authorization and payment security: How will the system prove what the user actually approved?

This perspective allows brands to ask a more useful question than “Which protocol should we choose?”

The better question is:

“Which layer of our Agentic Commerce infrastructure is currently missing?”

Why Can’t Agentic Commerce Run on a Single Protocol?

In traditional e-commerce, a user visits a product page through a browser, adds an item to the cart and personally completes the checkout process.

In an Agentic Commerce model, some or all of these steps may instead be carried out by software agents.

For example, a user might say:

“Find me a cordless vacuum cleaner under £150 that can be delivered within two days and buy the best option for me.”

Simply finding a product is not enough.

The agent may need to:

• understand the user’s criteria,

• discover suitable merchants,

• retrieve current product and inventory data,

• compare alternatives,

• check delivery conditions,

• create a cart,

• verify the spending authority granted by the user,

• initiate payment,

• record the transaction result.

Agentic Commerce is therefore not simply an API integration problem. It is a broader commerce infrastructure problem involving multiple systems, agents and trust layers working together.

What Layers Make Up an Agentic Commerce Architecture?

A simplified architecture can be represented as:

Web and Commerce Data → Tool / Agent Connectivity → Commerce Protocol → Authorization → Payment → Measurement

Within this chain:

• robots.txt, sitemaps, HTML, Schema.org and product feeds support discovery,

• MCP supports tool access,

• A2A supports agent-to-agent coordination,

• ACP and UCP provide shared commercial structures,

• AP2 focuses on authorization and payment accountability.

However, no protocol can automatically fix poor product data, incorrect prices or outdated inventory records.

Layer 1: Discovery and Machine Readability

The Agent Must First Be Able to Find the Brand and Product

Before an agent can perform a transaction, it needs to discover the merchant, products and relevant commercial information.

For this reason, Agentic Commerce readiness often begins with existing web infrastructure.

robots.txt

robots.txt controls which parts of a website crawlers and certain AI bots are allowed to access.

However, robots.txt is not a product catalogue or a special “AI file.”

Its primary function is to define crawl access policies.

XML Sitemap

XML sitemaps make it easier for search systems and crawlers to discover important URLs.

For large e-commerce websites in particular, they support discoverability across:

• product pages,

• category pages,

• brand pages,

• informational content.

Semantic HTML

Product names, prices, specifications, variants, delivery information and return conditions should not exist only inside complex JavaScript interfaces.

They should also be represented in structures that machines can reliably parse and interpret.

Schema.org Structured Data

Structured data types such as Product and Offer help systems interpret commercial information as defined entities rather than as unstructured text.

Organization, MerchantReturnPolicy and OfferShippingDetails can also make brand, return and delivery information easier for machines to understand.

Why Are Product Feeds Becoming More Important in Agentic Commerce?

For an e-commerce website with thousands or millions of product variants, relying only on web pages may be inefficient.

Product feeds provide commercial information in a more structured format, including:

• product ID,

• SKU,

• GTIN,

• product name,

• brand,

• price,

• sale price,

• availability,

• variant,

• image,

• product URL,

• delivery information.

From an Agentic Commerce perspective, however, simply having a feed is not enough.

The critical issue is consistency between the feed and the actual commerce system.

The First Major Agentic Commerce Problem: A Single Source of Truth

Imagine that the same product appears with:

• £99 on the product page,

• £89 in Schema.org,

• £109 in the product feed,

• £95 in the API.

This is no longer just an SEO problem.

A shopping agent may:

• recommend the wrong offer,

• display an incorrect price,

• build an invalid cart,

• fail during checkout because of a price mismatch.

One of the foundational concepts of Agentic Commerce should therefore be:

Single Source of Truth

Product information should ideally be managed from a central system and distributed consistently across HTML, structured data, feeds, APIs and checkout systems.

Layer 2: Connectivity and Coordination with MCP and A2A

What Is MCP?

Model Context Protocol enables AI applications to connect to tools and data sources through a standard interface.

For example, a shopping agent could use MCP to:

• search a product database,

• call an inventory service,

• check delivery times,

• read customer support documentation,

• trigger an order-management function.

What Does MCP Not Do?

Understanding MCP’s limitations is just as important as understanding its capabilities.

Setting up an MCP server does not automatically:

• fix product data,

• define a checkout standard,

• authorize payments,

• prove that the user approved a purchase.

MCP should therefore be understood primarily as a tool and context connectivity layer, not as a complete commerce protocol.

What Is A2A?

Agent2Agent Protocol is designed to enable independent AI agents to communicate and work together.

Its purpose is to allow agents built with different frameworks or operated by different providers to discover each other’s capabilities, delegate tasks and coordinate workflows.

For example:

a Shopping Agent

could delegate product discovery to a

Merchant Agent

while relying on a

Logistics Agent

for delivery calculations.

What Is the Difference Between MCP and A2A?

A practical distinction is:

MCP = Agent → Tool

A2A = Agent → Agent

For example:

“Check whether this product is in stock.”

could involve the agent accessing an inventory API via MCP.

Whereas:

“Ask the logistics agent whether this product can be delivered to London tomorrow.”

is closer to an A2A-style interaction.

MCP and A2A do not have to compete with each other.

In production architectures, both may be used together.

Layer 3: Commerce Semantics with ACP and UCP

MCP and A2A help define how systems communicate.

Commerce introduces another question:

When an agent and a merchant talk about a product, cart, checkout, price, delivery or payment, are they actually describing the same thing?

This is the core problem commerce protocols attempt to solve.

What Is the Agentic Commerce Protocol (ACP)?

Agentic Commerce Protocol is an open standard designed to support commercial transactions between AI agents, users and businesses.

ACP is associated with the OpenAI commerce ecosystem and standardises structures related to areas such as:

• product discovery,

• product feeds,

• carts,

• checkout,

• payment handoff,

• authentication,

• commerce extensions.

An important goal is to allow merchants to connect with agentic commerce surfaces without having to completely replace their existing commerce infrastructure.

What Is Universal Commerce Protocol (UCP)?

Universal Commerce Protocol is designed to establish a shared commerce language between consumer surfaces, businesses and payment providers.

Its scope extends from product discovery through checkout and related commercial capabilities.

One of UCP’s important architectural characteristics is its capability-based approach.

A business can declare the commerce capabilities it supports.

For example:

• checkout,

• fulfilment,

• discounts,

• payments,

• order management.

Agentic systems can then understand what the merchant is capable of doing before attempting a transaction.

UCP can also support multiple transport and interaction methods rather than locking commerce into a single communication mechanism.

API, MCP or A2A-style connectivity can therefore exist around the same broader commerce model.

ACP or UCP: Which One Will Win?

One of the most common questions is:

“Will ACP or UCP become the dominant standard?”

For most brands, this is currently the wrong starting point.

A more useful question is:

“Is our commercial infrastructure standardised enough to connect to multiple agentic commerce surfaces?”

Regardless of which protocol becomes more widely adopted, the fundamental data objects remain similar:

• Product ID,

• SKU,

• price,

• stock,

• variants,

• promotions,

• delivery,

• returns,

• cart,

• checkout,

• payment.

Companies should therefore avoid designing their entire commerce data model around a single protocol.

A more resilient strategy is to establish a platform-independent commerce data layer first, and then connect the appropriate protocols on top of it.

Layer 4: Authorization and Payment Security with AP2

Payment is one of the most sensitive parts of Agentic Commerce.

Once an agent begins acting on behalf of a user, several new questions appear:

• Did the user actually want to purchase this product?

• What was the maximum amount the user authorised?

• Was the cart modified after approval?

• Did the agent exceed the scope of its authority?

• Was the user present during the transaction?

• If the agent acted autonomously, what limits applied?

• Can the original approval be proven in the event of a dispute?

What Is Agent Payments Protocol (AP2)?

Agent Payments Protocol is designed to support secure payments initiated or coordinated by AI agents.

The concept focuses on creating a verifiable transaction context around agent-led payments.

Rather than simply accepting a request from a bot, the merchant and payment ecosystem should be able to determine:

• who authorised the transaction,

• what was authorised,

• under what conditions,

• whether the final transaction stayed within those limits.

What Is a Mandate?

A mandate represents the permission granted by a user or authorised party for an agent to carry out a particular transaction.

The goal is to make this permission cryptographically verifiable.

Within this model, it is useful to distinguish between concepts such as:

Checkout Mandate

and

Payment Mandate

A Checkout Mandate can represent authorization to proceed with a defined checkout.

A Payment Mandate can provide evidence that payment for that specific checkout was authorised.

This creates an accountability trail across the transaction.

Human-Present vs Autonomous Commerce

Not every Agentic Commerce transaction will involve a user looking at the final checkout page and pressing “Confirm.”

Two broad scenarios can emerge.

Human Present

The user sees the final cart and explicitly approves the transaction.

Human Not Present

The user defines conditions in advance.

For example:

“Buy this coffee machine if the price falls below £200 during the next three days.”

The agent may then complete the transaction later without the user being actively present.

In this case, the security problem is not simply protecting payment credentials.

The deeper requirement is:

proving that the agent stayed within the authority granted by the user.

How Could MCP, A2A, ACP, UCP and AP2 Work Together?

Consider a real-world example.

The user says:

“Find a black running shoe under £120 that can be delivered tomorrow and buy the best option.”

1. Intent

The AI agent extracts the criteria:

• category: running shoes,

• colour: black,

• maximum price: £120,

• delivery: tomorrow,

• action: purchase.

2. Discovery

The agent discovers suitable products using web content, merchant feeds or commerce systems.

3. Tool Access

The agent may access inventory or delivery services through MCP.

4. Agent Collaboration

It may delegate delivery calculations or another specialist task to another agent through A2A.

5. Commerce Interaction

The merchant’s checkout capabilities may be exposed using commerce protocols such as ACP or UCP.

6. Authorization

The user’s £120 spending limit and delivery condition are tied to an authorization mechanism.

7. Payment

A verifiable mandate structure such as AP2 can support the proof of purchasing and payment authority.

8. Receipt

The merchant returns the checkout result and the payment system returns transaction confirmation.

9. Measurement

The process should not be measured only as “AI referral traffic.”

The entire agentic commerce funnel should be monitored.

Which Problem Does Each Protocol Solve?

The important point is that these standards primarily solve different layers of the same system rather than replacing each other.

What Problems Do These Protocols Not Solve?

One of the most common Agentic Commerce mistakes is assuming that integrating a protocol completes the project.

It does not.

Protocols alone cannot solve the following issues.

Data Quality

No commerce protocol can automatically correct an incorrect price.

Entity Resolution

Relationships between identifiers such as:

• SKU,

• GTIN,

• feed ID,

• internal product ID

must be consistent.

Data Freshness

Inventory data that is 24 hours old may be unacceptable for real-time agentic commerce.

Authentication and Authorization

Not every tool call or agent request should receive the same level of access.

Fraud Prevention

A transaction being protocol-compliant does not automatically make it safe.

Observability

Businesses need to be able to track:

• which agent discovered which product,

• which API was called,

• where an error occurred,

• why checkout failed,

• whether authorization failed,

• whether payment was completed.

Privacy

An agent does not necessarily need access to the customer’s entire profile.

Agentic Commerce systems should expose only the minimum amount of data required for the specific task whenever possible.

How Should Agentic Commerce Be Measured?

In the Agentic Commerce era, measuring only organic traffic or AI referral traffic will not be sufficient.

New measurement layers are required.

Agent Discovery Rate

The percentage of products or brand entities that agentic surfaces can successfully discover.

Product Data Match Rate

The consistency of product information across HTML, structured data, feeds and APIs.

Agent Eligibility Rate

The proportion of discovered products that are actually eligible for an agentic transaction.

For example, an agent may discover 10,000 products while only 6,000 are ready for agentic checkout.

Tool Success Rate

The percentage of agent tool calls that complete successfully.

Checkout Initiation Rate

The percentage of agentic sessions that progress from product discovery to checkout.

Authorization Failure Rate

The percentage of transactions that fail because of authorization or mandate validation.

Agentic Conversion Rate

The percentage of agent-initiated journeys that result in a purchase.

Transaction Completion Rate

The percentage of agentic checkouts that result in successful payment.

This measurement framework also highlights the difference between GEO and Agentic Commerce:

GEO measures whether the brand enters the answer. Agentic Commerce must also measure whether the brand is actually transactable.

Where Should a Brand Start with Agentic Commerce?

1. Audit AI and Search Bot Access

Review robots.txt, crawlability, indexability and sitemap structure.

2. Establish a Single Product Data Source

Ensure that HTML, Schema.org, feeds, APIs and checkout systems are using consistent product and pricing data.

3. Standardise Product Identity

Clarify the relationships between SKU, GTIN, product IDs and variants.

4. Improve Structured Commerce Data

Align Product, Offer, Organization, shipping and return information with visible page content.

5. Measure Data Freshness

Track how quickly price and inventory changes propagate to feeds, APIs and other agent-accessible systems.

6. Select a Real Customer Job

For example:

“Find running shoes under £100 that can be delivered tomorrow.”

Test the entire journey from discovery to checkout.

7. Map Your Commerce Capabilities

Document whether your systems support functions such as:

• search,

• cart,

• checkout,

• discounts,

• shipping,

• payment,

• cancellation,

• returns.

8. Choose the Protocol Afterwards

Decide between ACP, UCP, MCP, A2A, AP2 or other integrations based on:

• your existing platform,

• payment provider,

• target AI surfaces,

• risk profile,

• desired customer experience.

The protocol should follow the architecture.

The architecture should not be built around the protocol.

What Is the Relationship Between GEO and Agentic Commerce?

GEO and Agentic Commerce should not be treated as completely separate disciplines.

The core GEO question is:

“Can an AI system find, understand and use the brand as a trusted source?”

Agentic Commerce takes this one step further:

“Once the agent finds the brand, can it safely transact with it?”

The maturity path can therefore be described as:

Discoverable → Understandable → Trustworthy → Transactable

If a brand cannot be discovered, it cannot be recommended.

If it cannot be understood, it cannot be compared accurately.

If it cannot be trusted, it is less likely to be selected.

If it is not transactable, the agentic commerce journey cannot be completed.

A structured GEO consultancy can support the visibility and content side of this preparation by helping brands become discoverable, understandable and trustworthy across relevant AI query spaces.

However, moving into Agentic Commerce also requires additional layers covering:

• product data,

• APIs,

• commerce capabilities,

• authorization,

• payment,

• transaction measurement.

The Webtures Approach to Agentic Commerce

Webtures approaches Agentic Commerce not simply as a technical trend defined by emerging protocols.

The broader framework combines:

• technical SEO,

• GEO and AI visibility,

• structured commerce data,

• product data quality,

• entity consistency,

• agent accessibility,

• trust,

• transaction readiness,

• measurement.

The objective is not simply to tell a brand to “set up an MCP server” or “integrate UCP.”

The real objective is to identify where the brand’s Agentic Commerce chain breaks and convert that problem into actionable technical tasks.

As standards continue to evolve, protocol assumptions will also need to be updated.

For this reason, Agentic Commerce readiness should not be treated as a one-off integration project.

It is better understood as an ongoing commerce infrastructure readiness programme.

Conclusion: Agentic Commerce Is Not a Protocol Problem, but a Systems Architecture Problem

The Agentic Commerce protocol landscape can be summarised through five questions:

Where will the agent find the brand and product information?

Machine-readable web infrastructure, structured data and feeds.

How will the agent access the required tool?

MCP.

How will the agent collaborate with another agent?

A2A.

How will products, carts and checkout be represented in a common commerce structure?

Commerce protocols such as ACP and UCP.

How will user authorization and payment approval be verified?

AP2 and related authorization and payment mechanisms.

A successful Agentic Commerce architecture does not attempt to use one protocol to solve every problem.

First, it makes the data reliable.

Then, it connects systems.

Next, it exposes commerce capabilities in machine-readable form.

Finally, it adds user authorization, payment security and transaction measurement.

Because the next stage of competition will not only be about:

which brand appears in the AI answer.

The more important question will be:

When an AI agent is ready to buy, which brand is actually ready to transact?