AI Agents Can Now Ask Businesses Directly: Will UCP Ask Turn GEO Into an Answer Interface?

A shopper looking at a winter jacket asks an AI assistant two questions: Does it run small? Can sale items be returned? Today, the assistant usually assembles the answer from whatever it can retrieve: product pages, feeds, reviews, policy pages, and third-party sites. The business shapes that answer, but it does not get to answer the question itself.

On October 7, 2026, the Universal Commerce Protocol (UCP) merged a change aimed at that gap. Pull request #538 adds an ask capability: a platform acting for a buyer sends a free-form question to a business and receives a business-authored text answer with optional related links [1][2]. The draft Shopping guide uses the same jacket scenario: the business replies that the item runs true to size and that sale items can be returned within 14 days for store credit [6].

Two facts frame everything that follows. First, Ask is a draft. It is merged into the main branch and published in the specification's draft documentation, but it is not part of the latest release, v2026-08-25 [3][7]. Second, as of October 8, 2026, we found no public announcement that ChatGPT, Gemini, Google AI Mode, Microsoft Copilot, or any other AI platform calls Ask in production.

So this is not a "do this now to rank" story. It is an early signal of where GEO may extend: from optimizing pages that AI systems retrieve to operating an answer interface that AI agents query.

---

The Short Answer

UCP Ask (dev.ucp.common.ask) is a draft, read-only question-and-answer capability. A business exposes it over REST as POST /ask or over the Model Context Protocol (MCP) as the ask_business tool, and advertises it in its UCP profile at /.well-known/ucp [4][5]. It targets questions that structured commerce data handles poorly: fit, materials, compatibility, returns, shipping, warranty, refunds, store hours, and accepted payment methods [3].

For GEO, the shift is from pages an AI system reads to answers a business authors. Instead of hoping a model extracts the right sentence from a policy page, the business can return its own answer, link the authoritative source, and attach disclosures that a conforming platform must not hide.

Ask is also tightly bounded. Three rules define it:

1. Access: What a business may reveal depends on the credential presented with each request. A conversation ID carries context, never authority.
2. Effect: Ask answers; it does not act. It must not create or change a cart, checkout, order, or booking, apply a discount, or reserve inventory.
3. Authority: An answer is indicative, not a commitment. When it conflicts with the structured capability that owns the data, the structured data wins.

What Ask is not: a ranking factor, a feature any platform has publicly put into production, a replacement for your website, catalog, or structured data, or a binding statement of price, policy, or safety information.

---

What Was Merged on October 7, 2026

Google launched UCP in January 2026 as an open standard for agentic commerce, co-developed with Shopify, Etsy, Wayfair, Target, and Walmart and endorsed by more than 20 other companies [8]. Its existing capabilities, such as catalog, cart, checkout, and order, exchange structured resources.

PR #538, titled "feat: ask capability for natural-language Q&A," was opened on June 22, 2026 and merged on October 7, 2026 at 01:01 UTC. Before landing, it went through 20 commits, 24 review comments, and changes to 14 files, and it was labeled for the project's TC review [1][2].

During review, the capability moved from the Shopping vertical into the Common service. It is now bound to dev.ucp.common, so a single capability can answer questions about resources in any vertical a business exposes, including shopping and lodging [3].

The draft calls Ask the open-question complement to UCP's structured capabilities. Catalog, cart, checkout, order, and booking return machine-readable resources. Ask returns human-readable answers about business-specific facts and knowledge those resources may not express. The two are independently adoptable: a business may offer Ask alone, and advertising Ask does not imply support for anything else [3].

Draft status has practical consequences. Field names, message codes, and rules can change before Ask ships in a release. Any prototype should be pinned to a specific commit and treated as disposable.

---

How an Ask Call Works

The request

A request carries one required field and four optional ones [3]:

• query is the buyer's natural-language question and the only required field.
• ids names the resources the question is about: a product, variant, location, cart, order, or booking. A business should accept its own Global IDs (GIDs) and may also accept SKUs, handles, or URLs.
• context carries market and localization hints such as address_country, language, and intent. These are provisional; a business may ignore or down-rank them.
• conversation replays an opaque ID the business returned earlier, to continue a multi-turn exchange.
• signals carries environment data the platform supplies for authorization and abuse prevention. Signal values must not be buyer-asserted claims.

