Sanity Context vs Notion AI for Internal Knowledge Agents

Your internal knowledge agent gets asked "which version of the deployment guide applies to customers on the enterprise tier?" and it confidently answers with steps from the wrong version, because the question carried a structural constraint (a tier, a version number) that a similarity search over wiki pages simply cannot honor. The query is close enough in embedding space to a dozen pages, so the model picks one and hedges, or worse, hallucinates. For an internal agent your support, engineering, and compliance teams rely on, a wrong answer is not a UX blemish; it is a mistake that ships into someone's decision.

Sanity Context (previously Agent Context) is the AI Content Operating System's answer to this: an intelligent backend that gives agents structured, governed access to your content instead of a bag of embeddings. Where Notion AI answers questions over pages you happen to have written in Notion, Sanity Context treats retrieval as a discipline, hybrid by default, with the same filters, freshness, and governance you already trust for your website.

This guide is a head-to-head. Notion AI is the established, low-setup way to ask questions of your internal wiki. Sanity Context is the modern approach for teams whose agents have outgrown "we have embeddings." We compare them on retrieval, developer experience, governance, and lock-in, then give you a decision framework.

The established-vs-modern tension

Notion AI earns its place honestly. If your internal knowledge already lives in Notion pages, docs, and wikis, turning on an AI answer layer is close to free: the content is there, the editor is familiar, and non-technical teams can ask questions the same day. For a lot of internal Q&A, that is genuinely enough. The trouble starts when the agent is expected to do more than surface a paragraph that sounds relevant.

Notion AI's retrieval is embedding-first over page content. It ranks pages by semantic similarity to the question, which is excellent for fuzzy, exploratory asks ("what's our stance on remote work?") and unreliable for anything carrying a hard constraint. As Sanity's own production analysis puts it, most retrieval failures share the same shape: the query carries a real structural component, a version number, a category, a status like "in stock", that pure vector similarity cannot resolve. The nearest pages come back, the constraint is quietly ignored, and the model hallucinates or hedges depending on the prompt.

Sanity Context starts from the opposite premise. It is the intelligent backend for companies building AI content operations at scale, so retrieval is not an add-on over documents; it is a query over a governed content model. Structured predicates enforce the filters that have to hold, and semantic and keyword ranking sort what is left. The tension between the two products is really a tension between "answer over the pages we have" and "answer over a model of the business." For a throwaway internal FAQ, the first wins on speed. For an agent people will act on, the second is the one that holds up.

Retrieval: semantic-first pages vs native hybrid over a content model

This is the axis that decides most internal-agent projects, so it is worth being concrete. Good retrieval is not one technique, it is three working together: keyword search (BM25) for literal matches, embeddings for semantic ranking, and structured predicates for the filters that must hold. Anthropic's contextual retrieval research measured the stacking directly: contextual embeddings cut top-20 retrieval failures by 35%, adding contextual BM25 took that to 49%, and adding reranking on top brought it to 67%. None of the three layers alone was enough. That is the case for hybrid, in one number.

Notion AI leans on the embeddings layer. It is strong at ranking pages by meaning, which is why it feels magical on open-ended questions, and it has no governed content model underneath to run hard filters against. Sanity Context runs all three in a single GROQ query inside the Content Lake. Predicates do the filtering that has to hold, then a score pipeline blends the layers: `score(boost([title] match text::query($queryText), 2), text::semanticSimilarity($queryText))` followed by `order(_score desc)`. The title keyword match is weighted 2x because a title hit matters more; the semantic score ranks the rest.

The counter-intuitive part comes from Sanity's own production data on Context MCP: structured retrieval dominates. When you look at how agents actually call the endpoint, the heavy majority of calls are GROQ queries and schema lookups. Semantic search is a small slice, and embeddings are opt-in, off by default, and most projects never turn them on. As the team writes flatly, "'We have embeddings' is not a retrieval strategy." An internal agent that answers version-and-tier questions well needs structured retrieval first, and semantic ranking as one ingredient, not the whole meal.

Teaching retrieval the shape of your data

There is a failure mode most teams do not budget for: retrieval that is technically working and still wrong, because the agent does not understand the shape of the data it is searching. Field names are counter-intuitive. References chain two hops deep. There are data-quality issues that a schema alone will not reveal. A pure similarity search over pages has no way to learn any of this; it just matches text.

Sanity Context ran a schema-exploration test against Sonos's catalog and landed around 83% accuracy on a mix of difficulty levels (using Sonnet 4.5 for reasoning). The point of that number is not the headline; it is where the accuracy came from. It came from teaching retrieval the structure: the counter-intuitive field names, the second-order reference chains, and the real-world data-quality issues. As the team put it, none of that is a model problem, it is a context problem. The model needed to know the shape of the data, not just its types.

