Order Management and UCP: How AI Agents Track and Fulfill Orders

What an OMS Does for an Agent

A UCP checkout creates an order. An order management system (OMS) tracks what happens to that order after it is created.

For a human buyer, order tracking means checking a confirmation email or visiting a tracking page. For an AI agent, order tracking means querying an API to get the current status, estimated delivery date, fulfillment source, and carrier tracking number. Agents that handle post-purchase workflows need direct access to OMS data.

The OMS is the system of record for everything between "order placed" and "package delivered." It knows where the order is in the fulfillment queue, which warehouse is picking it, which carrier will deliver it, and when the buyer should expect it. When agents need to answer questions like "where is my order?" or "can I change the delivery address?", the OMS API is where those answers come from.

How OMS APIs Work

Most modern OMS platforms expose REST or GraphQL APIs with a consistent structure:

Order lifecycle endpoints let you query an order by ID or reference number and retrieve its current status. Status values vary by platform but typically follow a progression: received, acknowledged, picking, packed, shipped, delivered. Agents poll these endpoints or subscribe to webhooks for status changes.

Inventory availability endpoints allow pre-purchase checks before a UCP checkout is initiated. An agent can call the OMS availability API with a SKU and destination to confirm the item can be fulfilled within the buyer's expected timeframe before presenting it as a purchase option.

Order modification endpoints handle changes after checkout. Common operations include address correction (before the order ships), item cancellation, and shipping upgrade. These endpoints have time constraints: once an order is in the picking queue, modifications may not be possible. Agents need to check modifiability status before attempting changes.

Fulfillment event webhooks push status updates to a registered endpoint. Agents subscribe to fulfillment events so they do not need to poll. When an order ships, the OMS sends a webhook with the carrier and tracking number. The agent receives this event and can proactively notify the buyer.

Distributed Order Management

Enterprise retailers often use distributed order management (DOM), where the OMS decides which fulfillment node handles each order based on configurable rules. A single order might be fulfilled from a warehouse, a retail store, or via drop-ship from a supplier.

For agents, DOM adds complexity. The OMS routing decision is not immediate. An order enters the system, and the routing engine evaluates available inventory across nodes before assigning a fulfillment source. This means order status may show "pending routing" for a period after creation. Agents that need to surface fulfillment source information to buyers should wait for the routing event before reporting it.

Platforms like Manhattan Associates, Fluent Commerce, and OneStock implement DOM. Their APIs include routing status as a distinct state in the order lifecycle. When building against these systems, agents should subscribe to the routing completion event before querying fulfillment node details.

Connecting UCP Checkout to OMS Fulfillment

The practical integration pattern:

1. Agent initiates UCP checkout and receives an order confirmation with an order ID
2. Agent stores the order ID alongside the UCP session context
3. Agent calls the OMS order submission API with the order details (items, destination, shipping method)
4. OMS acknowledges the order and returns an OMS-internal order reference
5. Agent subscribes to fulfillment webhooks using the OMS order reference
6. OMS sends webhook events as the order progresses through fulfillment
7. Agent surfaces status updates to the buyer on request or proactively

Steps 1 and 3 are separate calls because the UCP checkout layer and the OMS are often separate systems. The UCP endpoint handles payment and creates the order record in the merchant's commerce platform. The OMS picks up the order from the commerce platform and manages fulfillment from that point. Agents that need end-to-end visibility connect to both systems.

Order Modification Workflows

One of the more complex agent workflows is order modification after checkout. Buyers change their minds. Delivery addresses are wrong. Items are no longer needed.

The OMS API for order modification typically requires:

1. Querying the current order status to check if modification is still possible
2. Calling the modification endpoint with the change details
3. Receiving a confirmation that the modification was applied or a rejection if the order is past the modification window

Different OMS platforms handle the modification window differently. Some allow cancellation until the order is picked. Others have a strict cutoff at a specific status. Agents need to check the platform-specific rules and surface the right options to buyers based on current order state rather than assuming modification is always available.

What UCP Adds

UCP standardizes the checkout interface. The OMS standardizes the post-checkout interface. Together they give agents a consistent workflow from product discovery through post-delivery.

The UCP fulfillment capability, when implemented by a merchant, exposes order status and modification operations through the same standardized endpoint that handles checkout. Agents that integrate with UCP do not need separate OMS integrations for merchants that implement the full UCP capability set.

For merchants without full UCP fulfillment support, agents implement direct OMS integrations using the platform-specific APIs described above. The Fulfillment & OMS directory on UCPList tracks which OMS platforms are active in the UCP ecosystem and their current integration status.