DevDocs — A Developer Agent Grounded in Real Documentation

DevDocs — A Developer Agent Grounded in Real Documentation

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

I built DevDocs, a small AI-powered developer assistant that answers web-development questions using a knowledge base of real documentation stored in Sanity and accessed through Sanity Context MCP.

The idea is simple:

Instead of asking an LLM a development question and hoping it remembers the right information, give it access to a structured knowledge base containing the documentation it should reason over.

The current knowledge base contains documentation covering:

• React
• Next.js

The agent can use this content when answering questions about things like rendering, data fetching, browser APIs, state, effects, Server Components, Client Components, cookies, and other react/nextjs concepts.

The goal isn't to build another generic chatbot.

It's to make a small developer tool that can answer questions from a known body of documentation and show where its answer came from.

For example, instead of asking:

"What is a React effect?"

you can ask something more practical:

"I'm building a Next.js application. Should I fetch this data on the client or on the server?"

That question requires connecting multiple concepts rather than simply finding one paragraph containing the right keyword.

The agent can use the available documentation as context, reason over it, and return an answer with its sources.

The architecture

The core flow is:

User question
      ↓
   Groq Agent
      ↓
Sanity Context MCP
      ↓
Sanity Knowledge Base
      ↓
Relevant documentation
      ↓
Agent reasoning
      ↓
Answer + Sources

Sanity isn't just being used as a place to store blog posts.

The content is structured so that the agent can retrieve relevant pieces of knowledge through Context MCP.

Demo

Live demo:
DevDocs Agent

Note: This agent uses Groq's free tier, so responses may occasionally be slow or fail due to rate limits. If that happens, please try again after a short while.

The interface is intentionally minimal.

You get a question box, ask a development question, and the agent streams back a Markdown-formatted answer along with the documentation sources it used.

There is no login, no dashboard, and no unnecessary product machinery.

The goal is to get from:

Question

to:

Grounded answer + sources

as quickly as possible.

For the demo, some useful questions are:

"Can I update state directly in React?

"When should I use useEffect in React?"

"What causes a React component to re-render?"

"Can useEffect be used to fetch data?"

These questions also demonstrate why having multiple related documentation sources is more useful than treating the knowledge base as a simple FAQ.

Code

The project source code is available here:

DevDocs GitHub Repository

The application is built around a relatively small stack:

• Frontend: Next.js
• Styling: Tailwind CSS
• Agent: Groq (openai/gpt-oss-120b)
• Knowledge: Sanity
• Retrieval: Sanity Context MCP

I deliberately kept the architecture small.

There is no vector database, no custom RAG infrastructure, and no multi-agent system.

The point of this project was to see how far I could get by combining an agent with Sanity's structured content and Context MCP.

My Build Process

The interesting part of this project wasn't actually writing the chat interface.

It was figuring out how the agent should interact with the knowledge base.

I started with a simple question:

What if I gave a developer agent access to actual documentation instead of relying entirely on its pretrained knowledge?

From there, I broke the project into a few small pieces.

1. Build the knowledge base

First I created the Sanity project and started adding documentation.

I didn't want to dump a giant collection of unstructured text into Sanity.

Instead, the content was modeled around individual documentation concepts.

The initial scope was intentionally small:

React
Next.js

This gave the agent enough related knowledge to answer realistic frontend questions without turning the project into a massive documentation mirror.

2. Understand Sanity Context

The next step was understanding what Sanity Context actually gives an agent.

The important part for me was that the agent doesn't need to know how the Sanity dataset is internally organized.

Context MCP exposes the knowledge through tools that the agent can use.

The basic relationship became:

Agent
  ↓
MCP
  ↓
Sanity Context
  ↓
Structured content

Once I got a successful query through the MCP endpoint, the rest of the project became much more straightforward.

3. Connect the agent

I then connected the Groq agent to the Sanity Context MCP endpoint.

The first milestone wasn't a beautiful UI.

It was simply getting this to work:

User asks question
        ↓
Agent receives question
        ↓
Agent calls MCP
        ↓
