ODP Roadmap

Where ODP is heading

ODP helps Agents discover a Service's Offerings and the Actions available to use or acquire them. We are exploring common ways to prepare purchases, work with carts, and manage what happens after an acquisition. Services would expose these capabilities through their existing systems, retaining control over their data and business rules.

This roadmap describes future work. The published specification remains the reference for functionality available today. We welcome implementation feedback and use cases that can help shape these proposals.

Carts

Let Agents work with a Service's cart through ODP: add Offerings with selected options, inspect the contents, change quantities or selections, remove items, and discover the Action for purchasing the cart.

For example, an Agent could discover a shirt, select black and a quantity of two, and execute its add-to-cart Action. The Service would return a cart representation whose entries expose the available adjustment and removal Actions. The cart itself would expose a purchase Action for acquiring its contents.

Services would connect these operations to their existing cart systems, just as they connect ODP Offerings to their existing product inventory. ODP would describe the cart, its contents, and its Actions; the Service would continue to handle execution, authentication, and payment.

This work would establish common cart representations and operation meanings so Agents can interact with carts across Services without learning a different interface for each integration.

Quotes and purchase preparation

Help Agents obtain current purchase terms before committing: selected options, quantities, taxes, fees, discounts, delivery costs, and the resulting total. A quote could also state when those terms expire and which Action continues the purchase.

This capability would work independently of carts. An Agent could request a quote for one configured Offering, such as a print job or a flight, without creating a cart. ODP already defines a quote Action; this work would give its results and subsequent steps a common representation while the Service continues to calculate and enforce the terms.

Purchase policies and disclosures

Help Agents understand the conditions attached to an Offering before purchasing it. A Service could describe return windows, final-sale restrictions, warranty coverage, and other terms, including conditions that apply only to particular items.

For example, an Agent comparing two Offerings could explain that one allows returns while the other is final sale. The work would distinguish information provided for review from disclosures that require acknowledgment. These are the terms of a purchase; the Actions for requesting a return or refund afterward belong to post-purchase management.

Human handoff and resumption

Let an Agent prepare an interaction and hand it to a person through a browser link without making them repeat their selections. A person could review a configured Offering, resolve a step that needs their involvement, or finish a purchase using the Service's own interface.

This work would describe how to preserve the in-progress interaction and let the Agent retrieve its resulting state before continuing. It would apply to individual Offerings as well as carts. The Service would control access to the saved state, and opening a continuation link would not itself authorize a purchase or payment.

Orders and post-purchase management

Let Agents retrieve a record of what was purchased, check its progress, and discover the operations available afterward. An order could expose Actions to request a cancellation, return, exchange, or refund when the Service permits them.

For example, an Agent could find a previous purchase and request a return for one item rather than starting from the catalog again. The Service's existing order system would remain authoritative; requesting an operation would not imply that it has been approved or completed.

Fulfillment and delivery

Give Agents a common way to understand how an Offering will be delivered and to follow its delivery after purchase. Physical goods may offer shipping or pickup, with costs and estimated arrival times. Digital goods may provide download access or report when purchased content is ready.

An order may arrive in separate shipments or include items delivered in different ways. The representation would connect each delivery to the relevant purchased items and expose the available tracking or access Actions. Services would continue to arrange and perform fulfillment.

Availability and reservations

Help Agents check whether stock, capacity, or a time slot is available and understand a temporary hold on it. Examples include reserving a seat, holding inventory while a purchase is prepared, or allocating computing capacity.

ODP already defines a reserve Action. Further work would describe the resulting reservation, its expiration, and the Actions available to confirm or release it. Availability information and a confirmed hold would remain distinct, so an Agent would not mistake a catalog listing for a guarantee.

Subscriptions and ongoing access

Describe recurring terms and let Agents inspect and manage an ongoing relationship with a Service. A subscription could expose its renewal schedule, current access, and Actions to change a plan, pause service, or cancel renewal where supported.

For example, an Agent could determine when a plan change takes effect and whether access continues after cancellation. This work would standardize the information and available operations, while the Service and its payment integration remain responsible for billing and execution.

Discounts and promotions

Let Agents submit discount codes and understand which promotions the Service applied, including automatic discounts. Results could explain the affected items, the amount saved, and why a submitted code was rejected.

A Service would evaluate eligibility and return the resulting totals. This would help Agents explain the actual purchase terms without trying to reproduce the Service's promotion rules or assuming that every advertised discount applies to their purchase.

Loyalty and member benefits

Help Agents recognize benefits available through a customer's existing membership, such as member pricing, free delivery, or rewards earned on a purchase. Services could explain which benefits apply and distinguish confirmed benefits from those that still require membership verification.

The Service would retain its loyalty program and membership records. ODP would communicate the relevant benefits so an Agent can compare the terms available to that customer, rather than relying only on public prices.

Help shape ODP

Which of these capabilities would help your Service, or what other interaction does ODP need to describe? Tell us what your application needs and how an Agent would use it. These directions invite feedback; they are not a release schedule.

Contact us: nas@inflowpay.ai