When Google named local food delivery as a UCP vertical at Marketing Live, it was a single line in a keynote: order food "from a conversation in Google Maps." We mapped what that would take — live menus, a modifier explosion, hyperlocal fulfillment windows — and noted that an announcement is not a release.

A proposed Domain Tech Council (DTC) charter for Food Ordering — opened on GitHub on 15 June — just turned that keynote line into a roadmap. It names a committed core of participants and lays out three phases for how agentic food ordering gets built. There is still no schema to validate against. But, as with the lodging charter that followed it nine days later, there is now a shape — and the shape is telling.

Here is what the charter commits to, why its sequencing is the part to read closely, and the food-specific problems it still has to solve.

#The participants: a committed core

The charter lists Google as the consumer surface, alongside four businesses ready to implement UCP capabilities for food ordering: DoorDash, Toast, Square, and Uber Eats.

That is a serious table. DoorDash and Uber Eats are the demand-side marketplaces; Toast and Square are the point-of-sale platforms that the restaurants themselves run on. Getting both the aggregators and the POS layer onto one standard is the difference between a protocol that reaches a few chains and one that reaches the long tail of independent restaurants. A standard lives or dies on who actually ships it, and this is the first signal of who will.

#The roadmap, phase by phase

The charter sequences the work into three stages. Quoting the proposal:

Phase 1 (MVP) — core checkout actions. Three capabilities: Identity Linking ("to unlock loyalty status, rates, etc. — including new user setup"), Checkout ("covering fulfillment selection, loyalty, tips and supporting sensitive journeys with age restrictions (e.g. alcohol orders)"), and Get Order ("to guide users post-order with tracking links and clear confirmation"). In plain terms: an agent can link your account, place and pay for an order — handling delivery choice, tips and an age check where it is needed — and hand you a tracking link.

Phase 2 — the end-to-end journey. Menu Catalog ("to discover rich food menus and required modifications"), Cart ("for conversational cart building incl. dish modifications, upsells"), and a Discount Extension for "merchant specific discounts, promos, and loyalty-based discounts." This is where the menu and the modifier tree finally get standardized.

Phase 3 — personalization. Detailed order tracking (live ETA) and history ("reorder the usual"), plus voice-based ordering and payment fingerprinting.

#The tell: it starts at checkout, not the menu

Read the sequencing again. The menu — the part everyone pictures when they imagine "ask an agent to order dinner" — is not in Phase 1. It is in Phase 2. The cart is in Phase 2. What comes first is identity, a checkout that can take payment, and an order confirmation.

This is the same pattern the lodging charter showed: the money-moving core is built before discovery. It is not an accident, and it is not a coincidence across two verticals. It reflects a deliberate bet that the hard, trust-sensitive part — confirming a real order and taking payment safely — is the foundation everything else sits on, and that discovery can be layered on once the checkout contract is solid.

There is a second tell in the proposal's reasoning. The charter explicitly leans on UCP primitives that already exist: "Identity Linking and Loyalty are common capabilities that are readily usable for food ordering user journeys today." Food ordering is not starting from a blank page — it is bootstrapping off the retail-native commerce loop and adding the domain-specific pieces (a menu model, a dish line-item, fulfillment extensions) on top. That is exactly the cross-vertical reuse UCP was restructured to enable.

#The food-specific problems the charter still has to solve

A roadmap is not a schema, and the genuinely hard parts of food ordering are precisely the ones a charter can name but not yet define:

• The modifier explosion. "Required modifications," upsells and dish modifications are listed for Phase 2 — but the proposal itself calls food "a runaway explosion of permutations: stacking modification rules." A burrito with three required choices and a dozen optional add-ons is not a SKU; it is a small constraint-satisfaction problem. The Menu and Cart capabilities have to carry deep, self-validating option trees, or agents will build carts the kitchen can't make.
• Age-restricted and sensitive orders. Putting alcohol and age restrictions in Phase 1 checkout is the right call — but it is also the hardest contract to get right. An agent needs a machine-readable way to know an item requires verification, and a defined handoff for performing it, before it commits the order. Get this wrong and you have either a blocked legitimate order or a sold restricted item.
• Live availability and the clock. Items go 86'd mid-conversation; a store's delivery radius and window change by the minute. The charter's "real-time availability" is the right goal, but the contract for how an agent re-checks before it commits is the part that decides whether the order is real. This is the same expiring-inventory failure mode we measured in travel, in a hyperlocal key.
• All-in pricing. Delivery fees, service fees, tips and taxes mean the menu price is not the total. Until the fee and tip model is specified, agents will quote the wrong number.

These are not criticisms of the charter — they are the agenda it implies. Phase 1 cannot ship safely until the age-check and availability contracts have answers, which is exactly why measuring real agent behaviour against real menus matters now, before the spec freezes.

#What restaurants and ordering platforms should do now

You do not have to wait for the schema to get ahead of it. The Phase 1 primitives are predictable enough to prepare for:

1. Expose live availability. A menu an agent can trust means real-time item and store-status data, not a static catalog. Validate your catalog.
2. Model your modifiers cleanly. Required choices, option groups and add-ons need to be machine-readable and self-validating before an agent can build a correct cart. Validate your endpoint.
3. Get discoverable now. Being agent-legible is the prerequisite for any of this. Run a free check.

We track UCP for Food Ordering on a dedicated vertical page, and we will update it — and validate against it — the moment the spec lands. Two DTC charters in two weeks, both starting at checkout, is the clearest signal yet that UCP's expansion beyond retail is being built in earnest. The next milestone is the one that actually changes what an agent can do: a published spec with a menu model, a modifier tree, and an age-check contract.