Changelog
UCP versions are dates, so a version string tells you when something changed but not whether it breaks you. Every release here is read and written up, with the part that matters first: whether you need to do anything.
Not written up in plain English yet. The specification authors' notes are on the entry.
Read the full entryThe largest release so far, and the one that makes UCP feel finished rather than provisional. Cart arrives as its own capability, so an agent can build a basket over several steps instead of assembling everything in one shot at checkout. Errors become a first-class concept. Until now a failed negotiation between an agent and a merchant had no agreed shape, which meant every implementation guessed. There is now a defined way to say what went wrong. Request and response signing lands, which matters more than its one line in the notes suggests. It is the same idea appearing across the agentic web: an origin should be able to verify who is talking to it rather than trusting a string in a header. Smaller additions: an intent field in context for relevance, multi-parent schema inheritance with deterministic resolution, a colour scheme parameter for embedded checkouts, available payment instruments on handler configuration, and fulfillment method type becoming optional on updates.
What to do
Nothing breaks if you do not act. If you sell anything with a multi-step basket, the new cart capability is the reason to revisit your integration. If you care about being able to tell real agent traffic from anything else, look at request signing.
A short release with one significant change: a refactor marked as breaking by its own commit, landing twelve days after the initial version. The upstream notes are thin here. They record that the release happened and that it breaks compatibility, but not what specifically moved. If you integrated against the 11 January version, compare against the diff rather than trusting the summary. This one is worth remembering as a pattern rather than for its contents. A specification this young will break things, and it will not always explain itself well when it does. That is the argument for checking your integration on a schedule rather than after you happen to read a release note.
What to do
If you built against v2026-01-11, read the GitHub diff for this release directly. The upstream notes are not detailed enough to tell you whether you are affected, so verify rather than assume.
The first tagged release, published alongside the protocol's public launch. The bulk of the commits are documentation, linting and repository setup rather than protocol changes, which is what a first tag usually looks like. Useful mainly as a reference point. This is the baseline that later releases are diffed against, and the version anyone who integrated at launch will have built on.
Read the full entry