For five months, "UCP store" has meant one thing: an agent can find it, cart it, and reach checkout. Everything after the buy — shipping options, delivery promises, pickup, returns — has been left to each merchant's static configuration.

That changed this week. Google opened two new fulfillment proposals — and one of them proposes writing an 800-millisecond deadline directly into the protocol. They join a catalog-level fulfillment change already in review and a standing local-inventory RFC: the post-checkout layer is finally being built in the open.

#What landed this week

The work spans a few stages — two brand-new proposals from Google, a pull request already in TC review, and the standing RFC they build on:

• #532 — Partner Sourced Fulfillment (ranaj-google, June 19 — newly opened, awaiting triage). An outbound broker hook so a store can query a third-party logistics (3PL) partner for live shipping options, cost, and delivery speed at request time — instead of duplicating "complex rate sheets, regional zone definitions, and warehouse logic" into its own config. Three new structures: FulfillmentPartner (auth/linking), FulfillmentRoutingPolicy (merchant chooses local vs. partner-sourced), and a FulfillmentOption gaining a fulfillment_tier enum (default | fastest | loyalty).
• #531 — Delivery Instruction (ranaj-google, June 19 — newly opened). Structured "leave it at the back door" delivery guidance.
• #507 — Fulfillment methods on catalog (igrigorik, in TC review). A breaking change (feat!) surfacing fulfillment options at the catalog layer, not just at checkout.
• #375 RFC — Store-based local inventory & fulfillment (maximenajim — a standing RFC, in TC review). A three-phase plan: local product discovery → buy-and-collect → omnichannel and split shipments.

The sequencing is deliberate: the Technical Council explicitly slotted the Returns extension (#257) to land after the fulfillment deep-dive. Fulfillment is the spine the rest of the post-purchase layer hangs off.

#Why fulfillment is the hard part for an agent

Discovery and checkout are deterministic — the catalog says what's for sale, the cart says what it costs. Fulfillment is not. Shipping price, delivery date, and availability are dynamic, partner-sourced, and regional, and an agent can't complete a confident purchase without an accurate delivery promise. Stuffing all of that into static merchant config is exactly the "brittle, proprietary middleware" #532 calls out — and it sets up a familiar failure mode: an agent acting confidently on a delivery promise that has quietly gone stale.

A live broker hook fixes the staleness. It also introduces a new problem.

#The 800ms budget is the real headline

Here's the line that matters: #532 proposes capping the external partner call at ~800ms before a fallback activates. That would put a latency budget straight into the spec — and latency is precisely what we measure across the monitored directory.

A partner-sourced fulfillment call adds a network hop inside the checkout path — exactly where latency already decides whether an agent completes the buy or gives up. 800ms is generous against a 152ms baseline, but it's a budget that has to hold under load, through a third party, on top of everything else in the request. The proposal drawing that line now, before adoption, is the protocol learning from its own reliability gap: a store can be perfectly conformant and still time out an agent. We've made that distinction the editorial spine of every ecosystem report — conformance is not agent-readiness, and a slow fulfillment broker is a brand-new way to be conformant but unbuyable.

#Where fulfillment sits today

Fulfillment isn't new as a name — dev.ucp.shopping.fulfillment is already declared by roughly 8,215 verified stores, because Shopify bundles it. But today that declaration is static: a fixed set of methods baked into the manifest. What #532 and #507 do is turn fulfillment from a static declaration into a live, partner-sourced, catalog-level surface. The capability count won't move much; what moves is whether the thing behind the name can answer an agent in time.

That's the through-line of the whole capability cliff: declaring a capability is the easy 99%; making it fast and reliable at runtime is the part that separates a manifest from a sale.

#Why verticals make this urgent

Fulfillment is also where UCP's vertical expansion gets real. At Google Marketing Live, Google said UCP is moving into hotel booking and food delivery — and there's now a domain council charter for food ordering (#518). Those verticals are fulfillment-first: a hotel night or a food order is a delivery promise with a hard time window. A retail cart can tolerate a vague ship date; a hotel booking or a dinner order cannot. The fulfillment layer being specced now is the substrate those verticals will stand on.

#What to watch

• Does the 800ms budget survive review — and can stores meet it? A proposed latency ceiling only matters if it lands and real partner integrations clear it. This is measurable, and we'll measure it.
• The first store to declare partner-sourced fulfillment. Like every deep primitive, it'll start at one or two stores. The question is whether Google's demand-side pressure (Target and Walmart now live in Gemini) pulls it off the cliff faster than identity or AP2 moved.
• Returns next. With #257 sequenced after the deep-dive, the post-purchase layer keeps filling in.

UCP spent its first phase proving an agent can buy. The fulfillment layer is the start of the harder phase: proving an agent can be told the truth about delivery — fast enough to close the sale.

#About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and — through UCP Playground — test how real AI agents behave against real stores. Response-time budgets like the 800ms ceiling in #532 are exactly what we measure, store by store.

• Check your store: ucpchecker.com/check
• Grade it (UCP Score): ucpchecker.com/score
• Browse the directory: ucpchecker.com/directory
• Track adoption live: ucpchecker.com/stats

#Sources

• #532 Partner Sourced Fulfillment · #531 Delivery Instruction · #507 Fulfillment methods on catalog · #375 Local inventory RFC
• UCP TC minutes, 2026-06-05
• Latency figures from the UCP Checker crawler as of June 2026 — live stats; see also the June ecosystem report.