# I guess we're building knowledge bases now

> Sanity shipped Knowledge Bases in Context this month. What a build actually does, the five objections we get on calls, and where a compiled index won't help you.

**TL;DR:** Sanity Context compiles CMS content, website crawls and files into cited entries for agents. It also gives someone the job of sorting out the contradictions. We explain the build, work through Sanity's returns-policy example, and cover the refresh, access and beta limits we'd check before putting it in front of customers.

**Published:** 2026-09-10 | **Updated:** 2026-09-10 | **Categories:** Sanity, AI, Hot Takes
---

Sanity has shipped [Knowledge Bases](https://www.sanity.io/docs/ai/sanity-context-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](https://www.sanity.io/blog/taking-karpathys-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](https://www.sanity.io/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](https://www.sanity.io/docs/ai/sanity-context-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](https://www.sanity.io/docs/ai/sanity-context-create-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](https://www.sanity.io/docs/ai/sanity-context-resolve-issues) 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](https://www.sanity.io/docs/ai/sanity-context-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](https://www.sanity.io/docs/ai/sanity-context-maintain-knowledge-base) 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](https://www.sanity.io/docs/ai/sanity-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.

> **Where this fits in our agent work**: We build agentic workflows with Sanity, Next.js and Vercel, including the content and review processes those agents depend on. [See our agentic workflows work](/services/agentic-workflows)

## 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](https://www.sanity.io/docs/ai/sanity-context-security) 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.

## Frequently asked questions

### We already have a CMS. Why would we need a knowledge base on top of it?

A Sanity Context knowledge base gives an agent a compiled index over CMS content, website crawls and uploaded files, including sources from multiple Sanity projects. The CMS is one input. The knowledge base has its own purpose, topic outline, cited entries and issues queue, served through MCP. Start with the question you want the agent to answer and check where the evidence lives. If it's already a clean field in your CMS, a live GROQ query may be all you need. There's no prize for adding another system.

### Isn't a Sanity Context knowledge base just a CMS with AI bolted on?

It's a fair suspicion. In this case, look at the work the feature does: it compiles sources into cited entries, flags conflicting claims and saves editorial decisions as instructions for later builds. You're maintaining the material an agent retrieves, with a review process for disagreements. Context Insights can then identify missed questions, provided you configure conversation telemetry and a scheduled classification function. Whether that's useful depends on your workflow. An AI label on the box doesn't settle it.

### Why not just build on Postgres and a vector store?

You can build on Postgres and a vector store. Just include the surrounding work in the estimate: source updates, conflict review, version history, permissions and an interface for the person correcting answers. Sanity provides compiled entries, outline restoration and Issues and Instructions views. Knowledge Base mode scopes access by which knowledge bases an endpoint serves, with token access required for each one. The groqFilter boundary applies only to dataset reads in GROQ mode. Context tool calls are priced like ordinary Sanity API calls, without a per-token retrieval fee; Knowledge Bases remain beta with plan caps. Compare the whole job before choosing.

### Our AI team owns RAG. Why would content people be involved?

The AI team can own retrieval and the model without becoming the authority on every company policy. When sources disagree, someone who knows the subject has to decide which claim is right and correct the original material. Sanity Context raises those conflicts as issues. Give that queue a named content owner who can get decisions from the relevant team. Being able to configure a vector store doesn't make someone qualified to rewrite the returns policy.

### Our content isn't in good enough shape for a knowledge base. Should we fix it first?

You don't need to finish a company-wide cleanup before trying a narrow build. Start with relevant material you're comfortable exposing to the intended audience, inspect the issues and fix the important disagreements before relying on the answers. Sanity's review process exists because sources can contradict each other. A refresh schedule checks for changes, but someone still has to apply the resulting issues. The first build gives you something concrete to investigate; it isn't a certificate that all your content is correct.

### What is a Sanity Context knowledge base?

A Sanity Context knowledge base is a compiled index over sources you choose, owned by a Sanity organization and available to agents through MCP. A build organizes the material into topics and writes Markdown entries with source citations, raising issues for conflicting claims. The initial_context tool supplies the outline; knowledge_base_read retrieves full entries, up to 20 paths per call. Builds can rewrite those entries. Manual editing is available through certain issues, but source corrections and instructions are what you should maintain for future builds.

### What sources can a Sanity knowledge base ingest, and do they stay in sync?

As of September 2026, Sanity knowledge bases accept dataset sources, website crawls and uploaded files. Dataset sources use a complete GROQ query, read published documents only and allow up to 5,000 documents per query. Website crawls respect robots.txt. File limits include 500 MB for PDF, 100 MB for DOCX and PPTX, 50 MB for XLSX, and 25 MB for HTML and images, with a 5 GiB upload cap. Dataset and website sources are checked on a shared weekly, monthly or disabled refresh schedule. Files never re-sync: delete and upload them again. Yes, the PDF still needs a person.

### Is Sanity Context free, and are knowledge bases generally available?

Sanity says Context tool calls are priced like ordinary Sanity API calls, with no per-token retrieval fee. That doesn't make the whole agent free: account for the model and any classification work too. Dataset embeddings are optional, off by default and priced per dataset. Knowledge Bases are an opt-in beta as of September 2026, enabled by an organization admin in Manage. Plans cap knowledge base and source counts, but the docs don't publish the exact numbers. Check those before committing; Enterprise customers can ask their Sanity representative about higher limits.

## Related posts

- [Install our agency into your agent](/blog/install-our-agency-into-your-agent)
- [Building agents with eve: what Vercel's agent framework removes](/blog/building-agents-on-eve)
- [The state of headless CMS](/blog/state-of-cms)