Without ids, a question applies to the business broadly, such as "What is your return policy?" With ids, it is grounded in a specific resource, such as "Is this washable?" A business that does not recognize an identifier still answers what it can and may flag the unresolved reference in an informational message.

The Shopping guide's example request [6]:

{
  "query": "Does this jacket run small, and can sale items be returned?",
  "ids": ["gid://business.example/Product/alpine-shell"]
}

The response

A response contains the answer and, optionally, links, messages, and conversation state [3]:

• answer.plain is required in every answer. markdown and html are optional alternative encodings. A platform renders a richer encoding only if it supports it and can vouch for it; otherwise it falls back to plain.
• links enumerate the entities the answer mentions. Every link needs a title and a url. When a link points to an addressable UCP resource, it should also carry the resource's GID in id, which a platform may use on a best-effort basis to match the link to a structured capability. The url remains the fallback.
• Each link has a type display hint. Well-known values are refund_policy, shipping_policy, privacy_policy, terms_of_service, and faq; businesses may add others, such as a product or a size guide.
• messages carry errors, warnings, and informational notes, with codes such as insufficient_scope, disclaimer, not_found, operation_not_performed, and promotion.
• conversation returns an opaque id and an optional expires_at when the business supports multi-turn exchanges.

The Shopping example response, with the UCP envelope omitted [6]:

{
  "answer": {
    "plain": "The Alpine Shell runs true to size. Sale items can be returned within 14 days for store credit."
  },
  "links": [
    {
      "type": "product",
      "url": "https://business.example.com/products/alpine-shell",
      "title": "Alpine Shell Jacket",
      "id": "gid://business.example/Product/alpine-shell"
    },
    {
      "type": "refund_policy",
      "url": "https://business.example.com/policies/refunds",
      "title": "Refund Policy"
    }
  ]
}

The pattern is worth copying: a short answer, one link per entity the answer names, and a GID only where a UCP resource exists. The refund policy is a page, so it gets a URL and no id.

The draft also signals where this may go next. A later version may add an attachments array for multimodal grounding, such as asking about a product from a photo [3].

"I can't answer" is still an answer

The REST binding returns HTTP 200 for every well-formed, authorized, in-limits request. Business outcomes, including "I can't answer that," travel in a populated answer and the messages array. HTTP error codes are reserved for transport problems: 400 for malformed input, 401 for missing or invalid authentication, 429 for rate limiting, and 500 for server errors. The MCP binding follows the same model: a successful JSON-RPC result for business outcomes and JSON-RPC errors only for transport issues [4][5].

The draft's non-answer example is instructive. The business says it has no information about competitor pricing and lists what it can help with instead [4]. For GEO teams, the fallback answer is content to design, not an error page to ignore.

Multi-turn conversations and retries

A business may return a conversation object. The platform replays it on the next turn and must not parse or construct the ID. If an ID cannot be resolved, the business should start a new conversation and note that in an informational message [3].

Retries are guarded by idempotency keys. Over REST, a platform should send an Idempotency-Key header on any request that carries a conversation. The business must store the key with its result for at least 24 hours, return the cached result when a duplicate arrives with a matching body, and return 409 Conflict if the key is reused with a different body [4]. Over MCP, the key travels in meta["idempotency-key"], and every request must identify the platform's UCP profile in meta["ucp-agent"].profile [5].

---

The Three Boundaries That Define Ask

1. Access: every turn is authorized again

The draft defines three access tiers [3]:

• Public: With no credential, Ask answers from public business information and public resources.
• Resource reference: An identifier in ids grounds the question in a resource. For a protected resource such as a cart or checkout, the business must apply its normal access policy. It may treat possession of the identifier as sufficient, require an additional credential, or decline to use the resource.
• Authenticated buyer: With a buyer identity token the business recognizes, under the dev.ucp.common.ask:read scope, the business may return personalized answers, such as member pricing, entitlements, gated availability, or information derived from protected resources.

