One Fall '26 release note reads very plainly: "Business details in AI channels — review and approve the facts that get shared with agents, including policies and FAQs."
Behind that sentence is something merchants have not had before: a desk in the admin where you decide, line by line, what an AI tells people about your business.
Key takeaways
- The knowledge base moved into the Shopify admin on 26 October 2026, under Sales channels → Agentic. The standalone app is scheduled for shutdown on 15 January 2027.
- Shopify drafts facts by scanning your storefront and policy pages. You approve them. Unpublished drafts reach no agent.
- Official position: "Shopify never changes knowledge base content on your behalf." The ceiling is 1,000 facts across ten categories.
- The matching protocol capability,
ask_business, is still a UCP draft — we did not find it among the 15 tools a live store returned. - It already works anyway, through WebMCP's
search_shop_policies_and_faqs. Build it now.
How the workflow runs
Shopify scans your storefront and policy pages and generates unpublished fact drafts. You review each one and publish it. Three properties matter:
- Drafts are inert. An unpublished fact reaches no agent, anywhere. There is no partial exposure.
- The platform does not edit on your behalf. What you approve is what is served.
- There is a ceiling. One thousand facts, across ten categories. Stores above the limit in the old standalone app have to migrate manually before 15 January 2027.
Ten categories sounds like a small surface until you try to fill it honestly. Returns, shipping, warranty, contact, sizing, materials, service areas, payment methods, business details, store locations — most brands discover their policy pages answer about two thirds of what a buyer actually asks.
Where the facts actually surface
This is where teams get confused, so it is worth separating.
The protocol path, ask_business, is not live for most stores yet. It is the single tool of the Ask capability, on the same {yourdomain}/api/ucp/mcp endpoint, and it answers policy and service questions: returns, shipping, warranty, service coverage.
Its constraints, once available, are tight: single-turn only with no conversation; the response is answer.plain text, so do not depend on Markdown, source links or a session id; the query caps at 10,000 characters and serialised buyer context at 8,192 bytes. It answers questions and does nothing else — no cart changes, no orders, no returns initiation.
We ran tools/list against a live store and ask_business was not among the 15 tools returned. The documentation explains why: Ask exists only in the UCP draft profile, and the store had negotiated a dated version — 2026-08-25 in our sample. An agent wanting Ask has to use the draft profile and declare dev.ucp.common.ask.
The browser path already works. Among the WebMCP tools registered on storefronts is search_shop_policies_and_faqs, and it reads the same knowledge base. A buyer browsing your store with an in-browser agent can already get answers from facts you publish today.
So the honest answer to "can my store answer agent policy questions" is: not through the protocol yet, but yes through the page — and the asset you build serves both. See WebMCP storefront tools for the full tool list.
Why this is worth doing before the protocol settles
Three reasons, in descending order of how often they get ignored.
It fills a gap the agent openly admits. The official Shop skill instructs agents that shipping eligibility does not establish arrival by a deadline, and that when a buyer names a date the agent should say search cannot confirm it and point to checkout. That is an explicit blank. Published delivery facts are how you put something in it — and in peak season that blank sits exactly where urgency lives.
It is the one place you write the words. Nearly everything else an agent says about you is derived: product features are inferred from your copy, descriptions may be rewritten, the instruction file is platform-generated. Knowledge base facts are approved verbatim. It is the only first-person channel you have.
It does not expire. Protocol versions move; the facts do not. Work done now serves search_shop_policies_and_faqs today and ask_business when dated releases include it.
A two-week plan
Days | Action | Owner |
|---|---|---|
1–2 | Audit the generated drafts. Expect a third to be wrong or stale | Support |
3–5 | Fix the three that drive contacts: returns window and cost, delivery timing by market, warranty terms | Support and legal |
6–8 | Add the facts your policy pages never covered: sizing guidance, material care, service coverage, what is in the box | Merchandising |
9–10 | Legal review, then publish. Nothing counts until published | Legal |
11–14 | Test it: browse your own store with an in-browser agent and ask the five questions you get most | Growth |
That final step is the one worth protecting. Reading your own facts back through an agent is the only way to find out they are ambiguous.
FAQ
What happens if I do nothing? Agents fall back on what they can read from your public pages, which is usually less precise and occasionally wrong. You lose the ability to be the authoritative source about your own policies.
Is 1,000 facts enough? For most brands, comfortably. If you are near the limit it is usually a sign facts are being written at the wrong granularity — one fact per policy decision, not one per sentence.
Does this replace a help centre? No. The help centre serves humans and still earns citations in the model layer. The knowledge base serves agents directly. They overlap in content and differ completely in delivery.