Building an Incident Dashboard Around Hindsight Memory
An incident-response agent can have good reasoning and still be difficult to use.
For OpsMind, the frontend was therefore treated as more than a place to display an AI-generated answer. The dashboard needed to make the incident state, evidence, historical memory, diagnosis, remediation, and learning lifecycle visible to an engineer. The interface follows the same principle as the backend:
From Backend State to Operator View The OpsMind backend exposes endpoints for:
The main dashboard provides an incident selector and displays information such as:
The goal is to allow an engineer to understand the incident without jumping between multiple screens.
Making Current Evidence Visible
The first information shown after selecting an incident is its current operational state.
For example, INC-008 displays: This gives the engineer immediate visibility into what is happening now.
The UI should not make an engineer open the historical memory section before seeing the current evidence.
That mirrors the reasoning architecture.
One of the most important frontend decisions was to make historical memory visible rather than hiding it inside the AI prompt.
The dashboard can show a memory match and identify the historical incidents retrieved by Hindsight.
For INC-008, historical context included incidents such as: This makes the memory loop observable.
AI incident and memory context visual
An engineer can therefore see not only what the AI concluded, but also the context that influenced the conclusion.
If historical context is completely invisible, an engineer may have difficulty understanding why an agent recommended a particular action. Showing the historical incident references provides a basic explanation of where additional context came from.
It also makes the system easier to debug.
If an irrelevant incident appears in memory, an engineer can identify that problem rather than simply seeing an unexplained AI recommendation. This is especially useful when working with retrieval systems.
Retrieval quality becomes part of the application's observable behavior.
The Confidence and Evidence Sections
OpsMind also displays a confidence value and evidence signals.
The confidence field gives a concise indication of how strongly the agent's reasoning supports the diagnosis.
The evidence section shows the concrete signals associated with the incident.
Database connection pool exhaustion.
Database connection utilization, connection acquisition delays, latency, and HTTP 500 errors.
This makes the diagnosis easier to inspect.
The interface does not need to expose every internal model token or reasoning detail.
Instead, it provides structured information relevant to an operator's decision.
After diagnosis, the dashboard presents a human approval gate.
The interface makes the distinction between recommendation and execution visible.
The engineer can review the diagnosis and runbook before approving remediation.
The runbook is marked as simulation-only.
This is important because the dashboard should communicate the system's operational boundaries clearly.
The user should never be left wondering whether clicking the action button will change a real production service.
Once the simulated remediation succeeds, the interface changes state.
The incident becomes:
and the dashboard shows that the outcome was retained as organizational memory.
Hindsight memory lifecycle visual
This visual state is important because it communicates that resolution is not the end of the workflow.
The incident has moved into the memory lifecycle.
Demonstrating Future Recall
The strongest frontend demonstration occurs when a different incident is analyzed after the memory has been retained.
When INC-007 is analyzed, the dashboard can show INC-008 among its historical context.
AI incident investigation visual
This creates a clear visual narrative:
That is much easier to understand when the interface makes the state transitions visible.
One lesson from building the dashboard was that an AI interface can become cluttered very quickly.
There are many possible pieces of information:
The useful hierarchy is:
That sequence follows the engineer's decision process.
Frontend and Backend Boundaries
The frontend does not perform the incident reasoning itself.
It calls the backend API.
The backend coordinates:
It also makes it possible to change the AI or memory implementation without redesigning the entire interface.
If memory influences an AI decision, users should have some visibility into that context. The dashboard should clearly distinguish between analyzed, awaiting approval, resolved, and memory-retained states.
Historical memory is useful, but the latest telemetry should remain prominent.
Showing the transition from resolution to retained memory makes the value of persistent memory much easier to understand.
The interface should help an engineer inspect and decide, not simply display generated text.
Building the OpsMind dashboard made one thing clear: an AI SRE agent is not only a backend problem.
The frontend determines whether an engineer can understand what the agent knows, why it reached a conclusion, what historical context influenced it, and what will happen if remediation is approved.
The dashboard therefore mirrors the architecture of the agent itself.
That makes the memory loop something an engineer can actually see and reason about rather than an invisible mechanism behind an AI response.