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
- Keep a provenance field for every merchant candidate. Record whether the origin came from a marketplace, directory, merchant submission, platform catalog or another source.
- Resolve to the merchant-owned origin before execution. Verify the domain and current
/.well-known/ucpprofile instead of copying transactional fields out of an aggregator. - 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.
- 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.
- 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.
Primary sources
- Universal Commerce Protocol — Bulk Product Discovery DWG charter (#682)
- Universal Commerce Protocol — RFC: A Bulk Product Discovery Layer for UCP (#550)
- Universal Commerce Protocol — Proposal: per-seller offers for catalog variants (#810)
- Universal Commerce Protocol — current specification overview
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.