2026-07-06 · agentic commerce · protocol stack

UCP and ARC: two layers, not two standards

One standardizes the transaction. The other standardizes catalog legibility. They compose — and they're aligned by design.

TL;DR — The Universal Commerce Protocol (UCP) and the Agent-Readable Catalog (ARC) contract are easy to frame as rivals. They aren't: they sit at different depths of the same stack. UCP standardizes the transaction — capability discovery, checkout, identity, orders, payment. ARC standardizes catalog legibility — making a store's products understandable and trustworthy to an agent before any transaction starts. One is the channel; the other is the quality of what flows through it. They compose, and ARC's fields are already shaped to match UCP where the two meet.

Two problems, not one

"Expose a catalog to an agent" and "let an agent transact" sound like one problem. They are two, and the clearest way to see it is by analogy with the web. HTTP defines how a browser and a server talk; HTML defines the structured content that makes the response worth rendering. A perfectly compliant HTTP exchange delivering malformed HTML gives the user nothing useful. The transport being correct does not make the payload legible.

Agentic commerce has the same split. There is a layer that defines how an agent transacts with a store, and a layer that defines whether the store's catalog is good enough for the agent to reason over in the first place. UCP is the first. ARC is the second. Neither substitutes for the other, and a store that wants to be both visible to agents and sellable through them needs both.

ARC — legibility layer
Makes the catalog understandable and trustworthy before a transaction. Governs the content.
  • Discovery signals + discovery document
  • Catalog endpoints: search, listing, detail
  • Explicit availability, list price, variants
  • Quality signals for weak records
  • Hands off at checkout — no payment
UCP — transaction layer
Makes the purchase programmable end to end. Governs the channel.
  • Capability profile at /.well-known/ucp
  • Checkout: sessions, tax, totals
  • Identity linking (OAuth 2.0)
  • Orders: webhook lifecycle events
  • Payment token exchange, AP2
Like HTTP and HTML: one defines how to communicate, the other whether the payload is worth anything.

What UCP is (from the source)

UCP is an open standard, published on GitHub under the Apache 2.0 license, describing itself as enabling interoperability between commerce entities to facilitate seamless integrations. Its README states the design directly: businesses declare supported capabilities for autonomous discovery, facilitate secure checkout sessions with or without human intervention, and do so over standard transports.

Three facts from the specification matter here:

It is composable and discovery-driven. A business publishes a profile declaring which capabilities it supports; platforms read it and configure themselves. Google's UCP documentation specifies that this profile is published at /.well-known/ucp.

It is transport-agnostic. The spec states capabilities can be offered over REST, MCP, or A2A, depending on the business's infrastructure.

Its center of gravity is the transaction. The initial release names its core capabilities as Checkout, Identity Linking (OAuth 2.0), Order (webhook lifecycle events), and Payment Token Exchange, with support for AP2 payment mandates. The point of the protocol is completing a purchase, securely, and everything after it.

That last point is the one to hold onto: UCP's first-class primitives are about transacting. Discovery and product data exist in service of getting to a checkout.

What ARC is

ARC is deliberately narrower. It is a contract for one job: making a product catalog legible and trustworthy to an agent before a transaction is attempted.

It defines discovery signals and a discovery document, catalog endpoints (search, listing, product detail), and a product object carrying explicit operational facts — availability, list price, variants, and quality signals for records that are ambiguous or incomplete. Its conformance levels describe catalog legibility, and they stop short of payment on purpose: an ARC surface hands off to the merchant's own checkout rather than processing payment itself.

The restraint is the design, not an unfinished edge. ARC answers can an agent understand this offer well enough to consider it? and leaves executing the purchase to whatever executes purchases.

Where they meet — a matter of record

This is the part usually missed, and it isn't aspirational — it's written into the ARC specification's UCP-interoperability section. ARC was authored so its catalog data is UCP-shaped at the field level:

Because the vocabulary was chosen to match, the core catalog facts an ARC surface exposes are already in the form a UCP-speaking agent expects. The handoff between "legible catalog" and "transaction protocol" is a boundary both sides describe the same way, so it needs no translation layer to cross.

ARC — discover, search, compare, trust handoff — UCP-aligned fields, no translation UCP — cart, checkout, payment, orders

Why two layers is the right shape

If UCP already contemplates a catalog, why should a separate legibility contract exist? Because defining the interface and governing the content are different jobs.

An interface specifies the tool names and the request and response shapes an agent calls. It does not, by itself, guarantee that availability is stated with confidence rather than implied, that the same fact is offered at the right resolution for the step the agent is on, or that a low-quality record is quarantined instead of silently returned. A catalog can satisfy an interface and still be too noisy to reason over. The interface says how to ask; the legibility contract says what a good answer looks like.

Keeping those separate is the same principle UCP itself is built on. UCP's own README describes breaking commerce into distinct capabilities and extensions precisely so implementations stay flexible and don't bloat. A catalog-legibility layer feeding a transaction layer applies that separation one step earlier in the funnel: what makes a catalog worth transacting on is not the same mechanism that executes the transaction.

In practice

Concretely, on a real store, the two layers coexist without conflict.

On Shopify. Shopify's agentic-commerce stack is UCP-compliant. Its developer documentation describes Storefront Catalog MCP (single-merchant product discovery) and Global Catalog MCP (cross-merchant), both implementing the UCP Catalog capability and its MCP binding, alongside cart and checkout capabilities. A Shopify merchant participates in the transaction layer through this stack.

On WooCommerce. There is no built-in UCP stack, so the two layers are assembled explicitly: expose the catalog under ARC so agents can read and trust it, and publish a UCP profile at /.well-known/ucp declaring the transaction capabilities the store supports. Because ARC's availability_status, list_price, and variants[] are already UCP-aligned, the catalog the agent reads and the checkout it hands off to speak a compatible vocabulary. KaliCart Bridge is one open-source reference implementation of the ARC side on WooCommerce, and publishes a UCP profile alongside it.

The shape is the same in both cases: a legibility layer that gets the store considered by agents, and a transaction layer that lets the sale close — the difference is only whether the platform ships them for you or you assemble them.

The useful question

"UCP versus ARC" presumes a fight for one piece of ground. There is no fight, because there is no single ground — there is a transaction layer and a legibility layer beneath it. The question a merchant should actually ask is not which standard wins. It's whether their catalog is legible enough for an agent to consider at all, and whether, once it is, it can hand off cleanly to the protocol that closes the sale. Those are two questions, and in 2026 they need two answers.

Sources

← All posts