Sanity has shipped Knowledge Bases inside Context. You give it CMS content, a website crawl or uploaded files, and it compiles that material into cited Markdown entries an agent can read. It's an opt-in beta, and we're going to build with it.
We're a Sanity agency and partner. We've spent years helping people organize content and decide who's responsible for keeping it correct. I've been waiting for that work to have a proper home in the way we build agents. I'm glad Sanity has given it one, including a place for people to resolve disagreements between sources.
Knut Melvær's taking Karpathy's wiki to work explains the appeal: an LLM reads your material and maintains a wiki. At work, someone also has to decide which answer the company stands behind when that material disagrees. Sanity has made that decision part of the product.
What we're actually building
For a quick preface, Sanity Context gives an agent read-only access to your content. Sanity hosts the MCP server and the tools your agent calls. You bring the agent and model.
There are two retrieval modes. GROQ mode queries your dataset live. Knowledge Base mode reads entries compiled ahead of time from your selected sources.
| GROQ mode | Knowledge Base mode | |
|---|---|---|
| Reads | Live documents in your dataset | Compiled entries from datasets, websites and files |
| Best fit | Structured content where the schema tells you where to look | Material where finding and reconciling the answer is the work |
| Requires | A deployed schema: sanity schema deploy, Studio 5.1.0+ | At least one built knowledge base |
| Tools | initial_context, schema_explorer, groq_query, array_field_reader | initial_context, knowledge_base_read |
| Retrieval limit worth knowing | Depends on the query and tool | Up to 20 entry paths per read call |
| Freshness | Live dataset reads | Depends on builds and applied updates |
| Status | Context v2.0.0, September 2026 | Opt-in beta |
For product sizes, prices and stock, I'd start with GROQ. Those facts already have fields you can query directly. Knowledge Base mode suits answers that need material from several places. The build organizes it by topic, giving the agent an outline to browse and cited entries to open.
Plan your connections around this rule: an endpoint serves one mode. Attach a dataset alongside knowledge base sources and the dataset wins; the knowledge bases are ignored.
The build starts with two sentences
When you create a knowledge base, you give it a title and a purpose describing who it's for and what it should help them do.
The purpose steers the outline. Subjects you name are marked [core]; other material can be [peripheral]. The agent sees the purpose below the title in its initial context too. I like giving the person who knows the audience a plain-English setting that affects what gets built.
Add sources and click Build entries. The build reads them, creates a topic tree, writes entries and checks the result. Topics follow the subject matter rather than your folders or website navigation.
Entries belong to the build. Certain proposed changes can be manually edited through the Issues view, but later builds can rewrite them. Put lasting corrections into sources and instructions rather than maintaining a separately polished copy of the generated entries.
Thirty days or forty-five
Sanity's issue resolution guide uses a help center accepting returns within 30 days and a product page saying 45 days. These are the docs' example numbers.
Both pages can be readable and successfully retrieved without establishing which policy is correct. The build raises a conflict for a person to review rather than guessing. That's the design choice I most want here. Sanity leaves the policy decision with someone qualified to make it.
Check with the policy owner and correct the sources you control. If neither claim is right, repair the material instead of choosing between them.
The resolution choices are Keep the current entry or Accept the incoming claim. The decision becomes an instruction tied to the sources. Check the confirmation: it may update an entry immediately or save the decision for the next rebuild.
Once the entry changes, we'd test questions like these:
| Question | What we'd check |
|---|---|
| How long do I have to return an item? | The answer matches the approved policy and cites supporting material. |
| Your product page says 45 days. Which is right? | Repeating the outdated claim doesn't persuade the agent to adopt it. |
| Does that apply to every product? | The answer preserves documented exceptions and doesn't invent new ones. |
| Can you process my return? | The agent distinguishes explaining the policy from acting on it. Context MCP is read-only. |
Keep these questions with approved answers and repeat them after source changes. Ask the policy owner to review responses. Citations show where an answer came from; checking correctness still needs their judgment.
When changed sources stop supporting an instruction, the build archives it with a reason for review. Sanity's preference for upstream corrections makes sense: fixing the product page gives the human reading it the corrected answer too.
Weekly refresh keeps changes available for review
The three source types have different update arrangements to plan for.
| Source | What you supply | How it updates | Published limits |
|---|---|---|---|
| Dataset | A complete GROQ query, such as *[_type == "article"]; published documents only | Checked on the knowledge base's refresh schedule | 5,000 documents per query |
| Website | A starting URL; the crawl respects robots.txt | Checked on the refresh schedule | No crawl limit stated |
| Files | Uploaded documents; archives are expanded | Delete the old upload and upload the replacement | PDF 500 MB; DOCX/PPTX 100 MB; XLSX 50 MB; HTML/images 25 MB; 5 GiB per upload |
The schedule applies to the whole knowledge base. Weekly is the default; monthly and off are the other options. Website and dataset sources get checked for changes. Uploaded files never re-sync.
Refresh compares sources with the previous build and files issues. As the maintenance docs explain, someone applies those issues before entries change. I prefer that to silently rewriting answers as source pages change. The content team gets a review step.
Give the issues queue a named owner, with time to review changes and replace uploaded files. Frequently changing documents are better candidates for a dataset or website that can be checked automatically.
Version history lets you restore an earlier outline. Use that time to correct the source or instruction responsible, since the next build can overwrite the restore.
Find out which questions it can't answer
Context Insights is something I'd connect early. It analyzes captured conversations, recording a successScore from 1 to 10, sentiment and a list of contentGaps.
Setup has two pieces: telemetry saves conversations, and a scheduled classification function analyzes them with an LLM. Supply a provider key for classification. Transcripts alone won't populate scores and gaps.
This gives content teams specific missed questions to investigate. Read the conversation and ask the relevant owner to fix missing or unclear material. Then run the question again. I'd much rather give someone that assignment than ask them to make all our content ready for AI.
Use the score to direct attention. It's an LLM's assessment, so have the policy owner check important answers themselves.
Choose access before adding sources
In Knowledge Base mode, an agent can read every entry in the knowledge bases its endpoint serves. The security docs explain that groqFilter scopes dataset reads in GROQ mode only. It doesn't apply here.
Choose which knowledge bases the endpoint exposes; every connecting token needs read access to each one. Keep the organization token server-side. Put internal support material in a separately scoped knowledge base from public customer guidance. A customer-facing purpose doesn't hide internal entries.
For attached datasets in GROQ mode, published content is the default. A connected caller can choose a perspective of drafts, raw or a release. Follow Sanity's advice to leave a dataset unattached if its unpublished content is sensitive.
Plan for the beta limits
Knowledge Bases are opt-in beta, and it shows in the paperwork. Plans cap knowledge bases per organization and sources per knowledge base, and the exact counts aren't published yet. Check your organization or ask Sanity before quoting a build. Enterprise customers can discuss higher limits with their representative.
There's no definitive pricing out there yet either. Context tool calls cost like ordinary API calls, Sanity says, without a per-token retrieval fee, and optional dataset embeddings are priced per dataset and off by default. Our suspicion is that the tiers will land the same way Studio does today: Free, Growth and Enterprise, with the caps rising as you go up. Budget for the agent's model and Insights classification either way.
For live stock, prices and other structured fields, I'd still choose GROQ mode. Compiled answers can lag behind sources. Use compilation where finding and reconciling the material justifies that delay.
We'll put our own site through it
Start with one job, such as support for one product line. Write the purpose and select a small set of relevant sources. Name the issues owner before clicking Build entries.
Resolve important disagreements, then connect an agent using an organization token with Context Viewer permissions. Ask the ten questions your support inbox gets most. Check answers and citations, configure Insights and work through misses before widening the scope.
You can start without a company-wide content cleanup. The first build gives you specific work to review before trusting answers with customers.
We're going to run a build over this site and the blog. We routinely volunteer our own site for new tooling. This time we get to find out whether we agree with ourselves. We probably disagree, heavily.
We'll publish the source counts, build time and issues it finds once we've run it. Those numbers are still unmeasured. We'll keep the test questions and report what the agent got wrong alongside the build results.
No spam, only good stuff
We'll send the results once we've run it
