Agentic commerce is operationally viable only when a merchant can provide an accurate catalogue, valid terms and verifiable order status. A protocol such as UCP may connect commerce to AI surfaces, but it does not resolve data ownership, support from a specific platform or actual customer demand. The decision should therefore start with the business process, not the integration.
Agentic commerce describes a buying process in which an AI surface or agent may help a buyer find, compare and initiate a purchase. For a merchant, this creates another sales surface. It does not create a new source of business truth.
UCP, or Universal Commerce Protocol, is described as a protocol for connecting commerce with AI surfaces. For protocol context, see Shopify's UCP overview and Google's UCP guide . These sources do not, on their own, answer the business question of whether a particular merchant can currently sell through a specific AI surface.
Three layers need to remain separate:
The first two layers may create an opportunity. The third determines whether the merchant can present information a buyer can rely on during an order.
In a conventional web shop, a buyer often sees information the merchant displays and maintains on its own site. In agentic commerce, the same information can pass through several stages: from an ERP or another source, through a catalogue and integration, to an AI surface and the final buying flow. Any ambiguity in that chain becomes a business risk.
Accurate data for agentic commerce should therefore be assessed through three questions:
An ERP is often the official source for products, inventory, prices, taxes, customers, orders and fulfilment. That does not mean every channel must read directly from the ERP. The architecture still needs to identify the official transaction and the synchronisation rule. A catalogue, PIM, web shop, integration layer or marketplace can each have a role, but they should not leave the source of truth unclear.
It is particularly important to distinguish data intended for display from data used to confirm an order. A product name and description may follow a longer publishing cycle. Price, availability, a customer's eligibility for a condition, delivery timing and order status often need stricter validation at the point of decision.
No protocol can assume business responsibility in place of the merchant. Every sales-channel condition needs a named owner who can approve a change, explain the rule and resolve an exception.
The phrase owner of sales-channel terms does not need to mean one person for all data. In practice, it is more useful to assign responsibility by business decision:
It is equally important to specify who decides when data conflicts. If the channel shows availability and the ERP later rejects the reservation, the operational owner needs a predefined process. If an AI surface requests information the catalogue does not contain, the team needs to know whether the field may be omitted, supplemented or whether the offer should be blocked.
The most useful starting point is not a full inventory of every field. Start with the minimum promise made to the buyer: identify the product, show terms, receive the order, confirm its outcome and provide support after purchase.
For each stage, record the input, owner, rule, destination and exception procedure.
Check whether the channel has a unique item identifier, correct name, description, variant, unit, relevant images and the information needed to fulfil the order. Not every field has the same importance, but product identity must be stable.
A price without context is often not enough business information. Currency, tax display, discounts, quantity rules, a specific customer's eligibility for a condition, validity period and delivery cost should be clarified where relevant to confirmation.
Do not assume every sales channel supports every pricing model. Check support from the specific platform and payment flow. If a channel cannot transfer a required condition, a sound business decision may be to limit the offer, direct the buyer to a different flow or not activate purchasing in that channel.
Availability is not the same as physical stock. It can depend on reservations, warehouse location, customer priority, procurement lead time and the ability to deliver to a particular address. Define what the channel may show, when it must recheck the data and when an order must be rejected or routed for manual handling.
Payment requires a separate check of merchant, payment-system and marketplace or AI-surface support. A protocol may describe a connection method, but the operating model for payment, returns, customer identification and support remains subject to a specific review.
An order needs a unique identifier across the channel and the official processing system. This makes it possible to trace acceptance, rejection, change, fulfilment, cancellation and return.
Define which statuses the channel may display and what each status communicates to the buyer. "Received" is not the same as availability confirmed, and "shipped" is not the same as delivered. If systems use different statuses, record the mapping rules and the owner of every transition.
Consider a manufacturer with a B2B spare-parts catalogue. The catalogue contains items and descriptions, the ERP manages inventory and orders, and prices depend on the customer's contract. The company is considering presenting part of its offer through an AI surface connected by a protocol.
The assessment should not start with "can we connect?" It should follow this sequence:
A negative answer does not necessarily end the initiative. It may mean a narrower initial scope: standard items only, customers with simpler terms only, inquiry rather than purchase, or additional business rules before activation. This is preferable to extending the channel with an unclear promise.
Agentic commerce does not remove the need for human decision-making in exceptions. An AI surface may phrase a customer request differently, and a channel may have its own constraints around display, identity or payment. The process should not rely only on the wording of a response or the impression created by a user interface.
Protocol support also does not confirm regional availability, support from a particular marketplace, payment-system terms or the behaviour of a particular platform. Every planned combination of merchant, AI surface, marketplace and payment needs a separate check before public purchase activation.
There is also a business trade-off. Stricter validation before confirmation may add steps to the buying flow, while reducing the risk of an incorrect promise. A broader catalogue may increase visibility, while expanding the data and exceptions that must be maintained. The decision should reflect order value, volatility of terms and the team's capacity to handle exceptions.
Use this list as a decision criterion, not merely as a technical task.
If these questions reveal an unclear data source or an unnamed owner of terms, address the process first. ORKA's approach connects day-to-day collaboration, ERP official transactions and Trueforce specialised engineering around clear business accountability. For a structured assessment of the current state, consider Business process screening .