Your agent needs better content. Here's how to give it.

Written by Even Westvang, Knut Melvær

You've built an agent. It works in the demo. It answers product questions, surfaces relevant docs, helps customers find what they need. Confetti! You launch it to your site.

Then someone asks about the price of the blue running shoe in size 10, and it confidently returns the wrong number. Or it comes up with a product that doesn't exist. Or it suggests something that's been discontinued for three months. You add prompts like “DO NOT HALLUCINATE”. But it kinda doesn’t get better.

Everyone blames the model or gets bogged down in prompt engineering. But the model isn't the problem. There is only so much you can do with prompts.

The content backend is usually where it falls apart.

When “close enough” isn't close enough

RAG (retrieval-augmented generation) is the right idea: instead of relying on training knowledge, you retrieve real data and feed it to the model alongside the user's question. The question is what that retrieval looks like.

The first version most teams build: vectorize your content into text chunks, store the embeddings, and when the agent needs information, find the most semantically similar chunks and stuff them into the prompt. It's a reasonable starting point. For a lot of use cases, it gets you surprisingly far.

But the last year changed what agents can do. They went from "consume this context window" to "use these tools to go get what you need." That changes what good retrieval looks like.

This is where content as embeddings only takes you so far, and can turn out directly unhelpful for the folks you are trying to help.

Precision questions have fuzzy answers. A customer asks "what's the price of the blue trail runner in size 10?" Your embedding index returns the five most semantically similar chunks about trail running shoes. Maybe one of them contains the price. Maybe it contains last month's price. Maybe it contains the price for a different color-way. The model picks whichever chunk looks most relevant and answers with confidence. Sometimes it's right. Sometimes it's confidently wrong, which is worse than saying "I don't know."

Structure gets flattened. Your content has types, relationships, and attributes. Products have variants. Variants have prices, sizes, and inventory status. Brands relate to products. Products relate to reviews. When you vectorize all of that into text chunks, you flatten it. The embedding for a product page captures the vibe of that page, not the fact that variants[color == "blue" && size == "10"].price is $129. An agent that needs to filter, compare, or traverse relationships is out of luck.

Staleness is invisible. Someone on your team updates a price or discontinues a product. If your embedding pipeline runs on a schedule (and most do: hourly, daily, sometimes weekly), the agent keeps serving old data in the gap. Unlike a broken API that returns an error, a stale embedding returns a confident answer. There's no signal that anything is wrong. Money out the window.

There's no write path. Pure RAG is read-only. The agent can retrieve text, but it can't act on your content model. It can't filter a product listing, apply a discount code, or update a shopping cart. For agents that need to do things, not just answer questions, text retrieval is only half the picture.

None of these are exotic edge cases. They're the normal failure modes of agents in production. The teams we've been working with all hit them, usually within the first few weeks of real user traffic.

What Agent Context does differently

PortableText [components.type] is missing "sanityVideo"

Agent Context is still RAG. The retrieval just got a lot smarter and nimbler.

Today, we're shipping a "just add water" remote MCP endpoint that gives AI agents structured access to your Sanity Content Lake (that's our hosted content backend, if you're new here). MCP (Model Context Protocol) is an emerging standard for connecting AI agents to external tools and data sources. Think of it as a way for your agent to call functions on a remote server, similar to how a browser calls APIs.

The Agent Context MCP endpoint gives your agent two capabilities instead of just one: Semantic search and structured content retrieval. Built on top of out-of-the-box features in Content Lake.

Semantic search via embeddings

Agents can use semantic search for discovery. "Find products similar to trail running shoes" works even if your content never uses that exact phrase. This is the part that RAG gets right, and we kept it.

A customer asks your agent: "Do you have lightweight trail running shoes under $150?" With text-chunk retrieval, you'd search for similar text and hope a relevant chunk surfaces. With Agent Context, the agent writes a GROQ query that combines structure with meaning:

Internal server error