Shopify recently published a 47-minute conversation between CEO Tobi Lütke and Distinguished Engineer Ilya Grigorik — Building the Universal Commerce Protocol — and the throughline isn't really commerce. It's protocol design as a craft. Grigorik calls it the highest form of software engineering: done right, a protocol disappears, the way TCP retransmits packets you never think about.

We spend our days on the other half of that craft. A protocol is a set of promises about how two parties negotiate; validation is how you confirm the promises are actually kept. Design sets the rules — validation checks that real implementations follow them. The two are complementary disciplines, and you need both for an open protocol to work.

So this is a pairing: the design principles from the conversation, and what our validation layer sees across 6,391 verified UCP stores and over 1.5k agent shopping sessions. The design side and the validation side of the same coin.

#What the conversation is really about

Strip the episode and Grigorik's follow-up thread to their core and you get a short list of design principles — the same ones that make any good protocol work:

• Negotiate, don't blueprint. UCP doesn't try to "spec commerce" — "it's hubris to pretend anyone can," Grigorik says. It models "the rules of the bazaar that make commerce possible" and lets the market decide the rest.
• A small, boring, shared core, plus open extensibility on top.
• Discovery and negotiation as primitives — "no central registry. Profiles advertise what each side supports."
• Escalation that fails open, not closed.

Tobi's framing is the cathedral and the bazaar: a cathedral is one blueprinted checkout; a bazaar is organic variety. The clever move is writing a protocol for the bazaar. It's genuinely elegant design — and every principle on that list implies something you have to be able to verify. That's the validation layer. Here's how the two line up.

#Negotiate, don't blueprint → discovery is the front door

Grigorik's favorite example is HTTP: a client advertises Accept-Encoding, a server that understands it uses compression, one that doesn't sends plain text — and nobody had to ratify every algorithm in advance. UCP works the same way: "you can bring any flavor of discount that you like," he says, "as long as both parties agree." Define the negotiation, then get out of the way.

The validation counterpart is simple: a negotiation needs a front door, and that door is discovery. Of the 7,190 domains we track, 6,391 (89%) expose a verifiable UCP profile an agent can actually read. Validation is confirming that door is open and well-formed before an agent ever knocks — is your store discoverable and ready?

#A boring core + open extensibility → vindicated by the data

The shared vocabulary — boring, common types like line_item, price, and currency — is what makes composition coherent. It's a deliberately small core, with the interesting variation pushed into extensions.

The data vindicates the call. Among verified stores, the core is effectively universal — checkout 99.7%, cart 99.4%, order 99.5%. The extensibility layer — identity linking, payment tokens — is where adoption is still early. That's not a flaw in the design; it's the roadmap.

This is exactly where validation earns its keep: before an agent relies on a capability, it needs to know whether a given store actually supports it. Identity linking is the frontier that turns an anonymous agent into a recognized customer; payment tokens are the one that raises the trust and liability questions the whole industry is still working through. And the frontier is already moving faster than it looks — a fully autonomous purchase has already completed end-to-end on a real store, an agent paying from a store-credit wallet, even before the standardized payment_token capability is widespread. The rails are arriving; validation is how you see them arrive.

#Discovery and negotiation as primitives → validation is the trust layer

This is the principle our work exists to serve. Grigorik is explicit: "no central registry. Profiles advertise what each side supports," and the market decides what's adopted. It's the right call — central registries don't scale to a bazaar.

But a world that runs on self-advertised profiles needs a trust substrate: someone has to verify that the advertisement matches the behavior. When a store declares it supports checkout, does the endpoint actually complete one? When it claims a capability, does it conform to the spec? That verification is the validation layer — the independent check that lets a decentralized, no-registry protocol stay trustworthy as it scales. Good design makes the negotiation possible; honest validation makes it dependable.

#Escalation that fails open → observability makes it real

UCP's best primitive is that it "fails open, not closed," as Grigorik puts it — when an agent hits something it can't resolve, it hands control back to a human gracefully instead of dead-ending. "Today's escalation," he adds, "is tomorrow's automation."

You only know whether a real failure failed open (a clean handoff) or closed (a lost sale) if you can observe it. Across over 1.5k agent sessions spanning 150+ stores and 16 models, we see the full range — and the happy path is real: that first fully autonomous purchase passed cleanly through an escalation state before completing. Observability is how the ecosystem learns which of today's escalations become tomorrow's automation.

#The spec evolves → validation has to keep pace

Protocols improve — HTTP went 0.9 → 2 → 3 — and UCP ships breaking changes deliberately. The healthy signal here is speed: 99.6% of verified stores already run the latest 2026-04-08 spec, because platform-level updates move the whole field at once.

A spec that moves that fast needs a validation layer that moves with it. Always-current conformance checking is what keeps "is this store conformant?" anchored to the spec the ecosystem is actually running today — so the verification half never falls behind the design half. That's a service to the whole ecosystem, builders and merchants alike.

#Two halves of the same craft

Designing a protocol and validating its implementations are complementary disciplines. The conversation is a master class in the first; everything we build is the second. Grigorik's principles — negotiate don't blueprint, a boring core, discovery without a registry, fail open — are exactly the principles that create the need for an independent validation layer. Good design plus honest validation is how the bazaar stays open, vibrant, and trustworthy for merchants, agents, and buyers alike. Readiness still varies a lot by industry vertical — which is the best argument for measuring it.

If you build on UCP or run a store on it, check any domain's live profile and conformance — and see where it lands with the UCP Score.

#Sources

• Shopify — Building the Universal Commerce Protocol (Tobi Lütke & Ilya Grigorik)
• Ilya Grigorik — protocol-design thread on X, May 2026
• Universal Commerce Protocol specification — ucp.dev
• Our analysis — The first fully autonomous AI agent purchase and UCP now supports identity linking

#About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol — the verification half of the craft above. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and test how real AI agents behave against real stores.

• Check your store: ucpchecker.com/check
• Grade it (UCP Score): ucpchecker.com/score
• Validate a manifest: ucpchecker.com/ucp-validator
• See capability & payment coverage: ucpchecker.com/capabilities
• Browse the directory: ucpchecker.com/directory
• Get notified on changes: ucpchecker.com/alerts

Capability and conformance figures from UCPChecker's monitoring of 6,391 verified UCP stores. Agent-behavior figures from UCP Playground sessions across 150+ stores and 16 models. Data as of May 2026. Part of our ongoing State of Agentic Commerce series.