The emergence of agentic commerce has brought two critical standards to the forefront: Universal Commerce Protocol (UCP) and the Order Network eXchange (onX). While both are essential for AI-driven shopping to work at scale, they serve fundamentally different, and complementary, roles.
Understanding how these standards work together is crucial for anyone building commerce infrastructure for the AI era. Here’s what you need to know.
Two Standards, Two Very Different Jobs
UCP is a workflow-driven standard for AI agents. It defines the flows for product discovery, checkout, and payment capture. Think of it as the framework that tells AI agents: “Here’s how you present products, here’s how you handle checkout, and here’s how you capture payment.” It’s prescriptive by design: providing structured workflows that AI agents can follow consistently across different commerce experiences.
onX is a data and functionality interface. It exposes inventory, pricing, order capture, and fulfillment capabilities without dictating how they should be used. onX doesn’t tell anyone what to do or when to do it. It simply makes resources available: “Here’s inventory. Here’s an order return endpoint. Use them however you need to.”
The key difference is: UCP defines the “how” for discovery and checkout, while onX provides the “what” during and after.
Why UCP Needs onX (And Vice Versa)
UCP is excellent at orchestrating the selling experience, but it doesn’t originate critical data like inventory levels, fulfillment capabilities, or delivery promises. It needs that information from somewhere deeper in the stack, closer to fulfillment.

That’s where onX comes in.
UCP Handles Discovery and Checkout
When an AI agent helps a customer find and purchase a product, UCP defines that entire flow:
- How the product catalog gets surfaced to the AI agent
- How pricing and promotions are applied
- How the checkout process happens
- How payment is captured
So what doesn’t UCP do? It doesn’t store inventory, it doesn’t manage fulfillment, it doesn’t originate the data required to promise expected delivery dates. UCP defines callback points for these functions: places where the AI agent needs to retrieve information from an external source.

onX Provides the Back-Office Data and Capabilities
onX surfaces exactly what UCP’s callbacks need:
- Real-time inventory availability across fulfillment locations
- Pricing and promotional data that can change dynamically
- Expected delivery promise based on actual fulfillment capacity
- Order capture functionality to receive completed purchases
This is all taken from the fulfillment. The data can sit on top of 3PLs, WMSes, and OMSes.
When a UCP-powered AI agent needs to know if a product is in stock, it calls back to an onX-compliant system. When it needs to capture an order after checkout, it pushes that order to an onX endpoint.
onX doesn’t care how the AI agent got to that point or what it plans to do next. It just provides the tools and schema to accept the order.
How They Actually Work Together in Practice
Let’s walk through a simple example of how UCP and onX complement each other when an AI agent helps a customer complete a purchase.
Step 1: Product Discovery (UCP Territory)
The AI agent uses UCP workflows to surface products to the customer. The agent knows how to present product information, apply filters, and help the customer narrow down options. It’s all defined by UCP’s structured flows.
But when the customer asks, “Is this available?” the agent needs real data. It calls an onX-compliant system to get real-time inventory levels.
Step 2: Checkout (Still UCP)
The customer is ready to buy. UCP defines how the checkout flow works: collecting shipping information, applying promotions, calculating tax, and capturing payment.
But to promise a delivery date, the AI agent needs fulfillment data. Again, it reaches out to an onX endpoint to get accurate delivery promise information based on where inventory actually sits and how fast it can ship.

Step 3: Order Capture (Where UCP Hands Off to onX)
The order is complete. Payment is captured. Now what?
This is where UCP stops and onX takes over.
The AI agent sends the captured order to an onX-compliant order capture endpoint. From that point forward, onX is the interface for all the operational work that happens after the sale: order routing, fulfillment, shipment tracking, returns processing.
UCP’s job is done. onX’s job is just beginning.
What Makes This Pairing Work So Well
UCP and onX are complementary by design precisely because they’re so different.
UCP is opinionated. It tells AI agents exactly how to handle discovery and checkout. This consistency is critical for creating reliable shopping experiences across different AI platforms.
onX is deliberately unopinionated. It doesn’t dictate workflows for what happens after checkout. It just exposes data and functionality that any system (UCP-powered AI agents, traditional ecommerce platforms, or custom applications) can use however it needs to.
This means you can implement UCP for the selling experience and onX for the fulfillment without one constraining the other. UCP can evolve its checkout workflows. onX can expose new fulfillment capabilities. They work together without being tightly coupled.
The Practical Reality: Implementing Both Standards
Implementing UCP means building workflows. You’re defining how AI agents interact with your commerce system during discovery and checkout. You’re specifying callback points where the agent retrieves data or triggers actions.
Implementing onX means exposing data and functionality. You’re making your inventory, orders, and fulfillment capabilities accessible via Model Context Protocol (MCP). You’re not defining how they get used, just making sure they’re available when called.
For brands and commerce platforms, this means:
- Your product catalog, pricing, and checkout logic can live in UCP-compliant workflows
- Your inventory, order management, and fulfillment operations can be exposed via onX
- AI agents can seamlessly call both during a single customer transaction
The standards work together because they don’t try to do each other’s jobs.

Why This Matters for Commerce Infrastructure
If you’re building for agentic commerce, understanding the relationship between UCP and onX is essential.
You can’t just implement UCP and call it done. UCP needs real-time data from somewhere. Without onX (or something functionally similar), you’re back to building point-to-point integrations between every AI agent and your back-office systems – many of which are still stuck in the age of EDI and FTP.
You can’t just implement onX and assume AI agents will know what to do. onX provides the resources but doesn’t define the shopping experience. Without UCP (or an equivalent standard), every AI agent would handle discovery and checkout differently.
Together, they provide the full stack: structured selling experiences powered by real operational data orchestrated seamlessly.
What’s Next?
Both UCP and onX are evolving rapidly as agentic commerce moves from theory to practice. At Pipe17, we’ve implemented onX and are currently implementing UCP because we see how they work together to solve the complete problem: selling and fulfilling through AI agents.
UCP gives AI agents a consistent framework for commerce. onX gives them access to the operational infrastructure that makes those commerce transactions actually work.
That’s the relationship. That’s why they’re both essential. And that’s why the future of commerce infrastructure requires both.
Want to learn more about how Pipe17 enables both UCP and onX to work together? Book a demo to see it in action.