This is where an internal wiki tool and a content backend genuinely diverge. Notion AI operates over a page-and-block model that is the same shape for every workspace, which is what makes it easy to adopt and also what caps how precisely it can answer domain-specific questions. Sanity Context queries your schema, so an agent can reason about your entities, your relationships, and your governed fields. For an internal agent that fields questions about products, policies, tiers, or support cases with real structure, that difference is the gap between an answer that sounds right and one that is right.

Governance and developer experience: the system prompt as content

The retrieval story gets the attention, but for internal agents the governance of behavior is what keeps compliance and brand awake at night. An agent's system prompt is customer-facing behavior, or in the internal case, employee-facing behavior, and it should be governed like content rather than buried in code. In most stacks it is a string in a repository, which means every voice tweak or never-say-list update is a pull request, a review, and a deploy.

Sanity Context models the prompt as a document in the Studio with fields: role, voice, userContext, escalation, and a mustNotSay list. Splitting the prompt into fields is not cosmetic, it is access control. Brand owns voice, Product owns how the agent uses user context, Support owns escalation, and Compliance owns the never-say list, and none of them files a pull request or waits for a deploy. Because it is content in the Studio, you get real-time collaboration, version history, scheduled publishing, and rollback for free. You stage agent behavior with Content Releases the same way you stage your website, drafts, scheduling, history, permission gating, and audit trails included, ideally gated by an eval bench in CI.

Two customer signals make this concrete. Nearform reported that "storing the system prompt in a Sanity document is genuinely useful. Editors tuned the agent's voice without any code changes." Vipps came to Sanity wanting the whole organization to contribute to prompt writing, with product managers owning it, not just engineers. Notion AI's answer behavior, by contrast, is configured in-product rather than versioned, role-owned content with an eval gate. For an internal agent, that difference decides whether prompt changes are auditable and reviewable, or invisible.

Ops, freshness, and enterprise needs

An internal knowledge agent is only as trustworthy as its freshest answer. When someone updates a policy, changes a tier, publishes a new runbook, or deletes a deprecated page, the agent needs to reflect that within minutes, not on the next re-index. This is where the operational models diverge sharply, and where the DIY vector-DB path (Pinecone, pgvector, Weaviate) quietly becomes a permanent cost.

With Sanity Context, dataset embeddings and search are wired into the content backend, so index freshness is handled for you. A description update, a price change, a publish, or a delete propagates. When retrieval is a separate vector DB plus glue code, freshness becomes a permanent line item on your roadmap: incremental indexing, re-embedding on change, deletion handling, and backfill are yours to build and maintain forever. Notion AI keeps its index inside Notion, which spares you that plumbing but ties freshness and scope to what lives in Notion pages.

On the compliance axis that enterprise buyers actually gate on, Sanity brings SOC 2 Type II, GDPR, regional hosting and data residency options, and a published sub-processor list. That matters for an internal agent touching HR policy, support cases, or logged-in-user data. It is also worth naming a real limitation of the agent-platform tier (Kapa.ai, Decagon, Sierra AI): retrieval and prompt governance live inside the vendor, not in your content backend, and teams have reported struggling to feed structured, logged-in-user data (tier, quota, entitlements) into those agents. Sanity Context keeps that data in the model the agent queries, and exposes it through a hosted, read-only Sanity Context MCP endpoint any agent loop can connect to.

Cost, lock-in, and a decision framework

The honest cost question for internal agents is not the sticker price, it is who owns the moving parts over three years. Notion AI's cost is low and its lock-in is soft in the sense that your content is still Notion pages, but it is hard in the sense that your agent's quality is capped by Notion's retrieval model and its page-shaped data. The agent-platform tier trades build effort for vendor control: you often cannot own the model choice or cost, and structured, logged-in-user data is awkward to get in. The DIY vector stack gives you maximum control and hands you the freshness pipeline as a standing obligation.

Sanity Context's position is that retrieval, governance, and the content model live in one backend you already operate, so you are not assembling hybrid search from a separate stack or handing behavior governance to a vendor. Context has an MCP, a knowledge base, and an ingest path; Knowledge Bases turn datasets, websites, PDFs, and support databases into agent-readable documents that share the Sanity Context retrieval path. It is not only an MCP.

A simple framework. Choose Notion AI when your knowledge genuinely lives in Notion, the questions are open-ended and low-stakes, and you want answers today with no engineering. Choose an agent platform when you want a vendor to own retrieval end to end and can live inside their model and data constraints. Choose a DIY vector stack when you need bespoke control and have the team to own freshness forever. Choose Sanity Context when your agent must answer questions that carry real structure, when freshness and governance are not optional, and when prompt behavior needs to be versioned, role-owned, and auditable. For most internal agents that people will act on, that last row is the one that describes the requirement.