"Incident Brain: Giving an AI Agent a Graph Memory for Production Outages" published: true

Vidisha Gupta — Sat, 17 Oct 2026 17:36:21 +0000

When production goes down, the first ten minutes are not about fixing. They are about asking questions. What else will break? Who knows this system? Has this happened before?

The answers exist, but they are scattered across a service map, a team chart and old postmortems. Someone has to stitch them together by hand, under pressure. That is the problem I wanted to solve for Graph Hacks by WeMakeDevs and FalkorDB.

What I built

Incident Brain is an agent that keeps its context in a FalkorDB graph. You type something like "payments-api is returning 500 errors", and it answers with:

Blast radius: every downstream service affected, by hop distance
Who to ask: people ranked by ownership and hands-on experience
Similar past incidents: root cause, fix and who fixed it
Proof: the exact nodes, edges and Cypher behind each claim, highlighted in a live graph

Then you can log the incident. It is written back to the graph, so the next similar outage finds it.

Why a graph?

These questions are all about connections. "What breaks if this service fails?" is a multi-hop problem. In SQL it means recursive joins. In FalkorDB it is one readable query:

MATCH (f:Service {name: $name})<-[:DEPENDS_ON*1..4]-(s:Service)
RETURN DISTINCT s.name

That single query became one tool the agent can call. The agent never guesses. Every fact in its answer comes from a tool that ran a Cypher query and returned real nodes and edges.

How FalkorDB is used

Multi-hop traversal for the blast radius
shortestPath to explain why one service impacts another
Graph algorithms (PageRank) to rank affected services by importance
Persistent memory: each logged incident becomes a node with AFFECTED, FIXED_BY and SIMILAR_TO edges, so memory survives restarts
Multi-graph support: a shared company graph plus a separate memory graph per team

If you remove FalkorDB, the product stops working. The graph is not decoration, it is the brain.

The stack

Python, FastAPI, the official FalkorDB Python client, LLM tool calling, a force-directed graph view in the browser, and Docker. The whole thing starts with one command: docker compose up.

A challenge I hit

[Replace this with your real challenge. Example: "My first version let the model answer from its own knowledge, and it invented a service that did not exist. I fixed it by forcing every answer to come from tool results and returning node IDs as sources." Use whatever really happened.]

What I learned

[Write 2 or 3 honest lines from your experience. Example: "Designing the graph schema first made everything else easier. Once relationships were clear, the tools were small and simple."]

Try it

Live demo: [https://incident-brain-ashen.vercel.app/ ]
GitHub: [https://github.com/vidishagupta/incident-brain ]
Demo video: [https://youtu.be/tgIFDHjhuek?si=hZQJeaH4cgNR8uqV ]

Built for #GraphHacks with FalkorDB and WeMakeDevs. If you build agents, try giving them a graph. The difference between guessing and following relationships is big.

DEV Community: Vidisha Gupta