I Built an AI Agent That Fixes Production Outages by Rewiring a Graph
When a Redis cache dies at 2 AM the hard part is not knowing it is down. The hard part is figuring out what else is broken and who owns it and who is on call and what fixed it last time.
Most AI agents struggle here. Vector search cannot follow dependency chains or compare standby nodes and it has no idea who owns what. So for the FalkorDB hackathon I built NexusOps. It is an SRE agent that uses a graph as its brain instead of just a database.
What it does
When redis-cache-primary goes down NexusOps does three things.
First it finds the blast radius. One Cypher query walks up to 4 hops of dependencies and finds every affected service like auth-service and checkout-api and web-storefront. The same query returns the owning team and the on-call engineer and the healthy standby.
Second it remembers past incidents. Earlier fixes are stored as memory nodes in the graph. Before touching anything the agent checks what worked before. In my demo incident INC-2025-88 had already solved the exact same problem by moving traffic to the read replica.
Third it actually fixes the problem. Instead of only suggesting a fix it rewrites the graph. It deletes the broken dependency edges and points callers at redis-cache-ReadReplica and marks the services healthy and logs a new incident. It also opens a ticket JIRA-OPS-2704 for the on-call engineer.
The company brain
The graph is not only services. It also holds teams and engineers and Slack channels and runbooks and suspect commits. So the final report does not just say Redis is down. It says Core Platform owns it and Aarav Patel is on call and the alert goes to the core-platform-alerts channel and the runbook is RB-101 and the suspect commit is a8f921c.
The AI part
I used Kimi-K3 on NVIDIA NIM with streaming. It shows its reasoning live and ends with a clear incident report so every change to the graph can be explained.
Hackathon tracks covered
Track 01 Graph Decision and Action: it scores standby nodes and changes graph edges to heal services.
Track 02 Cross-Session Memory: past resolutions and agent handoffs stay saved in the graph.
Track 03 Company Brain: services are linked to owners and on-call engineers and runbooks and tickets.
Try it
🕸️ NexusOps: Multi-Agent SRE & Company Brain Command Center
FalkorDB Hackathon Submission
Track 01: Graph Decision & Action
Track 02: Cross-Session Memory & Multi-Agent Handoffs
Track 03: Company Brain & Automated Workflows
LLM Engine: NVIDIA NIM (moonshotai/kimi-k3) / OpenAI / FastMCP
🌟 Executive Summary
When critical microservices fail, Site Reliability Engineers (SREs) face an overwhelming barrage of disconnected monitoring alerts, tribal team knowledge, outdated wiki runbooks, and uncoordinated Slack conversations.
NexusOps solves this by unifying:
- Dynamic Microservice Topologies & Standby Replicas
- Cross-Session Procedural & Episodic Resolution Memory
- The Company Brain (Teams, On-Call SREs, Runbooks, Git Commits, and SLA Policies)
into a high-performance property graph inside FalkorDB.
Three collaborative AI agents (TriageAgent, MemoryAgent, and ActionAgent) interact with FalkorDB to diagnose blast radius, score candidate standbys, share state via in-graph handoffs, mutate runtime dependencies, and spawn automated post-incident remediation tickets.
🏗️ System Architecture
+------------------------+
|Start FalkorDB with docker compose up -d then install the requirements with pip install -r requirements.txt then add your API key to the env file. Run streamlit run app.py for the dashboard or python agent.py for the command line agent.
My biggest takeaway is simple. Once the graph holds structure and memory and ownership together the agent stops sounding like a chatbot and starts acting like an on-call engineer.
Top comments (0)