The business website is not disappearing. Its role is widening: it must serve people directly and make reliable facts and actions legible to software acting on their behalf.
For two decades, digital commerce largely assumed a person would search, open a website, read product pages, and operate checkout. AI assistants introduce another route. A buyer can describe an outcome in ordinary language, ask an assistant to compare options, and potentially approve a quote, booking, or purchase without navigating a conventional storefront from start to finish.
That shift has two distinct technical problems. Discovery is how an assistant finds and interprets a business and its offerings. Transaction is how it checks current terms, coordinates a purchase, handles payment, and knows when to return control to a person. Better product data can help discovery; it does not, by itself, provide transaction semantics.
Shopify’s recent work illustrates the separation. Its Catalog API is described as a structured, queryable product-data layer for discovery across AI surfaces. The Universal Commerce Protocol (UCP), developed with Google, describes how commerce interactions can be discovered and negotiated and how capabilities such as checkout and payment can be coordinated. These are related parts of a wider system, not interchangeable names for one feature.
Make the business understandable before optimizing how it is found; make its actions dependable before automating them. Protocol support matters only when the underlying facts, policies, inventory, and approvals can be trusted.
The web was built for humans
The familiar commerce journey is designed around a human operator. A person recognizes a need, searches or follows a recommendation, opens a site, interprets its language and visual hierarchy, chooses options, and enters details at checkout. The interface bundles together explanation, evidence, navigation, and action.
That design is valuable. A website is a place to establish identity, explain trade-offs, communicate policy, answer unusual questions, and let a buyer make a considered decision. It is also a useful fallback when an automated process reaches ambiguity.
But a visual interface is not automatically a reliable software interface. A human can infer that “ships in two days” excludes weekends; a machine needs the conditions and the relevant location in structured form. A person may notice that a product photo shows the wrong variant; an agent needs consistent identifiers and variant relationships. Humans routinely reconcile ambiguity. Software can instead repeat it confidently.
Agentic commerce does not mean removing the website. It means separating what the website currently presents as one experience into capabilities that different participants can use: readable information, machine-readable facts, and controlled actions.
From search to AI discovery
Search engines already changed how people reach businesses: ranking and snippets moved part of the decision outside the site. Conversational AI adds a more active layer. Instead of returning a list of pages, an assistant may interpret a request, synthesize evidence, compare options, ask a clarifying question, and make a recommendation.
A discovery system needs more than a crawlable URL. It needs enough trustworthy context to answer questions such as: What is this business? Which products or services are offered? Where are they available? What do they cost? What are the constraints? How current is the information, and where did it come from?
The next step is action. After discovery, the assistant might check live availability, request a quote, reserve a time, or start checkout. Those actions require authorization, clear parameters, current state, and a way to handle failure. A citation in an answer is not a reservation; a catalogue record is not a completed order.
Discovery answers “what should I consider?” Transaction answers “what can I do now, under which terms, with whose approval?” A good system connects them without confusing one for the other.
Shopify’s two-layer approach: Catalog + UCP
Shopify’s public material describes two complementary initiatives. The first is the Shopify Catalog API, positioned as a structured, queryable source for product information that can support discovery across AI surfaces. Its job is to make product facts easier for participating systems to access and use. It is not a universal protocol for every business transaction.
The second is UCP, an open protocol co-developed by Shopify and Google. UCP is intended to give platforms and businesses a common way to discover commerce services and capabilities, negotiate compatible support, and coordinate commerce workflows. It addresses interaction and action more directly than catalogue publication.
Think of the distinction as what is offered versus how a compatible system can act on that offer. A product-data layer can make an item easier to match to a buyer’s request. A commerce protocol can describe a path to check out, handle supported payment methods, and return a result. Neither guarantees that every merchant, assistant, market, or payment method is available.
Shopify has reported that Catalog-powered AI searches convert at twice the rate of searches relying on scraped data. That is a Shopify-reported company metric, not an independently verified result established by the public sources cited here. It should be read in the context of Shopify’s own product announcement, not generalized to all AI commerce implementations. [1]
Shopify describes its products and publishes performance claims from its own perspective. This article attributes those claims to Shopify; it does not treat a vendor announcement as independent market evidence.
What UCP actually does
UCP is a protocol for expressing and coordinating commerce capabilities across participating systems. Its specification organizes those capabilities into services, capabilities, and extensions. The protocol is designed so that a platform and a business can identify what each supports and use a compatible subset rather than assume every participant implements everything. [2][3]
Discovery begins at a well-known profile
A business can publish a UCP profile at the conventional location /.well-known/ucp. The profile describes the protocol version and the services, capabilities, and supported payment handlers it advertises; it may also include relevant keys. A platform can use the profile to discover what the business says it supports. The profile is an entry point for machine-readable capability discovery, not a substitute for operational readiness or access control.
Discovery is followed by version and capability negotiation. A platform indicates the UCP profile or version context it is using for a request; the parties determine a compatible version and the capabilities they share. Extensions can add optional behavior, but their dependencies matter: an extension whose required parent capability is absent cannot simply be treated as active. Compatibility is therefore richer than matching a list of labels.
Checkout is a stateful workflow
Commerce requires more than a single “buy” call. A checkout flow needs to carry selected items and quantities, validate the current offer, calculate applicable totals, and report a state that tells the platform what can happen next. The business remains responsible for the truth of price, stock, tax, shipping, and policy at the point those facts are used.
A checkout that is incomplete or requires escalation should not be misrepresented as ready to complete. UCP’s model includes states that communicate these distinctions. For the buyer, the important guarantee is not that every step is automatic; it is that the assistant can recognize what remains unresolved and hand it back instead of inventing completion. [2][3]
Payment handlers describe supported routes
Payment handlers let a business advertise supported payment approaches in the protocol context. This is a negotiation and integration boundary, not a claim that UCP itself is a universal payment rail or that a platform can charge any method without the necessary credentials, authorization, and user consent. A payment option must be supported by the relevant parties and valid for the transaction.
Fulfilment, extensions, and human handoff
Fulfilment is part of the commerce problem: a buyer needs to know what happens after checkout, whether delivery or collection is possible, and what terms apply. Extensions let participants express additional capabilities while retaining a shared core. As with any extension mechanism, optionality makes versioning and dependency handling important.
When a flow needs a person, a continue_url can provide a route to continue in a web experience. That handoff may be needed for authentication, a missing detail, a policy decision, or a step that the current integration cannot safely complete. The useful design principle is graceful escalation: preserve context, explain what remains, and let the person finish or approve. [2][3]
In short, UCP can standardize how compatible systems describe and coordinate commerce actions. It does not erase merchant rules, payment-provider requirements, consumer protection obligations, inventory constraints, or the need for a human when authority or context is missing.
Where MCP, REST and A2A fit
A common source of confusion is treating UCP, MCP, REST, and A2A as competing names for the same thing. They operate at different conceptual levels. UCP describes commerce semantics: the services and capabilities involved in an interaction. MCP, REST, and A2A can be ways to expose or carry those operations in compatible implementations.
The UCP documentation describes REST bindings using OpenAPI, MCP bindings using JSON-RPC and OpenRPC (including tool calls), and A2A interaction through an Agent Card. These bindings give different kinds of clients a way to discover or invoke operations in a form they understand. The choice of transport does not, by itself, define the commerce meaning of a checkout or the business policy behind it. [2][3]
Calling something “an MCP integration” says something about how tools may be presented to an MCP client. It does not automatically mean the integration implements UCP. Likewise, an HTTP REST endpoint is not UCP merely because it returns JSON, and an A2A agent interaction is not the same thing as a commerce capability profile.
| Layer | Question it answers | Example role |
|---|---|---|
| UCP semantics | What commerce capability or workflow is being represented? | Discover a service; negotiate checkout support |
| REST binding | How can an HTTP-oriented client call it? | OpenAPI-described request and response |
| MCP binding | How can an MCP client discover and invoke tools? | JSON-RPC tool call for a supported operation |
| A2A binding | How can agents advertise and coordinate capabilities? | Agent Card and agent-to-agent interaction |
That separation is useful in practice. It lets a business reason about commerce behavior independently from a particular client framework, while still making clear that every binding needs its own implementation, security model, and operational testing.
Why capability negotiation matters
A protocol can have a broad feature set while any particular integration supports only part of it. A platform may support checkout but not a particular extension; a merchant may advertise a payment handler the platform cannot use. Negotiation prevents both sides from assuming a capability exists just because it exists in the specification.
This matters for resilience. If an optional extension is unavailable, a platform should know whether it can proceed with the core flow, offer an alternative, or ask the buyer. If no compatible checkout capability exists, it should not silently turn a discovery result into an order attempt.
Version negotiation also changes how teams should think about “support.” A logo or a line in a vendor integration list is not enough. Ask which version, capabilities, bindings, markets, payment methods, and error states are actually covered, then test them end to end.
The website is becoming an interface for machines
The site remains a human-facing product: it carries the brand, makes a case, provides reassurance, and handles journeys that need nuance. But it increasingly sits beside machine interfaces: structured product data, documented APIs, business profiles, policy documents, and transaction endpoints.
This is not a binary choice between “website” and “agent protocol.” Businesses will likely operate several surfaces that share underlying facts. The storefront may present a curated experience; a feed or catalogue may publish product attributes; an API may return live availability; a protocol profile may advertise supported actions. Consistency across those surfaces becomes a business control, not just a technical nicety.
For example, if a site says a service area includes Cape Town, a feed implies nationwide availability, and a booking endpoint rejects most postcodes, an AI summary can only inherit the contradiction. The fix belongs in the source of truth and its synchronization rules, not in prompt wording.
A machine-readable interface is useful when it exposes the same dependable business the human-facing site promises.
Websites will continue to matter as source material, trust surfaces, and escalation destinations. In UCP-style flows, a continue_url makes that last role explicit: when the agent cannot safely finish, the person can return to a web experience with the next step intact.
What this means beyond ecommerce
The same architecture pattern can matter anywhere a business has structured offerings and consequential actions. A travel company may need to expose availability, fare conditions, and booking steps. A professional service may need to explain eligibility, collect context, and request a consultation. A venue may need to publish event details and reserve a space. A B2B supplier may need to answer specification questions and produce a quote.
In each case, discovery and action remain separate. A model can describe a service without knowing whether a team is available this week. A booking action may require a location, a deposit, a qualification check, or a human review. The protocol vocabulary may transfer; the domain rules do not transfer automatically.
UCP is commerce-oriented, and its presence should not be stretched into a claim that every industry workflow fits its current capabilities. The broader lesson is architectural: make the offering legible, make permitted actions explicit, expose current state, and design a safe path for exceptions.
The missing layer: being understood
Most conversations about “AI visibility” begin with distribution: how to appear in an answer or get selected by a model. That is only one stage. Before an assistant can recommend a business responsibly, it has to form a reasonably accurate picture of what that business does, for whom, where, under what conditions, and with what evidence.
Being understood is more than publishing structured markup. It means having stable names and identifiers; clear relationships between products, variants, and services; explicit audience and location constraints; policies written in unambiguous language; prices and availability with timestamps; and a known owner for each fact. It also means identifying what the business does not do, so an assistant can decline an unsuitable match.
Structured data can reduce ambiguity, but it cannot decide which system owns a fact or resolve inconsistent records by itself. A strong foundation connects public descriptions with operational sources and makes updates observable. The business should be able to answer: where did this statement come from, when was it checked, and what happens if it changes?
First create a dependable model of the business. Then make it discoverable and recommendable. Finally expose actions that are safe, authorized, and observable.
Zoowa’s perspective: Understood → Recommended → Transactable
At Zoowa, we use a three-stage lens to keep the work grounded in the business rather than in a single interface or protocol.
Understood
Can a system accurately describe the business, its offers, its constraints, and the evidence for those claims? This stage is about entity clarity, product and service data, source quality, policy, and freshness.
Recommended
Can the right business be considered for the right need, in the right context? Recommendation depends on relevance and credible evidence, not just presence in a feed. Teams need to see how buyer questions are framed, which sources shape answers, and where the business is misunderstood or absent.
Transactable
Can a buyer move from intent to a permitted action, with current terms, the right authorization, and a traceable outcome? That could be a purchase, but it could also be an availability check, a quote, a booking request, or a deliberate handoff to staff.
The order matters. Automating an unclear offer can scale the wrong promise. Increasing exposure to inaccurate facts makes correction harder. Establish the meaning and control first, then improve discovery and action.
What businesses should start preparing now
Preparation does not require betting on one assistant or immediately rebuilding the storefront. Start with a bounded review of the facts and actions your business already depends on.
| Workstream | Start with | Evidence of readiness |
|---|---|---|
| Business identity | Canonical names, locations, identifiers, service areas, and ownership | Teams agree which record is authoritative |
| Offer data | Products, variants, services, prices, eligibility, and constraints | Facts agree across site, catalogue, and operations |
| Freshness | Update cadence, timestamps, caching, and feed failure alerts | Stale data can be identified and corrected |
| Action boundaries | What an agent may read, request, reserve, or complete | Authorization and approval rules are explicit |
| Exceptions | Unavailable items, policy mismatches, ambiguous requests | Clear fallback, owner, and human handoff exist |
| Measurement | Source, prompt, result, conversion, cancellations, and errors | Teams can distinguish discovery from completed action |
Then choose a narrow pilot: one product range, one service, one location, or one low-risk action. Define what the agent may do, what requires confirmation, what data is logged, and how a customer can recover if the integration fails. Test ordinary cases and uncomfortable ones: stale stock, changed pricing, duplicate requests, out-of-area delivery, and interrupted payment.
Do not confuse publishing an endpoint with being operationally ready. A machine interface is only as safe as its permissions, underlying systems, monitoring, and escalation design.
What to watch over the next 12–24 months
The technical specifications will evolve. Watch for real implementation detail rather than assuming adoption from an announcement or a list of endorsements. Useful signals include which profiles and capabilities are deployed in production, which bindings platforms support, and how integrations handle errors, version changes, and extensions.
Also watch the commercial and governance questions. Which party owns the buyer relationship? What data is passed to an assistant? Who is merchant of record? How are consent, refunds, disputes, tax, and regional rules handled? Can a business opt in by product, market, or action? What is the audit trail when an agent takes a step?
Finally, ask whether reported performance is independently measured and comparable. A conversion claim may depend on how a search is defined, what traffic is included, and what baseline is used. Prefer transparent methodology, repeatable measurement, and evidence that distinguishes a product pilot from a market-wide shift.
Agentic commerce is a developing direction, not proof that conventional ecommerce has been replaced. The near-term task is to make the business ready for additional channels while preserving a dependable human journey.
Conclusion
The transition from being found to being bought is really a transition from pages as the only interface to a connected set of human and machine interfaces. Discovery helps an assistant understand what a business offers. Commerce protocols such as UCP aim to make compatible actions more explicit. Bindings such as REST, MCP, and A2A affect how software reaches those capabilities, not whether the offer or transaction is trustworthy.
Shopify’s Catalog API and UCP make a useful example of the two-layer challenge: make product information accessible, then coordinate commerce actions through a shared model. The details will continue to change, and vendor claims should be weighed according to their evidence. The enduring work is more basic: accurate facts, clear policies, current systems, controlled permissions, and a human path when automation reaches its limits.
For a business, the practical sequence is simple to state and demanding to execute: become understood, earn relevant recommendations, and make the next action dependable. The website remains part of that system, but it no longer has to be the only way into it.
Prepare the business behind the interface. Protocols can connect capabilities; they cannot make an unclear, stale, or unsafe operation ready for agents.
Sources
The protocol and product descriptions below are based on primary documentation. Company performance statements are attributed to the publishing company. UCP is a living specification; the version note below identifies the specification version consulted, not a publication date.
- Agentic commerce for every developer: The Spring ’26 Edition
Shopify, 17 June 2026. Shopify’s description of the Catalog API and its agentic-commerce developer work. Any Catalog conversion comparison in this article is explicitly attributed as Shopify-reported.
Used for: Shopify Catalog positioning and the attributed conversion claim. - Building the Universal Commerce Protocol
Shopify Engineering, 11 January 2026. Technical overview of UCP’s services, capabilities, extensions, discovery, negotiation, payment flexibility, and human handoff.
Used for: protocol model, profile discovery, capability negotiation, checkout, and escalation context. - UCP Specification: Overview
Universal Commerce Protocol, living specification; version referenced: 2026-08-25. Consult the current specification for exact schemas, profile fields, version behavior, and supported bindings.
Used for: protocol concepts and implementation details. The specification can change after this article’s review. - Under the Hood: Universal Commerce Protocol (UCP)
Google Developers Blog, by Amit Handa and Ashish Gupta, 11 January 2026. Technical explanation of UCP and example integrations, including REST, MCP, and A2A.
Used for: distinction between commerce semantics and transport/binding options. - The agentic commerce platform: Shopify connects any merchant to every AI conversation
Shopify News, 11 January 2026. Shopify’s announcement of its agentic commerce platform and UCP collaboration with Google.
Used for: announcement context and company-attributed statements about rollout and endorsements.
This article is Zoowa’s analysis of the sources above, not a statement of endorsement or partnership by Shopify or Google. Examples are conceptual unless a source is explicitly named.