GraphOps Brain dashboard showing service health, active incidents, and the main application interface.
When a production system goes down at 3 AM, the difficult part isn't just finding the error. It's figuring out what caused it.
Which service is responsible? What changed recently? Is another service affected? Have we dealt with the same issue before, and did we find a fix?
These questions are connected. But an AI agent working with isolated documents or information from a single session can easily miss those connections. It might have the right information somewhere in its context, but that doesn't mean it understands how everything fits together.
That was one of the problems I wanted to explore while building GraphOps Brain for the FalkorDB Hackathon.
GraphOps Brain is an AI-powered reliability platform built around FalkorDB. The idea is to bring service relationships, incident history, company knowledge, and agent memory into one connected graph. Instead of relying only on an LLM to figure things out, the agent can query that graph, follow relationships, and use the results to investigate an incident.
Here's how I approached the three hackathon tracks and where FalkorDB fits into the system.
Track 01: Agents That Act on Connected Data
Incident response rarely happens in isolation. A problem in one service can affect several others, and the cause might be a deployment that happened somewhere else in the system.
To represent those relationships, I modeled services, dependencies, deployments, and incidents as nodes in FalkorDB. Relationships such as DEPENDS_ON, CHANGED, and AFFECTED connect the relevant parts of the system.
This gives the agent something more useful than a collection of logs or documents: a way to explore how different events and services relate to each other.
When checkout-api goes down, for example, the agent can query the graph to look for recent deployments and trace the services involved. I use Cypher queries to retrieve this information and build an evidence path that connects the relevant entities.
One example looks like this:
Deploy-42 → Payment-Gateway → Checkout-API → Incident-2481
The actual graph relationships show how these entities are connected, helping the agent investigate a problem using information it can retrieve from FalkorDB.
The Graph Explorer showing the path between the deployment, payment gateway, checkout service, and incident.
The Run Detail page showing the investigation findings and the human approval step.
The important part here is that the agent isn't expected to invent a root cause based on a text description alone. It can retrieve connected evidence from the graph and use that evidence during its investigation.
Once it has enough context, it can look for a relevant past fix and propose a rollback for an engineer to review. The final decision remains with the human, rather than giving the agent unrestricted control over production.
Track 02: Agent Memory and Coordination
I also wanted to address a limitation that comes up when building agents: what happens to everything the agent learns after a session ends?
A conversation history can preserve what was said, but it doesn't necessarily give the agent a useful way to connect previous incidents with the services and fixes involved.
In GraphOps Brain, I use FalkorDB to store two kinds of memory.
Episodic memory records what happened during an incident. Procedural memory records how a problem was resolved or how a particular issue can be handled.
These memories are connected to the relevant services through ABOUT relationships, so they aren't just standalone text entries. The graph can also show which entities a memory relates to.
The Agent Memory page showing a selected memory, its confidence score, and its linked entities.
When another incident occurs, the agent can query the graph for relevant memories and use the results when deciding what to investigate or recommend next.
I also implemented a simple confidence adjustment for verified successful fixes:
confidence += (1 - confidence) * 0.2
The intention is to increase confidence when a proposed fix is verified as successful, while making each subsequent increase smaller as the score gets higher. This is a simple heuristic, not a guarantee that the agent is correct, but it provides a starting point for recording successful outcomes and improving future recommendations.
For me, this is where graph-based memory becomes particularly useful. The system can retain not only what happened, but also how that experience relates to the services it may need to investigate again.
Track 03: The Company Brain and Permission-Aware RAG
The third part of GraphOps Brain focuses on company knowledge.
Imagine an engineer asking, “What is the payment SDK migration policy?” A conventional retrieval pipeline might find a relevant document and pass it to the LLM. But finding a document is only part of the job. The system also needs to understand the context around it and whether the person asking the question should be allowed to see it.
For this, I built a GraphRAG pipeline using FalkorDB.
The retrieval process combines two steps. First, a full-text search finds relevant Document nodes. Then, the system expands through the graph to retrieve related context, such as the owner of the service described in a document.
That additional context can make the answer more useful because the agent isn't working with the document alone.
There is another requirement that matters just as much: access control.
In GraphOps Brain, documents have visibility properties, such as workspace or team:payments. The retrieval query takes the user's permissions into account and filters out documents they aren't allowed to access before the retrieved context reaches the LLM.
For example, when Krish, a member of the Core Platform team, asks about the payment SDK migration policy, the interface can show the answer alongside a warning that says “1 matching item hidden by permission.”
The Knowledge Base showing the answer and the permission warning when Krish asks about the payment SDK migration policy.
When Ananya, who belongs to the Payments team, asks the same question, the system can retrieve the relevant RFC that her permissions allow her to access.
The important distinction is that retrieval isn't based only on which document matches the question. It also takes the user's access into account. That helps prevent restricted information from being included in the context sent to the model.
The Guardrail: No LLM-Written Cypher
Giving an AI agent access to a database introduces another challenge: how do you stop it from generating a query that performs an unintended or destructive operation?
For example, a query such as MATCH (n) DETACH DELETE n could delete every node and its relationships in the selected graph. You don't want an LLM improvising database commands without proper controls.
In GraphOps Brain, the LLM doesn't write Cypher queries directly.
Instead, it interprets the user's request and selects from predefined, parameterized query templates. The project includes more than 40 query files, including templates such as Q01_blast_radius.cypher.
A Cypher query template or the Python code that loads and executes predefined queries.
This approach keeps query execution within a controlled set of operations. It also makes the database interactions easier to review and maintain because the query logic lives in the codebase rather than being generated from scratch for each request.
It doesn't remove every security risk on its own, but it provides a clear boundary between the model's interpretation of a request and the database operations the application permits.
What I Learned Building GraphOps Brain
Building GraphOps Brain gave me a practical way to explore how FalkorDB can support AI agents beyond basic retrieval.
The same graph can represent service dependencies, connect incidents to past fixes, preserve memories across sessions, and help retrieve company knowledge with access controls.
What I find most interesting is how these pieces work together. A graph isn't just a place to store relationships. Those relationships can become part of the information an agent uses to investigate a problem, explain its findings, and make a recommendation.
There's still plenty of room to improve how these systems evaluate confidence, validate proposed fixes, and handle failures. But this project has been a valuable step toward building agents that work with connected, retrievable evidence rather than relying entirely on what an LLM generates.
Project Links
Live Demo: https://graphops.krishchhabra.com
GitHub Repository: https://github.com/Krishkumarchhabra25/grapghops-hackathon
API Documentation: https://api.graphops.krishchhabra.com/docs
Health Checks
Live Health Check: https://api.graphops.krishchhabra.com/api/v1/health/live
Readiness Health Check: https://api.graphops.krishchhabra.com/api/v1/health/ready
My Portfolio: https://krishchhabra.com/
Thanks to the FalkorDB team and wemakedevs and the Discord community for the support during the hackathon!
