How Hindsight Supports Evidence-Based Incident Diagnosis
An AI incident-response agent needs more than a language model.
It needs evidence.
That was the starting point for the diagnostic pipeline in OpsMind. The system combines current logs and metrics with historical incident experiences retrieved through Hindsight, then asks an AI agent to reason over the combined context.
The architecture deliberately separates those information sources.
Current telemetry tells the agent what is happening.
Hindsight helps explain what has happened before.
From Incident to Diagnosis
The diagnostic pipeline follows several stages:
Incident → Evidence → Memory → AI Reasoning → Diagnosis
For every incident, OpsMind first retrieves the incident details and then gathers current evidence.
The evidence layer provides:
- Application logs
- Performance metrics
- Error rates
- Resource utilization
- Service-specific signals
Only after that does the system construct a Hindsight query.
Figure 1 — OpsMind combines current telemetry with historical memory before generating a diagnosis.
This ordering is important because the agent should not start with a historical explanation and then search for evidence to justify it.
Instead, the evidence comes first.
Building the Evidence Context
The SRE agent retrieves the current incident and its evidence before constructing the reasoning prompt.
The investigation context intentionally contains the current incident's:
- ID
- Service
- Severity
- Symptoms
- Metrics
- Logs
It does not directly expose the stored root cause or resolution from the incident dataset.
That distinction prevents the AI from simply reading the answer from the incident record.
The model has to reason from the evidence available to the investigation.
The Role of Hindsight
Once the current evidence has been collected, OpsMind creates a query for Hindsight.
The query asks for previous SRE incidents with similar:
- Symptoms
- Service behavior
- Performance problems
- Errors
- Resource saturation
- Remediation experiences
- Outcomes
The retrieved incidents are then passed into the reasoning context as historical information.
This gives the AI another dimension of evidence.
For example:
Current evidence: database connection utilization is 97%.
Historical context: previous payment API incidents involved connection pool exhaustion and successful pool-capacity remediation.
The agent can compare the two rather than treating either one independently.
A Concrete Example: INC-008
INC-008 involved the Payment API.
The telemetry included:
Latency: 6.1 seconds
HTTP 500 errors: 26%
Database connection utilization: 97%
The logs also reported that database connection acquisition was taking longer than two seconds and that requests were waiting for database connections.
These signals formed the primary diagnostic evidence.
Hindsight returned historical incidents including INC-007, INC-006, and INC-001.
The AI therefore had both current and historical context.
Figure 2 — INC-008 diagnosis combines current telemetry with historical incident context.
The resulting diagnosis identified database connection pool exhaustion causing connection contention and timeouts.
The reasoning connected the current signals:
High connection utilization → connection acquisition delays → request waiting → increased latency → HTTP 500 errors
The historical incidents provided additional operational context but were not treated as proof.
Why the Separation Matters
Consider two incidents that both contain the phrase “database timeout.”
They may have completely different causes.
One could be caused by connection pool exhaustion.
Another could be caused by a slow query.
Another could result from network connectivity.
A memory system that simply finds a similar phrase could therefore mislead an AI agent.
This is why OpsMind treats similarity as supporting context rather than diagnosis.
The agent is instructed to support current claims with current evidence and avoid inventing facts that are not present in the investigation context.
This is a useful pattern for AI systems that operate in technical environments:
retrieval should expand context, not replace reasoning.
Producing Structured Output
The AI agent returns a structured diagnosis containing:
likely_root_causereasoningevidencehistorical_contextrecommended_actionsconfidence
Structured output makes the result easier for the frontend and downstream workflow to consume.
Instead of displaying an unrestricted block of generated text, OpsMind can map each field to a specific part of the incident dashboard.
For example:
Root Cause
Database connection pool exhaustion.
Evidence
Connection utilization, connection acquisition delays, latency, and HTTP 500 errors.
Historical Context
Previous payment API incidents with related database connection behavior.
Confidence
High.
This structure also makes the reasoning easier for a human operator to inspect.
Confidence Is Not a Guarantee
The system includes a confidence field, but this should not be interpreted as a statistical probability.
It is a reasoning-level indication of how strongly the available evidence supports the diagnosis.
For an operational system, that distinction matters.
An AI-generated “High” confidence value does not mean the diagnosis is guaranteed to be correct.
It means the evidence available to the agent provides relatively strong support for the proposed explanation.
That is one reason OpsMind keeps a human approval gate before remediation.
From Diagnosis to Runbook
After the AI produces its diagnosis, OpsMind matches the likely root cause against a configured runbook.
The runbook contains predefined remediation steps.
For the database connection pool scenario, the recommended workflow includes actions such as increasing connection capacity and restarting the affected service.
The runbook is marked as:
simulation_only: true
This means the workflow demonstrates the remediation process without changing a production environment.
The separation between diagnosis and execution is deliberate.
The AI can recommend an action, but an operator remains responsible for approving it.
The Memory Feedback Loop
After successful remediation, OpsMind retains the incident outcome in Hindsight.
This creates a feedback loop:
Evidence → Diagnosis → Resolution → Learning → Future Evidence
The next incident can therefore benefit from the previous incident's outcome.
Figure 3 — INC-007 can use the retained INC-008 experience as historical context.
When INC-007 was analyzed after INC-008 had been retained, Hindsight returned INC-008 as part of the historical context.
This was an important validation of the architecture because it demonstrated that the memory was operationally reusable rather than simply stored.
What We Learned
Current evidence needs priority
The latest logs and metrics should remain the foundation of incident diagnosis.
Retrieval needs a purpose
A memory query should search for operationally relevant experiences, not simply matching words.
Similarity is not causality
Two incidents can look similar while having different root causes.
Structured reasoning improves inspection
Separating diagnosis, evidence, historical context, actions, and confidence makes the agent's output easier for engineers to evaluate.
Memory should feed a loop
The most useful memory is created when successful incident outcomes become available to future investigations.
Conclusion
Building the diagnostic pipeline for OpsMind changed how we thought about AI-assisted incident response.
The objective was not to make the model answer every incident from memory.
It was to give the model access to two complementary sources:
What the system is telling us now.
What the organization has experienced before.
Hindsight provides the persistent historical context, while logs and metrics provide the current evidence.
Keeping those roles separate makes the overall reasoning process easier to inspect and gives human operators a clearer basis for deciding whether a proposed remediation should proceed.
Hindsight Documentation
What Is Agent Memory? — Vectorize
OpsMind — GitHub Repository



Top comments (0)