ACP vs UCP vs BMOS: How Merchants Prepare for Agentic Commerce
ACP vs UCP is best read as a scope comparison, not a protocol feud: ACP helps AI agents complete checkout with sellers, UCP standardizes more of the commerce journey from discovery through post-purchase support, and BMOS gives merchants a catalog/feed layer that can expose ACP- and UCP-compatible data while attaching the public surface to .agent identity.
For a merchant, the useful path is not choosing a tribe. Start by cleaning catalog data, publish checkout and policy surfaces agents can read, decide which protocol endpoints to support, then anchor the official public commerce surface with HeadlessDomains.com.
Quick Comparison
| Path | Primary job | Merchant prep | Use when |
|---|---|---|---|
| ACP | Agent-ready checkout protocol for programmatic purchase completion. | Expose checkout configuration, payment credential relay, order confirmation, and fulfillment handoff. | A seller wants compatible agents to initiate checkout without scraping a storefront. |
| UCP | Open commerce standard spanning discovery, checkout, identity linking, order management, and support. | Publish catalog, capability, checkout, order, payment, and post-purchase surfaces agents can inspect. | A business wants one commerce language across assistants, agents, embedded surfaces, and partners. |
| BMOS | Merchant-facing catalog and feed layer for agentic commerce readiness. | Build or connect product data, live availability, policy context, human checkout links, machine checkout links, and .agent attachment. | A merchant wants a practical feed before or alongside ACP and UCP protocol work. |
How ACP Fits
The Agentic Commerce Protocol homepage describes ACP as an open standard for programmatic commerce flows between buyers, AI agents, and businesses. Its docs define a programmatic exchange between buyers, their AI agents, and sellers to complete a purchase. That makes ACP a checkout protocol first: the seller remains merchant of record, and the agent gets explicit interfaces for selection, credential relay, purchase completion, and updates.
ACP is useful when the merchant already has product data and wants a cleaner transaction path than browser automation. ACP does not replace product discovery, catalog operations, or public identity. It gives compatible agents a structured checkout lane once the buyer, seller, product, and payment path are ready.
How UCP Fits
The Universal Commerce Protocol takes a broader scope. UCP positions itself as a common language for platforms, agents, and businesses, with building blocks across discovery, checkout, and beyond. The Google UCP launch post says UCP works across discovery, buying, and post-purchase support and is compatible with A2A, AP2, and MCP.
That means UCP is closer to a commerce operating standard than a checkout-only lane. A UCP-ready merchant should think about catalog lookup, cart construction, identity linking, checkout sessions, order status, returns, support, payment proof, and partner interoperability as one connected surface.
How BMOS Fits
BMOS sits closer to merchant operations. It gives stores a standardized catalog/feed layer, ACP and UCP support, live pricing and availability, machine-ready checkout links, policy metadata, and .agent integration. In plain terms, BMOS helps the merchant publish the data that protocols and agents can use.
BMOS is not a replacement for ACP or UCP. BMOS is the preparation layer a merchant can use to make products, checkout links, policies, and feed metadata readable before the merchant chooses protocol surfaces. A store can publish BMOS feed output, support ACP-compatible checkout, add UCP-compatible capability surfaces, and connect the public commerce record to .agent identity.
Merchant Prep Checklist
- Normalize product IDs, titles, descriptions, images, variants, price, currency, availability, shipping rules, return policy, support contact, and terms URL.
- Build or connect a catalog feed that agents can parse without reading a visual storefront.
- Expose both human checkout links and machine-ready checkout links, with payment support and receipt expectations.
- Choose ACP surfaces where agent-ready checkout is the priority.
- Choose UCP surfaces where discovery, checkout, order management, and post-purchase support should follow one standard.
- Attach the feed, protocol endpoints, policy pages, agent-readable manifests, and proof links to a .agent identity.
- Test common buyer-agent prompts against the feed, product pages, protocol endpoints, and public identity record before launch.
Example Public Commerce Surface
{"merchant":"northstar.agent","catalog_feed":"https://merchant.example/agentic-commerce/feed.json","protocol_surfaces":{"acp":"https://merchant.example/acp/checkout","ucp":"https://merchant.example/.well-known/ucp","bmos":"https://app.buildmyonlinestore.com/agentic-commerce/feeds/northstar"},"identity":{"agent_json":"https://northstar.agent/.well-known/agent.json","skill_md":"https://northstar.agent/SKILL.md","llms_txt":"https://northstar.agent/llms.txt"},"commerce_context":{"policies":["shipping","returns","support"],"checkout_links":["human","machine"],"price_stock":"current"}}Where HeadlessDomains.com Fits
HeadlessDomains.com is the identity anchor, not a replacement for ACP, UCP, or BMOS. The .agent name can point agents to the official feed, manifest, policy pages, protocol endpoints, checkout routes, support contact, and verification record. Catalog data tells agents what can be bought; public identity tells agents which commerce surface is official.
Headless Domains names are headless. They do not require browser-native DNS resolution, and agents can use Headless Domains and SkyInclude infrastructure through command-line and API workflows. Browser behavior is a conventional user-experience topic, not a blocker for agents using the identity layer.
Where to Go Next
The fuller planning path starts with how to make a store discoverable to AI shopping agents. After that, compare product feeds and agent-readable catalogs, then connect the commerce layer back to the Agent Identity Stack.
FAQ
Is ACP the same as UCP?
No. ACP focuses on agent-ready checkout and purchase completion. UCP covers a broader commerce journey, including discovery, checkout, identity linking, order management, and post-purchase support.
Where does BMOS fit if ACP and UCP are protocols?
BMOS fits at the merchant catalog and feed layer. It helps stores publish structured product data, checkout links, policy context, ACP/UCP-compatible metadata, and .agent attachment in a merchant-facing workflow.
Should a merchant implement ACP, UCP, or BMOS first?
Start with the catalog feed when product data is incomplete or inconsistent. Add ACP where agent-ready checkout is the near-term channel. Add UCP where discovery, checkout, orders, and support should be standardized across agent surfaces.
How does .agent identity help agentic commerce?
A .agent identity gives the public commerce surface one stable name. Agents can inspect the official feed, manifests, endpoints, proof links, policies, and support routes before they recommend a product or prepare a purchase.
Do Headless Domains require browser-native DNS resolution?
No. The names are headless and do not require a browser to resolve or use. Agents can work with Headless Domains through command-line and API workflows maintained by Headless Domains and SkyInclude.
Build the Merchant Surface First
If you are preparing a store now, build or connect the catalog feed first, pick the ACP and UCP surfaces that match the channel plan, then attach the feed, checkout links, policy pages, and agent-readable manifests to a .agent identity so agents can inspect one public commerce surface before they recommend or buy.