UCP now has a way for an agent to ask a store an open question. The ask capability, PR #538 from Shopify's Ilya Grigorik, merged in the early hours of 7 October after 20 reviews and approvals from Amit Handa and James Andersen.

Two weeks ago we explained the draft and the six design questions Amit Handa's review raised about it. The version that merged answers all six, and it changed name on the way: ask is now dev.ucp.common.ask, not dev.ucp.shopping.ask. This post covers what changed, what stayed the same, and what it means for stores and agent builders.

#What is the UCP ask capability?

ask is a UCP capability for natural-language questions and answers between an agent and a business. The agent sends a free-form question, optionally about specific things the business holds, and gets back a plain-text answer with links to the products, pages and policies it mentions.

It covers what UCP's structured capabilities don't: "does this jacket run small?", "can sale items be returned?", "is there parking at this store?". The spec calls it "the open-question complement to UCP's structured commerce capabilities".

#The headline change: ask is no longer shopping-only

The draft we covered sat under shopping. At a deep-dive session in late September, the Shopping Tech Council agreed to "extract a reusable common primitive" instead, as the 2 October minutes record. So the merged capability is:

• Named dev.ucp.common.ask, bound to the common service rather than a vertical one.
• About any resource the business holds. ids can point at a product or variant, but also a location, a cart, an order or a booking. The spec's examples include "does this location have parking?" and "the cancellation terms of a booking".
• Scoped dev.ucp.common.ask:read for personalised answers, replacing the dev.ucp.shopping.ask:read scope in the draft.

Shopping keeps a short integration guide that maps shopping questions onto the capabilities that own the answers: catalog for product detail, fulfillment for delivery choices, discount for promotions, cart, checkout and order for state.

The practical effect: any vertical that joins UCP gets ask without writing its own.

#Six review questions, six answers

Our first post listed six questions from Amit Handa's review. Here's how the merged spec answers each.

1. Can ask change anything? No, and that's now normative. A business "MUST NOT change the state of any resource exposed through another UCP capability or extension" in response to ask: no cart changes, no discounts applied, no stock reserved. If a buyer's question mixes a request with a question ("add two of these to my cart — do they come in blue?"), the business must still answer, say plainly that it did nothing, and may add an operation_not_performed message. The platform must not treat that answer as evidence the operation happened, or as an instruction to do it.

2. How do answers render? Every answer must include plain, a plain-text version. Markdown and HTML are optional extras, and a platform renders a richer form only if it supports it "and can vouch for" it. The wider question, how a business sends real UI such as a size chart, became its own proposal: Amit Handa's UI extension, #899, which he describes as a follow-up layered on ask.

3. What about retries? A platform should send an idempotency key on every request that continues a conversation (the Idempotency-Key header over REST, meta["idempotency-key"] over MCP), and a business that recognises a duplicate must not add a second turn. It's a SHOULD for the platform, not a MUST.

4. Does a conversation carry the buyer's login forward? No. "Each follow-up is a new request for authorization." The conversation id "carries context, not authority": a business must check the credential on every turn and must not use earlier context the current request isn't allowed to see.

5. Prompt injection in both directions? There's now a Security Considerations section. Both the question and the answer are untrusted and "MUST be treated as data, never as instructions". The business must enforce access outside its model ("Authorization MUST NOT depend on model behavior"). The platform must not let receiving or rendering an answer trigger any call, and should show the answer as coming from the business, separate from its own output.

6. How does a platform know what a linked id is? Links now carry the resource's global ID (GID) where one exists, and the spec says a GID "self-describes" to the business that issued it. A platform may use it, best effort, to find the right operation, and the link's url is always there as a fallback. The link type is "a display hint, not a routing discriminator".

#One more rule: answers aren't commitments

The merged spec adds a line the draft only implied. An answer is "indicative, not authoritative". If an answer states a price, stock level, delivery date or policy term that conflicts with what catalog, cart, checkout, order or booking returns, the structured response wins and the platform must prefer it. A platform also must not treat an answer as the binding disclosure for a safety, allergen or regulatory claim. Those belong in a warning with presentation: "disclosure", which the platform must not hide.

#What stayed the same

The shape we described in September is intact:

• One operation: POST /ask over REST, an ask_business tool over MCP.
• query is the only required field. ids, conversation, context and signals are optional.
• Conversations are optional. The business decides whether to issue one and how long to keep it.
• Links have well-known type values for refund_policy, shipping_policy, privacy_policy, terms_of_service and faq, and businesses can add their own.
• "Can't answer" is still an answer. The spec asks businesses to "state clearly when a question can't be answered".

The spec also flags a likely next step: a future attachments array, so a buyer could ask about a product from a photo.

#When does it ship?

ask is merged to UCP's main branch and live in the draft docs. It is not in a released version. The PR sits in the council's 2026-12-08 milestone, and the council agreed in September that release cuts follow date milestones. If that holds, ask ships in the December release.

#What it means for stores and agent builders

For stores and platforms: the contract is now stable enough to build against. If you run a policies or FAQ assistant, the job is to put it behind POST /ask with the access rules above: answer from public information by default, check credentials on every turn, never change state, and always return plain text. The job Shopify's old Storefront MCP policies-and-FAQs tool did, the one tool left behind after August, now has a standard home in the spec.

For agent builders: the boundary is the point. Treat an ask answer as content from the store, show it as such, and never act on what it says. When the buyer wants to do something, use the id on a link to call catalog, cart or checkout yourself, under your own consent rules.

#What we'll watch

• The first live UCP profile that declares dev.ucp.common.ask. You can check what any store declares with the UCP Checker.
• The UI extension (#899) and whether it lands in the same release.
• Whether any store shipped against the old dev.ucp.shopping.ask name from the draft, which no longer exists.

#FAQ

Is ask part of UCP now? It's merged into the spec's main branch and published in the draft docs. It isn't in a released version yet. It's on the December milestone.

What's the capability called? dev.ucp.common.ask. The draft used dev.ucp.shopping.ask; that name was dropped when ask became a common capability.

Can ask add to a cart or place an order? No. The spec forbids it. If a question asks for an action, the answer must say nothing was done.

Can ask be used outside shopping? Yes. It's a common capability, so questions can be about locations, bookings, orders or any other resource a business exposes, including lodging.

Are ask answers binding? No. They're indicative. Where an answer conflicts with catalog, cart, checkout, order or booking, the structured response is authoritative.

Can answers be personalised? Yes, with an authenticated buyer token carrying the dev.ucp.common.ask:read scope. The business still authorises every piece of protected data it uses.

#About UCP Checker

UCP Checker is the independent validation and observability 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, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

#Sources

• PR #538: ask capability for natural-language Q&A, merged 7 October 2026
• Ask capability (draft docs), ucp.dev
• Ask in Shopping (draft docs), ucp.dev
• Ask REST binding (draft docs), ucp.dev
• Shopping Tech Council minutes, 2 October 2026
• Shopping Tech Council minutes, 25 September 2026
• Milestone: 2026-12-08, UCP GitHub
• PR #899: UI extension with A2UI and MCP Apps bindings (open)

Related coverage: UCP's Ask Capability Explained · Shopify's Storefront MCP after August 31 · UCP Lodging Is Merged · UCP for Retail