A dated timeline of agentic commerce announcements

01

The five fields used in the timeline

Applies to marketplace onlyown storefronthybrid

Events in this field are often described with a single general term — a protocol is "launched", a surface "supports" checkout, a program "goes live". The timeline records each event in five separate fields instead, because each field answers a different question and is supported by a different kind of evidence.

The fields are kept separate because one does not imply the next. A specification does not by itself provide access. An access path does not by itself provide a test environment. A test environment does not itself document production use. Recording each answer in its own field, with its own source, keeps those distinctions visible when an entry is read months later.

Separate does not mean exclusive. Most events fill more than one field at once: a specification release is both an announcement and documentation, a policy amendment is an announcement that changes merchant access, and a foundation launch is an announcement that carries governance information. The fields record what an event establishes, and a single event can establish several things.

02

The timeline at a glance

Applies to marketplace onlyown storefronthybrid

These are the dated entries in the current record, in order. Two of the sources are continuously updated documentation with no publication date of their own; they appear at the end with that status noted, and the date that matters for them is the date you read them.

Testing availability and documented production use do not appear in the right-hand column for any entry, because the current cited sources do not fill those fields. The rest of this lesson explains how the entries are maintained and how to read them against your own channels.

03

How entries are recorded

Applies to marketplace onlyown storefronthybrid

The timeline is kept as a data file checked into the repository, not as prose. Every entry records its date, its governing party, the version it describes, and its source. Each of the five fields is either filled in or intentionally left empty.

This structure keeps claims tied to sources. To record that a protocol has a test environment, the maintainer fills in the testing field and attaches the source that documents it, so a reviewer can check one against the other. An empty field means the current cited sources do not provide that information.

Some sources make version identification easy. One specification includes its snapshot date in the document’s URL, so readers can tell exactly which version they are looking at and compare it with the version they built against earlier.⁴

04

Information currently included

Applies to marketplace onlyown storefronthybrid

The entries recorded so far contain three main kinds of information. These are not separate buckets — as the table above shows, a single entry usually contributes more than one kind, so the groupings below describe what the sources contain, not a sorting of entries.

Specification documents. Dated, versioned snapshots have been published, and they describe interfaces in enough technical detail to build against.¹ These fill the documentation field for their entries.

Governance information. Some entries record who stewards a specification and under what structure. For example, a payments protocol moved to a foundation under neutral stewardship in July 2026, with roughly forty founding organizations across three membership tiers.² A governance entry of this kind documents membership and stewardship arrangements. Implementation and deployment are separate facts, recorded in their own fields when a source documents them.

Production use. The documented-production-use field is currently empty for every entry: the cited sources do not include a documented production transaction for a specific merchant’s goods. The published materials from the operating parties do not include per-merchant transaction figures, and no independent source in the registry provides them. As with any empty field, this records what the sources contain, not whether the underlying activity is or is not occurring.

05

Access rules and policy changes

Applies to marketplace onlyown storefronthybrid

The timeline records policy changes as ordinary entries, not as a separate category. A policy entry is itself an announcement with a date and a source; what distinguishes it is which field it changes — usually merchant access, and usually for paths that already existed. Access rules move in both directions, and the changes often arrive as amendments to governing documents rather than as press releases. One documented example: the February 20, 2026 amendment restricts buy-for-me agents, LLM-driven bots, and end-to-end automated ordering on a major marketplace unless the operator has prior express permission.³

Including both kinds of entry gives a fuller picture when you read the record against your own channels. A launch entry may describe a path you could apply for; a policy entry may describe a rule that already applies to a venue where your inventory is listed. For a seller on that marketplace, the February 2026 entry describes a current, in-force condition, which is why policy entries carry the same date-and-source treatment as launches.

06

Gaps in the public record

Applies to marketplace onlyown storefronthybrid

The timeline is built from published, dated sources, and some kinds of events do not generate one. A discontinued pilot, a program that stops accepting applications, or an integration that no longer appears in a partner list often ends without a dated public document.

Because of this, the timeline records publicized starts more completely than quiet stops. Where a change is visible only through a page ceasing to exist, the course records nothing rather than inferring an event without a source. Readers should treat the ledger as a record of what has been published, with the understanding that program closures may exist that no current source documents.

07

Using the timeline as a merchant

Applies to marketplace onlyown storefronthybrid

For most merchants, the most useful field on any entry is merchant access, because it is the field that can describe an available action. A practical way to read the timeline is to check that field first and note what, if anything, it makes available to you.

1. Take the three most recent entries and read each one’s merchant-access field.
2. For each, note the concrete step the sources describe — an application, a feed field, a settings check, a policy read — or note that the sources describe no path available to you. Both are useful notes to keep.
3. Note which steps you could undo within a day, since easily reversed steps can be taken while other fields are still empty.
4. Revisit the notes when the record next changes.

Applied to the Meridian camera, the access field gives different answers for different entry types:

Two rows come directly from their sources. Onboarding for one feed program is documented as limited to approved partners and entered by application, so access for a non-partner merchant currently means applying and waiting.⁵ Separately, one platform enables eligible stores by its own decision, so participation can already be active without the merchant having taken any step⁶ — which is why checking your current settings appears in the table as an available action.

08

Current summary

Applies to marketplace onlyown storefronthybrid

The timeline currently spans September 2025 through July 2026, plus two continuously updated documentation sources. Its entries include: specification snapshots with dates and versions; a governance launch with named memberships and stewardship tiers; access paths with documented eligibility criteria and application processes; a platform that enables participation for eligible stores by default; and a marketplace policy, in force since February 20, 2026, restricting automated ordering without prior express permission. Many entries fill several fields at once, which is why the record is read by field rather than by entry.

Public information remains incomplete in two areas. The cited sources do not include documented production transactions or per-merchant usage figures, and events that end without an announcement — closed pilots, paused programs — may not appear at all.

When reading any entry, an empty field means the current cited sources do not provide that information. Filled fields carry a date and a source, so they can be re-checked when either changes.