ACP vs UCP vs BMOS: How Merchants Prepare for Agentic Commerce

ACP vs UCP is a scope comparison, not a protocol feud. ACP gives AI agents a structured way to complete checkout with sellers. UCP standardizes more of the commerce journey, from discovery through post-purchase support. BMOS is the merchant catalog and feed layer that can publish ACP- and UCP-compatible data and attach that public surface to a .agent identity.

For a merchant, the useful move is not picking a tribe. Clean the catalog. Publish checkout and policy surfaces agents can read. Decide which protocol endpoints you need. Pin the protocol versions you support. Then anchor the official public commerce surface with Headless Domains.

This update reflects protocol and catalog changes through September 2026, including UCP v2026-08-25, ACP’s 2026-04-17 surface expansions, and BMOS feed v0.2.

Quick Comparison

How ACP Fits

The Agentic Commerce Protocol is an open standard for programmatic commerce flows between buyers, AI agents, and businesses. Stripe and OpenAI co-developed it. Sellers stay merchant of record. Agents get explicit interfaces for selection, credential relay, purchase completion, and updates.

ACP is still best read as a checkout protocol first. It 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.

Community changelog notes from 2026-04-17 expand the ACP surface set beyond a single checkout call. Cart, feed, orders, auth, MCP, and discovery (/.well-known/acp.json) are part of that line. Confirm exact paths in the ACP GitHub repo before you hard-code filenames. The scope contrast with UCP still holds: ACP is the purchase lane; UCP is the broader journey language.

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. Google’s launch materials describe UCP as covering discovery, buying, and post-purchase support, and as compatible with A2A, AP2, and MCP.

That makes UCP closer to a commerce operating standard than a checkout-only lane. A UCP-ready merchant should treat catalog lookup, cart construction, identity linking, checkout sessions, order status, returns, support, payment proof, and partner interoperability as one connected surface.

UCP v2026-08-25 (required merchant note)

UCP v2026-08-25 is a breaking release. Secondary analyses of the GitHub/spec line describe multi-vertical foundations, stronger payment and consent tooling, and schema changes that require migration. If you published a UCP profile earlier in 2026, do not assume clients still speak the same shape.

Practical merchant actions:

1. Publish or update /.well-known/ucp (or your platform’s equivalent profile) and record the exact profile version.
2. Re-test discovery, cart, checkout, and order callbacks after any upgrade.
3. If you sell through Google’s UCP-powered checkout path, read the current Google Merchant Center UCP checkout help. Help text notes eligibility for participating merchants and partners in the United States, Canada, and Australia. Do not invent wider coverage.
4. Enterprise stacks may expose UCP through platform docs (for example Salesforce B2C Commerce UCP guidance). Treat those as platform enablement notes, not a substitute for your own catalog and identity hygiene.

How Build My Online Store (BMOS) Fits

BMOS sits closer to merchant operations. It gives stores a standardized catalog and feed layer, ACP and UCP support, live pricing and availability, checkout actions, 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. It is the preparation layer you can use before, or alongside, protocol work. 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.

The public BMOS agentic commerce standard documents feed v0.1 (legacy) and v0.2 (accepted), plus draft work on checkout_actions[] for multiple checkout routes. Prefer v0.2 fields when you publish a new feed. Keep human checkout links and machine checkout actions in the same commerce story so agents and people do not see different products.

What Changed Since May 2026

For deeper how-to work after this comparison, read Agentic Commerce for Merchants and the AI Shopping Readiness Checklist. This page stays on protocol roles.

Merchant Prep Checklist

1. Normalize product IDs, titles, descriptions, images, variants, price, currency, availability, shipping rules, return policy, support contact, and terms URL.
2. Publish a catalog feed agents can parse without reading a visual storefront (BMOS v0.2 or equivalent).
3. Expose human checkout links and machine checkout actions, with payment support and receipt expectations.
4. Add ACP surfaces when agent-ready checkout is the near-term channel.
5. Add UCP surfaces when discovery, checkout, orders, and support should share one standard. Pin the profile version after any upgrade past v2026-08-25.
6. Attach the feed, protocol endpoints, policy pages, agent-readable manifests, and proof links to a .agent identity.
7. Test common buyer-agent prompts against the feed, product pages, protocol endpoints, and public identity record before launch.

Example Public Commerce Surface

Illustrative only. Replace hosts and feed IDs with your live values. Do not treat sample BMOS paths as live feeds.

{
  "merchant": "northstar.agent",
  "catalog_feed": "https://merchant.example/agentic-commerce/feed.json",
  "feed_version": "0.2",
  "protocol_surfaces": {
    "acp": {
      "discovery": "https://merchant.example/.well-known/acp.json",
      "checkout": "https://merchant.example/acp/checkout"
    },
    "ucp": {
      "profile": "https://merchant.example/.well-known/ucp",
      "profile_version": "2026-08-25"
    },
    "bmos": {
      "standard": "https://github.com/BuildMyOnlineStore/bmos-agentic-commerce-standard",
      "feed_note": "Use your live BMOS storefront feed UUID; sample path names are not live feeds"
    }
  },
  "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_actions": ["human", "machine"],
    "price_stock": "current"
  }
}

Where Headless Domains Fits

Headless Domains 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. 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

Start with how to make a store discoverable to AI shopping agents. Then compare product feeds and agent-readable catalogs. 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 actions, 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, and pin the UCP profile version you ship.

What should merchants do about UCP v2026-08-25?

Treat it as a migration event. Update the published profile, record the version, and re-test discovery through order flows. Do not assume an early-2026 profile still matches clients built for v2026-08-25.

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.

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. Pin versions. Then attach the feed, checkout actions, policy pages, and agent-readable manifests to a .agent identity so agents can inspect one public commerce surface before they recommend or buy.