Building AI Agents With the Vercel AI SDK and Sanity Context

Building an AI agent is the easy part. Grounding it in content that's actually correct, and stays correct, is where most projects stall. The Vercel AI SDK gives you a clean, model-agnostic way to define tools, stream responses, and orchestrate multi-step reasoning in TypeScript. What it doesn't give you is a source of truth. This guide walks through wiring the Vercel AI SDK to Sanity Context (previously Agent Context) so your agent retrieves answers from governed, structured content over an MCP endpoint, instead of hallucinating against a stale vector index nobody owns.

Sanity Context is Sanity's agent-facing product, and its Context MCP endpoint is what makes the retrieval side of this guide concrete: schema reads, GROQ queries, and reference traversal over a read-only interface your agent tools can call directly.

The retrieval gap the AI SDK leaves open

The Vercel AI SDK is deliberately unopinionated about where your agent's knowledge comes from. You get streamText, generateText, and a tool-calling interface that works across OpenAI, Anthropic, Google, and the rest, but the moment your agent needs to answer a question about your product, your docs, or your support history, you're on your own. The default pattern teams reach for is a bolted-on vector store: chunk the docs, embed them, push the vectors to a standalone index, and write a retrieval tool that does nearest-neighbour lookup. It demos well. Then the content changes. Now you own a second pipeline whose only job is to stay in sync with the first, and every gap between them is a hallucination waiting to happen. The agent doesn't know the index is stale; it answers confidently from whatever it retrieved. For an engineering team, the AI SDK solved orchestration and quietly handed you a data-freshness problem instead.

Defining a retrieval tool over the Sanity Context MCP endpoint

The cleaner path is to give the agent a tool that queries content directly rather than a snapshot of it. Sanity Context exposes an MCP endpoint, the surface production agents actually connect to in order to query governed content. With the Vercel AI SDK, you register that as a tool the model can call: the SDK handles the tool-call loop, and the tool body issues a query against the Content Lake, Sanity's queryable content store and the backbone of the Sanity Context retrieval path. Because retrieval runs against live content rather than a copied embedding index, the answer the agent returns reflects what editors published, not what some nightly job last managed to sync. In an AI SDK multi-step run, the model can call the retrieval tool, read the structured result, and decide whether it has enough to answer or needs a follow-up query, the same agentic loop you'd build by hand, but pointed at a source that doesn't drift away from production.

Hybrid retrieval that lives inside the content backend

Semantic search alone misreads exact terms, SKU numbers, version strings, error codes, because vectors are about similarity, not literal matches. Keyword search alone misses paraphrase. The robust answer is hybrid retrieval, and the differentiator here is that Sanity Context does it natively in GROQ rather than asking you to assemble it across two systems. In a single query you blend `text::semanticSimilarity()` for meaning with a BM25 `match()` for exact terms, combining them with `score()` and `boost()` to rank results. The embeddings are dataset embeddings tied to the content itself, so when an editor updates a doc the embeddings propagate within minutes, there's no separate vector pipeline to babysit. From the Vercel AI SDK's perspective this is still just one tool returning ranked, structured results. But underneath, the relevance work that usually sprawls across a content store plus a vector DB plus glue code collapses into one query against one source.

Governing what the agent is allowed to say

An agent is only as trustworthy as the instructions and content behind it, and most stacks leave both ungoverned, system prompts live in code, knowledge lives in an index nobody reviews. Sanity Context moves that governance into the place editors already work. Agent instructions and the content the agent draws on are managed in Studio, and Content Releases let teams stage agent behaviour the same way they stage a website launch: review a change, see what the agent would now answer, ship it deliberately. Knowledge Bases (launching September 2026) extend the same retrieval path to datasets, websites, PDFs, and support databases, turning unstructured sources into agent-readable documents without standing up a parallel ingestion stack. For the Vercel AI SDK developer, this means the prompt and the knowledge your tool returns are both versioned, reviewable artifacts, not hardcoded strings and an opaque vector blob that drift apart over time.

Putting it together: a content-grounded agent

The full loop is straightforward once the pieces are named. Your Vercel AI SDK agent runs streamText with a tools map; one of those tools connects to the Sanity Context MCP endpoint and issues a hybrid GROQ query against the Content Lake. The model calls the tool when a user question needs grounding, reads the structured, ranked result, and composes an answer it can attribute to real published content. Because retrieval hits live data and the embeddings stay tied to that content, there's no sync job to fail silently between deploys. Editors govern the instructions and source material in Studio, staging changes through Content Releases, so the people who own the content also own what the agent says about it. The AI SDK keeps doing what it's good at, model abstraction, tool orchestration, streaming, while the hard part, trustworthy retrieval, is handled by the system that already holds your content rather than a copy of it.