Editorial

Research brief · UCP merchant discovery

How do AI agents find UCP merchants? The business-discovery gap

UCP is getting better at describing what a merchant can do and how a known merchant can expose products. A different question remains upstream: before an agent can fetch /.well-known/ucp, how does it discover which businesses exist and which domain is authoritative?

Published 12 September 2026 · current proposals are status-bounded below

Known origin

business profile discovery starts after the merchant domain is known

Known business

bulk product discovery is currently scoped to businesses already known to a platform

Open gap

business discovery / seller-directory standardization is explicitly deferred from the feed DWG

The protocol boundary

A business profile is not a business directory

UCP's provider-owned profile is powerful once an agent has a merchant origin. It gives the platform a place to inspect versions, services, capabilities and payment-handler declarations before transaction execution. But an agent cannot fetch a merchant's profile until something has already told it which merchant domain to try.

The official Bulk Product Discovery working-group charter makes this distinction explicit. Its goal is efficient product-feed discovery across businesses using UCP product identity, but its stated scope excludes “business discovery” — which businesses exist, or a seller directory — as a separate complementary problem deferred to future work.

That boundary matters because “find every merchant” and “fetch every product for this merchant” have different trust, identity, freshness and abuse problems. Combining them into one vague discovery claim makes it easy for agents to treat a directory row as if it were merchant-authoritative configuration.

Current architecture

Five layers an agent should keep separate

1. Find a business

Directory, marketplace, platform catalog, search index or another trusted source produces a merchant origin. This is the unresolved cross-business discovery layer.

2. Verify the origin

Resolve the merchant-owned domain and fetch its declared UCP profile. Do not let a third-party directory become the execution source of truth.

3. Negotiate capability

Use the business profile to determine supported services, versions, payment handlers and compatible capabilities.

4. Discover products

For a known business, use its real-time catalog or, as the bulk-discovery work matures, a declared feed that preserves product identity and provenance.

5. Route the transaction

If an aggregator exposes multiple sellers, preserve the selected seller/Merchant-of-Record identity and route to the seller's own supported checkout contract.

What the new UCP work changes

Bulk feeds and per-seller offers move discovery forward without closing the directory gap

UCP RFC #550 proposes a bulk product discovery layer so a known business can publish product data efficiently rather than forcing every platform into bespoke integrations or broad web crawling. The approved working-group charter #682 carries that work forward and targets product-feed transport, schema, sync, access and provenance.

Separately, open proposal #810 addresses a marketplace problem: one catalog variant may represent offers from several sellers. Its proposed offers[] shape gives each offer a seller domain, seller item ID and price, then routes checkout to the selected seller. That can make seller identity explicit after an aggregator has surfaced an offer.

Neither mechanism is currently a universal answer to “which merchants should I search in the first place?” That is why merchant-directory and business-discovery infrastructure remains strategically important even as UCP's product layer matures.

Builder checklist

How to build merchant discovery without pretending the standard is finished

  1. Keep a provenance field for every merchant candidate. Record whether the origin came from a marketplace, directory, merchant submission, platform catalog or another source.
  2. Resolve to the merchant-owned origin before execution. Verify the domain and current /.well-known/ucp profile instead of copying transactional fields out of an aggregator.
  3. Separate presence from conformance. A directory listing proves only that a listing exists. It does not prove the merchant profile is current, schema-valid, reachable or transaction-ready.
  4. Preserve seller identity through routing. If a product is aggregated across sellers, keep the selected seller and Merchant-of-Record explicit through checkout and payment.
  5. Expect the discovery layer to evolve. The official UCP work is still active. Avoid hard-coding a private directory format as if it were a stable UCP standard.
Universal Commerce ProtocolUCP profile validatorAI shopping discoverabilityAgentic Commerce ProtocolMachine service discoveryzFinia machine-service catalogue

Primary sources

Status note: #550 and #810 are proposals and #682 is a working-group charter. This page describes their public state as of 12 September 2026 and does not present unmerged proposal details as stable UCP requirements.