Incident Context: tracing production failures without guessing A developer built Incident Context, an incident-investigation agent that models operational records — services, deployments, changes, runbooks, and incidents — as connected Sanity documents and traces explicit relationships between them rather than relying on keyword matches. The agent follows a Sanity Context MCP Knowledge Base to separate confirmed evidence from inference and preserves source paths behind every report, refusing to generate an unsupported fallback answer if Sanity Context is unreachable. In a demo comparing two consecutive-day outages, it traced distinct root causes — a DB_POOL_SIZE reduction for INC-142 and a PAYMENT_TIMEOUT_MS reduction for INC-208 — instead of correlating on shared timeout mentions. This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content https://dev.to/challenges/sanity-2026-09-16 . Incident Context is an incident-investigation agent for questions that cannot afford a confident but unsupported answer. During an outage, evidence is rarely contained in one document. It is spread across services and dependencies, deployments and released versions, configuration changes, previous incidents, and version-specific runbooks. Incident Context models those records as connected Sanity documents. The agent follows their relationships through a Sanity Context MCP Knowledge Base, separates confirmed evidence from inference, and preserves the source paths behind every report. A keyword search can find "timeout" in both INC-142 and INC-208. But correlation is not causation. Both incidents were production outages on consecutive days. Both involved configuration changes. Both mentioned timeouts. That is not enough to determine whether they share a root cause or require the same remediation. The useful answer is not a matching paragraph. It is a supported path across an incident, an affected service, a deployment, a configuration change, and an applicable runbook. The agent models operational records as a connected graph: Service → depends on → Service Deployment → belongs to → Service Deployment → includes → Change Change → modifies → Service Runbook → applies to → Service Incident → affects → Service Incident → relates to → Deployment Incident → relates to → Change Incident → references → Runbook When you ask it to compare the two incidents, the agent follows the structured path, not keyword matches: INC-208 → affected checkout-api → related deployment checkout-api v2.3.0 → included PAYMENT TIMEOUT MS configuration change → reduced from 5000ms to 1500ms This traversal becomes an evidence trail in the interface: Notice the evidence trail at the top. It shows the relationships the agent followed: INC-142 affected payment-api and was caused by a DB POOL SIZE reduction; INC-208 affected checkout-api and was caused by a PAYMENT TIMEOUT MS reduction. Two different paths. Two different root causes. Below that: 4 confirmed evidence items, 0 inferences, 2 sources. The model did not guess or correlate. It followed the graph. Operational data contains many correlations: Those relationships are useful evidence. They are not automatically proof of causation. The agent preserves the distinction. Every investigation returns: If Sanity Context cannot be reached, the application does not generate an unsupported fallback answer. Sanity is not being used as a generic document store behind a chat box. Its references form the investigation graph. The project defines five document types: service , deployment , change , runbook , incident . Their references encode the operational relationships. During the build, I included the references required for an investigation: service.dependencies → service deployment.service → service deployment.changes → change change.service → service runbook.service → service incident.affectedServices → service incident.relatedDeployments → deployment incident.relatedChanges → change incident.relatedRunbook → runbook Sanity Context distilled those connected documents into navigable, source-linked entries. At investigation time, the agent reads the Knowledge Base outline through initial context , selects relevant entries, retrieves them through Knowledge Base tools, and traces explicit relationships. The system prompt explicitly forbids turning correlation into confirmed causation. Live application: https://incident-context.vercel.app/ https://incident-context.vercel.app/ No login is required. The dataset represents a small production system: web-app → checkout-api → payment-api → postgres Try these questions: What changed before INC-208? Trace the services affected by INC-208. Which runbook applies to INC-142? Compare INC-142 and INC-208. The comparison question is the strongest demonstration. It asks the agent to distinguish incidents that share related terminology but have different evidence paths. Repository: https://github.com/anilloutombam/incident-context https://github.com/anilloutombam/incident-context The repository contains two standalone applications: agent/ Next.js investigation interface and API sanity/ Sanity Studio, schemas, and demo data php flowchart LR User Incident question -- UI Next.js interface UI -- |POST /api/chat| API Next.js API API -- Loop AI SDK agent loop Loop <-- |model requests| Gemini Gemini 3.5 Flash-Lite Loop <-- |MCP tool calls| MCP Sanity Context MCP Content Sanity Content Lake