This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.
What I Built
OpenCoach is a question-answering agent for the architecture and business rules of an order-processing system. It helps a developer answer questions such as “How does the dead-letter queue work?” with evidence from structured, source-linked knowledge rather than a plausible but unverified summary.
The problem is especially visible when documentation ages: an earlier diagnostic said retry and a DLQ still needed to be implemented, while the current Go code declares dead-letter exchanges and queues and rejects failed messages without requeueing. I modeled both claims, their status, and their sources in Sanity so the agent can distinguish historical advice from current behavior. That is more useful than treating all matching text as equally current.
The pre-existing Go orders/payments application is the foundation, not the contest entry itself. I began that repository before this challenge. During the challenge I added the Sanity Studio schemas and seed content, connected OpenCoach to a Sanity Context Knowledge Base over MCP, and added the grounded-answer interface. The existing local RAG mode remains available as a separate mode.
Demo
Try the live OpenCoach demo: open OpenCoach, enter “Como funciona a DLQ?” (“How does the DLQ work?”), then click Buscar evidências. The response shows the Sanity Context mode and the Knowledge Base evidence it used. This exact question was tested against the deployed app.
No login is required for the demo. The backend runs on a free hosting tier and may need time to wake after inactivity. If an upstream model request briefly returns 503, wait and try again.
Code
The open-source repository contains the Go application and the contest additions. The Sanity integration pull request makes the new work and its history easy to inspect. The main integration points are sanity/schemaTypes/, sanity/seed/, open_coach.py, rag_api.py, and frontend/src/App.tsx.
How I Used Sanity
I created a Sanity Studio for technical knowledge, not customer or order records. Five document types model business rules, architecture decisions, domain events, API endpoints, and documentation claims. The content records code-file evidence and distinguishes current claims from outdated ones. A historical DLQ claim explicitly references the current claim it conflicts with.
I seeded the Studio from facts checked against the repository code and used those documents to build a Sanity Context Knowledge Base. At question time, the OpenCoach backend calls the Context MCP initial_context tool for the Knowledge Base outline. A Gemini routing step selects relevant entry paths; the backend reads those entries with knowledge_base_read; and a second step generates the answer from the retrieved entries. The UI exposes the answer and the evidence so a reader can inspect the basis for it.
This structure is central to the use case: the agent needs to know whether a claim is current or historical, what code supports it, and which claims conflict. A plain keyword match on “DLQ” would retrieve both old and new statements without resolving their status.
One limitation remains transparent: in a generated DLQ Knowledge Base entry, two citation markers about metrics and monitoring point to the current-DLQ claim rather than the architecture-decision source that actually documents those details. The source-card mismatch is recorded in sanity/README.md. The presence and basic behavior of the DLQ were checked against code, but these two citation markers still need human review; “entries up to date” does not mean every generated citation is correct.
Sanity Project Details
- Sanity project ID:
ss56mini - Dataset:
production - Knowledge Base ID:
kbbKnMXYLs6b - Studio schemas and seed content:
sanity/
The MCP access token stays on the backend and is not published with the demo or repository.
Top comments (0)