An AI incident-response system is not just a language model connected to a prompt.
It needs a user interface, an API layer, memory, reasoning, and a way to keep track of incidents as they move through the workflow.
I worked on the architecture of IncidentMind, an AI-powered incident response agent designed to combine these components into one workflow.
The system separates the interface, backend logic, persistent memory, AI reasoning, and incident state so that each part has a clear responsibility.
The overall architecture is:
Streamlit → FastAPI → Hindsight → Gemini → SQLite
Each component solves a different part of the incident-response problem.
The architecture at a glance
IncidentMind architecture showing how Streamlit, FastAPI, Hindsight, Gemini, and SQLite work together.
The IncidentMind workflow can be represented as:
User
│
▼
Streamlit UI
│
▼
FastAPI
│
┌──────────┴──────────┐
▼ ▼
Hindsight SQLite
Historical Memory Incident State
│
▼
Gemini
AI Analysis
│
▼
Investigation + Remediation
The important architectural decision was to keep memory and reasoning as separate responsibilities.
Hindsight provides persistent historical context, while Gemini performs the reasoning over the current incident and the available evidence.
SQLite is used for incident workflow state, while Streamlit provides the interface through which the user interacts with the system.
Why separate the components?
Separating the system into layers makes the workflow easier to understand and maintain.
The Streamlit interface handles interaction.
FastAPI handles the backend API and coordinates the workflow.
Hindsight provides persistent incident memory.
Gemini performs the AI analysis.
SQLite stores the incident state used by the application.
This means that changing one part of the system does not require redesigning the entire application.
For example, the AI model can be changed without changing how the Streamlit interface communicates with the backend.
The frontend layer
I used Streamlit as the frontend because it allowed me to build an interactive interface for the incident-response workflow without adding unnecessary frontend complexity.
The interface allows the user to:
- enter incident details
- submit an incident for analysis
- view historical context
- review the AI-generated diagnosis
- see investigation steps
- view remediation recommendations
- resolve the incident and store the outcome
The frontend communicates with the FastAPI backend instead of directly calling Hindsight or Gemini.
This keeps the API keys and backend logic away from the user interface.
The FastAPI backend
FastAPI acts as the central coordinator of the application.
The frontend sends the incident information to the backend, and the backend controls the sequence of operations.
The main flow is:
Incident Request
↓
FastAPI
↓
Retrieve Historical Memory
↓
Build Analysis Context
↓
Gemini Analysis
↓
Return Structured Result
This makes the backend responsible for coordinating the different services rather than putting the workflow logic inside the frontend.
Connecting the memory layer
Hindsight is connected to the backend as the persistent memory layer.
When a new incident arrives, the backend sends the incident description to Hindsight and retrieves relevant historical memories.
Those memories are then included in the context provided to Gemini.
After the incident is resolved, the backend creates a structured post-mortem and retains it in Hindsight.
This creates a two-way relationship between the incident workflow and the memory layer:
Recall before analysis → Retain after resolution
Connecting Gemini to the workflow
Gemini is responsible for analyzing the incident after the backend has gathered the relevant context.
The backend builds a prompt containing:
- the current incident description
- historical evidence from Hindsight
- instructions for root-cause analysis
- investigation requirements
- remediation guidance
Gemini then returns the analysis that is displayed in the Streamlit interface.
The important point is that Gemini is not responsible for retrieving or storing the incident history.
That responsibility stays with the application and Hindsight.
This separation makes the architecture easier to reason about:
Hindsight remembers → Gemini reasons → FastAPI coordinates → Streamlit displays
Managing incident state with SQLite
While Hindsight stores persistent knowledge about previous incidents, the application also needs to track the current incident workflow.
For this, IncidentMind uses SQLite.
SQLite stores information such as:
- incident ID
- title
- description
- severity
- status
- root cause
- resolution
- outcome
This creates a useful separation between application state and agent memory.
SQLite answers:
What is the current state of this incident?
Hindsight answers:
What have we learned from previous incidents?
Keeping these responsibilities separate prevents the memory layer from becoming the application's entire data store.
Putting the architecture together
IncidentMind Streamlit interface showing the incident intake and end-to-end response workflow.
With the individual components connected, the complete workflow becomes:
New Incident
│
▼
Streamlit UI
│
▼
FastAPI
│
┌──────────┴──────────┐
▼ ▼
SQLite State Hindsight Recall
│
▼
Historical Evidence
│
┌────────────┴────────────┐
▼ ▼
Gemini Current Incident
│
▼
AI Analysis
│
▼
Investigation + Remediation
│
▼
Resolution
│
▼
Hindsight Retain
This architecture keeps each component focused on a specific responsibility while allowing them to work together as one incident-response system.
What I learned from the architecture
Designing IncidentMind showed me that the architecture of an AI agent is just as important as the model used inside it.
Each layer has a clear role:
- Streamlit handles user interaction.
- FastAPI coordinates the workflow.
- Hindsight provides persistent incident memory.
- Gemini performs incident analysis.
- SQLite maintains application state.
This separation also made debugging easier because each part could be tested independently.
For example, memory retrieval could be checked separately from AI generation, while the incident state could be inspected without depending on the model.
A limitation of the architecture
One limitation I had to consider was that the system depends on several services working together.
If the AI model is temporarily unavailable, analysis cannot be generated.
If the memory service is unavailable, the agent loses access to its historical context.
This made error handling and clear separation between components important during development.
The architecture is therefore designed so that failures in one layer can be identified without making the entire workflow difficult to debug.
Why the architecture matters
The main lesson from building IncidentMind was that an AI agent is more than its model.
The model provides the reasoning capability, but the surrounding architecture determines what information reaches it, where previous knowledge comes from, how results are stored, and how users interact with the system.
For IncidentMind, the combination of a frontend, API layer, persistent memory, AI reasoning, and application state created a complete incident-response workflow rather than a standalone AI prompt.
Conclusion
IncidentMind uses a layered architecture to connect incident management, persistent memory, and AI reasoning.
The final flow is:
Streamlit → FastAPI → Hindsight → Gemini → SQLite
Each component has a specific responsibility, while the backend connects them into a single workflow.
Designing the system this way made it easier to separate current incident state from historical memory and to keep the AI reasoning process grounded in the information available to the agent.
The architecture became the foundation that allowed IncidentMind to turn a collection of independent services into one incident-response system.
Top comments (0)