Do I have to pick between UCP and ACP?

Only if you think of them as products to buy rather than obligations to meet. Listed as obligations, the overlap is most of the cost: identity, variants, accurate price and stock are demanded identically by both, and only the transaction path differs. A team that scopes this as "choose a standard" ends up sequencing the decision before the work, when the work is the same either way for the first four steps.

Which should I implement first?

Neither, in the sense that matters: build the catalog layer first, because both require it and it is useful to assistants that implement neither. Protocol-specific work should start at the feed serialisation, which is small once the source data is right.

Is the checkout layer worth implementing yet?

For most merchants, not yet. OpenAI shut down Instant Checkout during 2026 and repositioned ACP toward discovery, and large retailers adopted it on the discovery side. The party best positioned to know walked back their own in-chat checkout; the cost of building that integration twice exceeds the cost of being late to it once.

What do both protocols assume you already have?

Scoped, audited agent access — and neither specifies it. Per-credential permissions, idempotency on writes, a durable audit trail and a human gate on irreversible actions are the platform's responsibility, and they are the difference between an agent integration and an incident.

Agentic commerce

How do merchants implement UCP and ACP at the same time?

Updated August 14, 2026

They are not an either-or, and most of the implementation is shared. Both require the same foundation — a machine-readable catalog with product identity, variants, and price and availability that are accurate at read time. UCP then specifies discovery and cart construction; ACP specifies the checkout session and delegated payment inside an AI interface. Build the catalog layer once, and the remaining protocol-specific work is the transaction path, which is also the part still moving.

The shared foundation is most of the work

Presented as competing standards, they look like a costly choice. Broken into obligations, the overlap is large and the divergence is late.

Both need to know what you sell, in a form a machine can parse without interpreting a layout: product identity, variants, attributes, a stable identifier, and price and availability that are true at the moment they are read. That requirement is not protocol-specific, it is not wasted if either standard loses, and it improves classical search at the same time.

Layer	UCP	ACP	Shared?
Machine-readable catalog	Required	Required	Yes — build once
Real-time price and inventory	Required	Required	Yes
Product feed format	UCP shape	ACP feed spec	Same source data, different serialisation
Cart construction	Specified	Specified	Largely
Checkout session	Cart-level	Full session spec	No
Delegated payment	Not the focus	Specified	No

Where the work is shared and where it diverges

The order that does not strand work

Sequence by what survives a protocol losing.

1. One catalog source of truth with accurate price and availability. Serves both, plus every assistant that implements neither.
2. Serialise to each feed format from that source. Two serialisers over one dataset is a small job; two datasets is a reconciliation problem forever.
3. A programmatic quote and cart returning a binding total including shipping and tax. Both protocols need it and it removes browser simulation regardless.
4. Scoped, audited agent credentials before anything can write. Neither protocol specifies this and both assume it.
5. Checkout and payment delegation last, because it is the layer still in motion.

The freshness requirement is the real engineering

Most merchants can produce a structured catalog. Far fewer can produce one whose numbers are true when read, and that is where implementations of either protocol fail.

A feed refreshed nightly will confidently advertise stock sold that morning, and an agent acting on it generates a cancellation rather than an order. For subscription businesses it is sharper still: upcoming renewals are committed inventory, so a stock count that does not reserve against them will sell units already promised.

This is a genuine architectural advantage where inventory, orders and subscriptions share one system rather than syncing across an integration boundary — reserved quantity becomes a property of the data instead of a nightly reconciliation job.

Frequently asked questions

Do I have to pick between UCP and ACP?: Only if you think of them as products to buy rather than obligations to meet. Listed as obligations, the overlap is most of the cost: identity, variants, accurate price and stock are demanded identically by both, and only the transaction path differs. A team that scopes this as "choose a standard" ends up sequencing the decision before the work, when the work is the same either way for the first four steps.
Which should I implement first?: Neither, in the sense that matters: build the catalog layer first, because both require it and it is useful to assistants that implement neither. Protocol-specific work should start at the feed serialisation, which is small once the source data is right.
Is the checkout layer worth implementing yet?: For most merchants, not yet. OpenAI shut down Instant Checkout during 2026 and repositioned ACP toward discovery, and large retailers adopted it on the discovery side. The party best positioned to know walked back their own in-chat checkout; the cost of building that integration twice exceeds the cost of being late to it once.
What do both protocols assume you already have?: Scoped, audited agent access — and neither specifies it. Per-credential permissions, idempotency on writes, a durable audit trail and a human gate on irreversible actions are the platform's responsibility, and they are the difference between an agent integration and an incident.

Sources

Agentic commerce standards: UCP vs ACP vs AP2 — merchant guide — Digital Applied