DEV Community: Sumanth Gadiparthi

NexusOps: Multi-Agent SRE & Company Brain Command Center Powered by FalkorDB

Sumanth Gadiparthi — Sun, 18 Oct 2026 14:19:59 +0000

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

wondermen103 / nexusops-falkordb

🕸️ 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

                             +------------------------+
                             |

…

View on GitHub

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.

Building ArenaIQ: A Real-Time Stadium Fan Experience Powered by AI

Sumanth Gadiparthi — Mon, 20 Apr 2026 12:57:38 +0000

We’ve all been there. You pay top dollar for a concert or a sports game, only to miss the most exciting moment because you were stuck in a concession line for twenty minutes, or trapped outside at the most crowded entrance gate.

Stadiums are massive, unpredictable ecosystems. But what if we could give every fan a real-time, personalized guide to navigate the venue?

That was the inspiration behind ArenaIQ—a real-time fan experience dashboard built for the PromptWars by Google hackathon. Here is a look at how I built it, the architecture behind it, and how Prompt Engineering drives the entire experience.

🎯 The Problem
Large venues suffer from three massive crowd-control issues:

Gate Bottlenecks: Thousands of people flock to the main entrance, leaving side gates completely empty.
Concession Wait Times: Fans guess which food stand is fastest, often guessing wrong.
Dangerous Density: Sections get dangerously crowded without warning.
I wanted to build an application that solves all three of these problems natively on a fan's mobile device, all without relying on expensive backend infrastructure or paid APIs.

💡 The Solution: ArenaIQ
ArenaIQ is a premium, mobile-responsive dashboard designed to feel like a live, high-end tech product. It features three core modules:

Smart Gate Recommender: Highlights the absolute fastest gate to enter through based on live capacity.
Concession Wait Time Tracker: Ranks food stalls and displays wait-time trends so you know exactly when to grab a bite.
Flash Crowd Alerts: A live heatmap that pushes an alert directly to your phone if your current stadium section exceeds 85% capacity.
🏗️ Technical Architecture
To meet the strict hackathon constraints (specifically keeping the entire repository under 10MB), I had to be incredibly efficient with the architecture.

Frontend Framework: Next.js 14 (App Router) using React.
Styling & UI: Tailwind CSS. I completely avoided heavy external component libraries (like Material UI or Chakra) and instead built a custom Glassmorphic dark-mode design system. This kept the bundle size incredibly small while looking exceptionally premium.
State & Simulation: Because I couldn't use a paid live-data API, I built a custom React hook called useStadiumLive. This acts as a localized Simulation Engine, generating "Random Walks" and jittering the stadium data every 5 seconds to mimic thousands of moving fans.
🤖 The "Secret Sauce": The AI Logic Bridge
Because this project was for PromptWars, the judges aren't just looking at the code—they want to see how Prompt Engineering is utilized.

To showcase this, I built the AI Logic Bridge.

Instead of hiding the AI logic in the backend, I built a live, typewriter-animated terminal directly into the dashboard. Every 5 seconds, as the stadium data changes, the UI generates the exact System Prompt that the AI uses to calculate its recommendations. It dynamically feeds the AI the live gate occupancies, crowd thresholds, and concession wait times, and outputs the final recommendation.

It makes the prompt engineering 100% transparent and proves that the app's routing is driven by dynamic context, not just hardcoded if/else statements.

🚀 Accelerating Development with Antigravity
Building a beautiful, dynamic, and state-heavy dashboard in a short amount of time is difficult. To speed up my workflow, I heavily leveraged Google's Antigravity AI assistant.

Using Antigravity allowed me to:

Rapidly scaffold the useStadiumLive simulation engine.
Iterate on the Tailwind CSS glassmorphism design system without getting bogged down in CSS syntax.
Wire up complex Next.js state management across multiple components seamlessly.
🏁 Conclusion
ArenaIQ proves that you don't need massive databases, paid API keys, or heavy backend infrastructure to build a product that feels "live." By combining Next.js, highly optimized vanilla Tailwind, and smart Prompt Engineering, you can build dynamic, real-time dashboards that solve real-world problems.

The codebase is currently completely open-source and comes in at a remarkably small 0.08 MB.

Check out the code on GitHub here: https://github.com/wonderful809/arenaiq
What are your thoughts on using Client-Side AI simulations for live events? Let me know in the comments below!