This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.
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.
When you ask it to compare the two incidents, the agent follows the structured path, not keyword matches:
Notice the evidence trail at the top. It shows the relationships the agent followed: INC-142 affected payment-api and was caused by a DBPOOLSIZE reduction; INC-208 affected checkout-api and was caused by a PAYMENTTIMEOUTMS 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: a deployment happened before an incident two incidents mention timeouts a runbook belongs to an affected service a configuration value changed near an outage
Those relationships are useful evidence. They are not automatically proof of causation.
The agent preserves the distinction. Every investigation returns: A direct answer — plain language, grounded in the evidence An evidence trail — the relationship path the agent followed Confirmed evidence — facts from the Knowledge Base Inferences — what the model had to infer (or in this case, nothing) A recommended next step — actionable based on what was discovered Sources — exact Sanity paths for verification
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 initialcontext, selects relevant entries, retrieves them through Knowledge Base tools, and traces explicit relationships. The system prompt explicitly forbids turning correlation into confirmed causation.