The scope is not a blanket pass to a buyer's data. The business remains responsible for authorizing every protected resource and every item of information it uses. Each follow-up turn is a new authorization decision: a replayed conversation must not carry forward access granted on an earlier turn, and the business must not use or disclose retained context the current request is not authorized to access.

2. Effect: Ask answers; it does not act

A business must not change the state of any resource exposed through another UCP capability in response to an Ask request. If a query mixes an action with a question, the business must still return a populated answer that clearly says Ask did not perform the operation. It may answer the informational part and add an operation_not_performed message [3].

The draft's example: a buyer asks the business to add three more widgets and whether that qualifies for a volume discount. The business replies that it has not added anything and the cart is unchanged, then explains the rule: orders of 10 or more widgets get 15% off each widget [3].

The rule binds platforms too. A platform must not treat the answer or the message as evidence that the operation occurred, or as an instruction to perform it. Whether to call the cart capability is the platform's own decision, based on the buyer's original request and subject to that capability's authorization, consent, and idempotency rules [3].

3. Authority: answers are indicative

Prices, availability, totals, taxes, fulfillment estimates, and policy terms stated in an answer are not commitments. When an answer conflicts with what the owning capability returns, such as catalog, cart, checkout, order, or booking, the platform must prefer the structured representation. A platform must not treat an answer as the binding disclosure for a safety, allergen, or regulatory claim [3].

Those notices belong in warnings with presentation: "disclosure", which platforms must not hide or dismiss. The REST binding's example answers a question about a nut butter, defers to the on-product allergen disclosure as the authoritative source, and attaches an allergens disclosure warning [4].

The draft's answer-quality guidance follows from these limits. Businesses should keep answers to what fits in a conversation, link to resources such as size charts instead of inlining them, link the authoritative source behind each answer, carry regulated notices as disclosure warnings, and state clearly when a question can't be answered [3].

---

Security: Natural Language Crosses the Boundary Both Ways

Ask moves natural language across a trust boundary in both directions. The buyer's question reaches the business's model, and the business's answer reaches the platform's model. The draft requires both sides to treat that content as data, never as instructions [3].

For the business:

• Treat query as untrusted input that must not alter system instructions or authorization decisions.
• Enforce access tiers outside the model. What a caller may see is decided by the credential presented, not by what the question says or which conversation it replays. Authorization must not depend on model behavior.

For the platform:

• Treat all business-authored content, including content contributed by negotiated extensions, as data.
• Never let receiving or rendering an answer trigger a capability call or state change.
• Present the answer as content from the business, distinguishable from the platform's own output [3].

These rules target prompt injection, the first entry (LLM01) in OWASP's 2025 Top 10 for LLM applications. OWASP distinguishes direct injection through user input from indirect injection through external content a model processes [11]. In Ask, the buyer's query is a direct path into the business's system, and the business's answer is an external-content path into the platform's system.

The practical consequence: an answer service connected to order data or member pricing is a security system, not a content widget. Test it with hostile questions before any platform does.

---

What Ask Means for GEO

From retrieved pages to authored answers

Most GEO work today is indirect. A business publishes pages, structured data, and feeds, earns third-party coverage, and hopes an AI system retrieves the right passage and represents it accurately. The platform composes the answer.

Ask creates a second path. At the moment of a specific question, a platform could ask the business and receive a first-party answer with links and disclosures. The unit of work shifts from the page or passage to the question-and-answer pair: the answer text, the link set, the message codes, and the fallback behavior.

Google has already shown interest in brand-authored answers. In the same January 2026 announcement that introduced UCP, it launched Business Agent, a branded agent on Search that answers product questions in a brand's voice, and announced new Merchant Center attributes that include answers to common product questions [8]. Google's AI optimization guide, updated in July 2026, adds that protocols like UCP are emerging that will let Search agents do more [9]. None of these sources says Business Agent or Google Search uses Ask.

What Ask does not change

Ask is a channel for the business's answer, not a guarantee that a platform will call it, quote it, or prefer it. The platform decides whether to call Ask, how to present the result, and how to weigh it against other sources, and the draft tells platforms to label it as business content.

