📢 Heads up: A New Version of UCP is Coming soon!

[amithanda]

Hello UCP Community! 👋

We are excited to share that a new version of the Universal Commerce Protocol is slated for release within the next two weeks. The next version marks a significant step forward in our mission to build a strong foundation for agentic commerce.

✨ Release Highlights

We are introducing several key improvements to the protocol, including:

• New Capabilities: Support for Catalog & Cart to enable more seamless discovery and multi-item purchase flows.
• Protocol Hardening: Improvements to UCP core constructs like versioning and enhanced error handling.
• Payments: Enhancements to payment handlers.

🙏 Acknowledgments

We want to thank everyone who has contributed feedback and code to make the upcoming version possible. Your input is what drives the protocol forward.

Stay tuned for the official release notes when we release the new version!

Questions or feedback? Drop a comment below! We’d love to hear your thoughts on the upcoming changes.

[revanth-zolofy]

Huge milestone, especially the addition of Catalog + Cart and multi-item flows.

One architectural question from an implementer working on non-static commerce (custom goods, hospitality, rentals): in these cases, the product and price often don’t exist as a fixed catalog item upfront. They only become concrete after the agent collects parameters and the merchant-side system resolves them deterministically.

The pattern I’m currently using is:

1. Agent extracts structured parameters
2. Merchant-side logic computes price / fulfillment
3. A temporary resolved item (“Ephemeral SKU”) is minted
4. That resolved item is passed into checkout

With UCP v2’s new Cart support, is the intended pattern to inject these resolved single-use items directly into Cart once pricing is fixed? Or are there new v2 primitives around pre-cart quoting / dynamic catalog generation for this class of merchant?

Would love to align early with the intended path.

[haunic]

I have a similar observation. I work for a global leader in IT solutions for the travel industry, and UCP’s current architecture is not equipped to manage perishable inventory. Specifically, when searching for flights or hotel rooms, providers cannot hold inventory indefinitely; they must release seats or rooms if a transaction isn't completed within a set timeframe.

Currently, there is no mechanism for merchants to notify clients when inventory is released or when a new availability check is required. This limitation is a primary reason why UCP is not yet viable for the travel sector. I would be happy to discuss this further and contribute to a solution (and join a Travel Domain Working group together with some of our travel customers and partners).

[revanth-zolofy]

Very interesting point and I think it’s closely related to the same structural issue.

In my case, I’ve been looking at non-static pricing where the object doesn’t fully exist until merchant-side logic resolves it. In travel, the challenge is slightly different, but equally stateful: the object may exist, but inventory validity and hold/release windows can change before settlement.

Feels like both cases point to the need for stronger protocol support around time-bound merchant authority before final transaction execution.

[appdrops]

Great thread — this hits on something we've been working through in practice at UCP Playground.

Both use cases share the same root problem: agents have no protocol-level awareness of temporal validity. Revanth's resolved ephemeral SKUs can expire or reprice between minting and checkout. Nicolas's perishable inventory holds can be released before settlement. In both cases, the agent treats merchant data as a fact rather than a decaying signal. That's where things break.

In the non-agent world, this is already solved per-vertical. Airline GDS systems return ticket time limits on every fare quote. E-commerce platforms use cart reservation timers. Hotel PMS systems issue hold windows on room blocks. The pattern is universal — the merchant signals "this offer is valid for N minutes" — but every vertical implements it in its own proprietary way.

What's missing from UCP is a standardised primitive for this. Something like a validity_window or offer_ttl that a merchant includes in the tool response, telling the agent: this data expires at timestamp X. The agent then knows whether to proceed with checkout or re-query first. It works the same whether the underlying inventory is a flight, a floral arrangement, or a hotel room.

A time-bound session authority primitive — where merchants signal validity windows back to the agent — would address both the ephemeral SKU lifecycle and the perishable inventory hold problem in a single protocol-level concept, rather than pushing each agent to guess per vertical.

Happy to support a working group if one forms to test this against real agent sessions. We've been running transactional workflows against perishable inventory in UCP Playground and could provide a practical testing environment for whatever the group designs.