MCP retrieves documentation
        ↓
Agent uses documentation
        ↓
Answer

Once that worked end-to-end, I knew the core idea was viable.

4. Make the answers source-aware

I didn't want answers that looked grounded without actually showing what information they were based on.

So the response format was designed to include sources.

The agent produces its answer as Markdown, while the application extracts the source information and renders it separately.

That gives the user two things:

The answer

and

the documentation behind the answer.

This also makes the distinction between the model's reasoning and the underlying source material much clearer.

5. Keep the agent constrained

I also deliberately avoided turning this into a giant "AI developer" agent.

The agent has a specific job:

Answer web-development questions using the available documentation.

That constraint matters.

Without it, it's very easy to build a generic chatbot with a Sanity logo attached to it.

I wanted Sanity to actually be part of the answer pipeline.

What Didn't Work

The first temptation was to build too much.

I considered things like:

• authentication
• user accounts
• conversation history
• a database
• vector search
• multiple agents
• a large documentation library
• complex RAG pipelines

But none of those were necessary to demonstrate the idea.

So I cut them.

The challenge had a short deadline, and I wanted to spend the time understanding Sanity Context + MCP + agents, rather than spending most of the time building infrastructure around them.

Another important lesson was that simply giving an agent access to documentation doesn't automatically make every answer good.

The agent still needs a clear task and a useful knowledge base.

The quality of the final answer depends on all three pieces:

Good question
      +
Relevant structured knowledge
      +
Good agent instructions
      =
Useful answer

That's something I found much more interesting than simply throwing more documents at the model.

Sanity Project Details

The Sanity project powering DevDocs is publicly accessible so the structure and content can be inspected.

Project ID:

o0x6dlzz4

The project contains the documentation used by the agent, including the React and Next.js that powers the demo.

The important part here is that the Sanity dataset is not just decorative content for the website.

It is the actual knowledge source the agent queries through Context MCP.

The MCP layer sits between the agent and the Sanity content:

Groq 
   ↓
Context MCP
   ↓
Sanity
   ↓
Documentation

That separation is what makes the architecture interesting to me.

The agent doesn't need to know the implementation details of the CMS.

It can work with the knowledge exposed through the MCP interface.

Agent Session

I built the project using an AI-assisted development workflow and iterated on the implementation as I went.

The most useful part of the process was not asking the model to generate the entire project in one shot.

Instead, I broke the work into smaller milestones:

Sanity setup
      ↓
Knowledge modeling
      ↓
Context MCP
      ↓
Agent connection
      ↓
First successful query
      ↓
Source handling
      ↓
UI
      ↓
Deployment

That made debugging much easier.

Whenever something broke, I could isolate whether the problem was in:

• the Sanity content
• the MCP connection
• the agent
• the response format
• or the frontend.

That approach also helped me understand what was actually happening instead of blindly accepting whatever code the model generated.

What I Learned

The biggest thing I took away from this challenge is that an AI agent becomes much more useful when you give it a well-defined source of truth.

LLMs already know a huge amount about React, Next.js, JavaScript, and web development.

So the interesting question isn't:

"Can an LLM answer a React question?"

Obviously, it can.

The more interesting question is:

"Can I give an agent a specific, structured knowledge source and make it reliably use that source when answering?"

That's what I wanted to explore with DevDocs.

Sanity provided the structured content layer, and Context MCP provided the bridge between that content and the agent.

The final application is intentionally small.

No giant RAG architecture.

No collection of agents talking to each other.

No huge product surface.

Just:

Real documentation
       ↓
Sanity
       ↓
Context MCP
       ↓
AI Agent
       ↓
Developer answer
       ↓
Sources

And honestly, that was enough to make the project useful.

This challenge also changed how I think about CMSs.

I initially thought of Sanity mainly as a place where a website could retrieve content.

After working with Context MCP, I started thinking about structured content differently:

the content doesn't necessarily have to be consumed by a webpage.

It can become a knowledge source that an agent can reason over.

That's the part of this project I'd like to explore further.

For now, DevDocs is my small experiment in that direction.