There is also no public evidence that adopting UCP capabilities changes ranking. Google's Merchant FAQ for its UCP checkout integration says choosing Native integration does not influence how offers rank in product listings [10]. That statement covers checkout, not Ask, and no platform has suggested Ask works differently.

Finally, Ask raises the cost of inconsistency. Its answers are designed to link to policy pages and resources, and structured capabilities override them on conflict. If an Ask answer says returns are accepted within 30 days, the policy page says 14, and the product feed says something else, the business has published three competing versions of the truth. For its current UCP integration, Google already requires return policies and business contact information in Merchant Center to be complete and up to date [10].

---

What Businesses Should Do Now: A Seven-Step Readiness Workflow

Most businesses should not rush to deploy an endpoint against a draft that no platform has publicly adopted. They should build the assets an answer interface would need. Each step also improves the website, customer support, and the public sources AI systems already use.

Step 1: Inventory the questions buyers actually ask

Pull questions from support tickets, chat transcripts, product reviews, site search, return reasons, and sales calls. Cluster them around the use cases the draft names: fit and sizing, materials, compatibility, comparisons, returns and refunds, shipping, warranty, store hours, and payment methods [3]. For each cluster, note whether a structured system already answers it or whether the answer lives only in free text, or in someone's head.

Step 2: Give every answer an authoritative source

Ask's link model assumes there is a page or resource to send the buyer to. For each answer, record the owning system, the canonical URL, the GID if the item is a UCP resource, the person responsible, and the last review date. If an answer has no source page, create one. A clear compatibility table or size guide helps a future Ask answer and the AI systems reading your site today.

Step 3: Classify data by access tier before connecting it

Decide what an anonymous caller may learn, what possession of a cart or order ID unlocks, and what requires an authenticated buyer. Member pricing, entitlements, order details, and gated availability belong in the authenticated tier. Enforce these rules in code, outside any model prompt [3].

Step 4: Write answer patterns, including the uncomfortable ones

Draft standard answers for the top clusters. Keep them short enough for a conversation and link to the detail. Then write the patterns teams usually forget:

• The honest fallback: what the business says when it doesn't know.
• The non-action reply: "I haven't changed your cart" when a question includes a request to act.
• Non-commitment phrasing: estimates rather than promises for delivery dates and totals, with a pointer to checkout for binding numbers.

Step 5: Move required disclosures into structured warnings

Allergen, safety, and regulated claims should not depend on answer wording. Identify them, make sure the binding disclosure exists on the product or policy page, and plan to deliver them as disclosure warnings that platforms must display [3][4].

Step 6: Red-team the answer service

Test hostile and edge-case questions: requests to ignore instructions, reveal another customer's order, apply an employee discount, cancel an order, or reuse a conversation ID under different credentials. Verify that authorization happens outside the model, that no state changes occur, that a retry with the same idempotency key does not add a turn, and that a mismatched retry is rejected [4][11].

Step 7: Monitor consistency across every surface

Compare four versions of each answer: what your Ask service would say, what your policy and product pages say, what your structured systems return, and what public AI platforms tell buyers today. Fix conflicts at the source rather than patching the answer layer.

---

Where Innflows Fits

Even if platforms adopt Ask, many AI answers about a brand will still be composed from public sources. The readiness work above needs an outside view of those answers.

Innflows monitors AI answers, citations, and brand mentions across major AI platforms and languages. For Ask readiness, a business can turn its Step 1 question inventory into a fixed prompt set and use Innflows to:

• record how AI platforms currently answer return, shipping, warranty, compatibility, and policy questions about the brand;
• compare those public answers with official policies and flag conflicts or outdated claims;
• see which pages and third-party sources the answers cite, so fixes start at the source; and
• track whether answers converge on the official position after content and data changes.

The boundary is clear. This is external monitoring of public AI answers. It does not read platform-internal logs or Ask traffic, it is not a UCP implementation, and it cannot guarantee that any platform will cite the business or use its answers. Its role is to show what buyers hear from AI today and where that diverges from what the business would say.

---

Six Common Misreadings

1. "Ask is already live in AI assistants."

As of October 8, 2026, Ask exists in the draft specification, and we found no public announcement of production use by any AI platform.

2. "Implementing Ask will raise AI visibility or rankings."

There is no evidence for this. Platforms decide whether to call Ask, and Google says its Native checkout integration does not affect how offers rank [10].

3. "Ask replaces the website, product feed, or structured data."

Ask answers link to pages and defer to structured capabilities. Weak sources produce weak answers.

4. "A business answer is a binding commitment."

The draft says answers are indicative. Prices, availability, totals, and policy terms in an answer are not commitments [3].

5. "Ask can add items to a cart, apply a discount, or make a booking."

Ask is read-only. Mixed requests get an answer stating that nothing was done.

6. "A conversation ID works like a login session."

It carries context, not authority. Each turn is authorized on the credential it presents.

---

Frequently Asked Questions

What is UCP Ask?

A draft UCP capability, dev.ucp.common.ask, that lets a platform send a buyer's natural-language question to a business and receive a business-authored answer with optional links, messages, and conversation state. It is exposed through REST as POST /ask and through MCP as ask_business [3][4][5].

Is Ask part of an official UCP release?

Not as of October 8, 2026. It was merged into the main branch on October 7, 2026 and appears in the draft documentation. The latest release, v2026-08-25, does not include it [2][7].

How is Ask different from Catalog?

Catalog returns structured, machine-readable product data. Ask returns human-readable answers to open questions, such as fit or return conditions. When the two conflict, the catalog representation wins, and a business can adopt either one without the other [3].

Can Ask give personalized answers?

Yes, when the platform presents a buyer identity token the business recognizes and the request falls under the dev.ucp.common.ask:read scope. The business must still authorize each protected resource and data item it uses [3].

What happens when the business can't answer?

The business returns a normal successful response whose answer states the limitation plainly. A business-level non-answer is not an empty field, an error code, or a non-2xx status [4].

Should we build an Ask endpoint now?

If you already run a UCP integration and maintain a well-governed knowledge base, a sandbox prototype pinned to a specific commit can surface gaps early. For most businesses, the better investment is the readiness work: question inventory, source mapping, access tiers, answer patterns, disclosures, testing, and monitoring. It pays off on the website and in today's AI answers regardless of when platforms adopt Ask.

How does Ask relate to MCP?

MCP is one of two transports. Ask defines the capability; the MCP binding exposes it as the ask_business tool through JSON-RPC, alongside the REST binding [5].

---

The Bottom Line

Ask is a small capability with a clear direction. An open commerce protocol now defines, in draft, how an AI agent can ask a business a free-form question and receive an answer the business wrote, with source links and disclosures a conforming platform must not hide.

That points GEO toward a new layer of work: running an answer interface, not just publishing pages. The draft also sets the limits. Answers are read-only, indicative, authorized per request, and treated as untrusted data. The platform still decides what to use, and structured data still decides what is binding.

The practical move today is preparation, not deployment: know the questions, own the sources, classify the data, write honest answers, structure the disclosures, test for abuse, and monitor what AI platforms already say.

When AI agents start asking businesses directly, the businesses best placed to benefit will be those whose answers are already accurate, sourced, and consistent everywhere else.

---

References

[1] - feat: ask capability for natural-language Q&A (PR #538) — Universal Commerce Protocol on GitHub, opened June 22, 2026, merged October 7, 2026

[2] - Merge commit a41a2dc for PR #538 — Universal Commerce Protocol on GitHub, October 7, 2026

[3] - Ask Capability (draft) — Universal Commerce Protocol Specification

[4] - Ask – REST Binding (draft) — Universal Commerce Protocol Specification

[5] - Ask – MCP Binding (draft) — Universal Commerce Protocol Specification

[6] - Ask Capability in Shopping (draft) — Universal Commerce Protocol Specification

[7] - Release v2026-08-25 — Universal Commerce Protocol on GitHub, August 25, 2026

[8] - New tech and tools for retailers to succeed in an agentic shopping era — Google, January 11, 2026

[9] - Google's Guide to Optimizing for Generative AI Features on Google Search — Google Search Central, updated July 10, 2026

[10] - Universal Commerce Protocol (UCP) FAQ — Google Merchant Center for Developers

[11] - LLM01:2025 Prompt Injection — OWASP Gen AI Security Project