How I Built CausalMesh: An Autonomous SRE Swarm Powered by FalkorDB

How I Built CausalMesh: An Autonomous SRE Swarm Powered by FalkorDB
Why Flat Vector RAG Fails at 3 AM and How GraphBLAS Solves Cascade Outages

By Yashvir Singh
Submitted to FalkorDB Graph Hacks 2026: Context for AI Agents
Demo Video: https://youtu.be/skAD7R8OXp8

1. The 3:14 AM Nightmare in Distributed Systems

If you have ever held an on-call pager for a modern microservice fleet, you know this gut-wrenching feeling:

At 3:14 AM, your phone shrieks. PagerDuty sounds the alarm:
[CRITICAL P1] High Error Rate (504 Gateway Timeout) on /checkout

You rub your eyes and open Datadog. Fifteen dashboards are blazing crimson. The API Gateway is dropping connections, inventory-service is throwing thread pool exceptions, payment-service is timing out, and database connections are spiking.

You scramble to spin up an emergency incident bridge in Slack with four groggy engineers. The urgent questions start firing:

"Did someone ship a deployment in the last hour?"
"Who owns the database configuration for inventory workers?"
"Is Postgres actually down, or did the connection pool starve?"
"Didn't payment fail with this exact signature three weeks ago? What was the mitigation back then?"

It takes 45 agonizing minutes to discover the truth: Dave merged PR-88 thirty-five minutes ago, tuning db_pool.idle_timeout from 30s down to 2s in an effort to "reduce memory footprint." Under early-morning flash traffic, database connections churned violently, exhausting the pool and cascading 504 timeouts all the way up to checkout.

45 minutes of human panic. Thousands of dropped transactions.

Now imagine replacing those 45 minutes with 18 seconds of autonomous, explainable graph reasoning.

That is why I built CausalMesh.

1. Why AI Agents Fail Without a Graph (The Vector RAG Fallacy)

Over the past year, hundreds of engineering teams have attempted to construct "AI Site Reliability Engineers" using standard LLM agent frameworks and vector databases. They embed cluster logs, postmortems, and wiki runbooks into chunks, run semantic search, and prompt an LLM to "troubleshoot."

In production, this approach consistently collapses. Here is why:

Topological Blindness: Vector similarity cannot follow dependency hops. Finding that Service A calls Service B, which connects to Queue C, which is processed by Worker D writing to Database E requires graph pathfinding. Vector search has no concept of directional causality.
Hallucinated Runbooks: LLMs generate plausible-looking remediation commands (e.g., kill -9, untested SQL migrations, or dropping pods) that risk worsening an active outage. Without verified procedural workflows, unconstrained LLM tool execution is an operational liability.
Disjointed Organizational Context: Outages do not happen in a vacuum--they are triggered by human changes. A vector search over Git diffs treats a commit message as raw text, completely missing who authored it, who reviewed it, what Jira ticket requested it, and which downstream dependencies it touches.
Context Amnesia Across Sessions: When an incident ends, standard agents discard their context. The next time a failure occurs, the agent starts from zero, unable to recall how similar past episodes were solved.

The Paradigm Shift: For an agent to act responsibly, its context layer cannot sit on the side. The graph must shape every single step of the agent's reasoning loop.

1. Enter FalkorDB: The GraphBLAS Context Engine

I chose FalkorDB as the central context layer for CausalMesh. Built on Redis and powered by GraphBLAS, FalkorDB represents property graphs as sparse adjacency matrices. This architectural choice gives AI agents three critical superpowers:

Sub-Millisecond Multi-Hop Traversal: Evaluating 3 hops of a 25-microservice dependency DAG executes in < 2 milliseconds--orders of magnitude faster than relational joins or vector chunk searches.
Multigraph Isolation (prod vs staging): FalkorDB supports thousands of isolated graphs within a single instance. In CausalMesh, causalmesh_prod and causalmesh_staging operate completely independently without cross-tenant contamination.
Mathematical Lineage & Explainability: Every decision my agents make is backed by an OpenCypher query. When an agent isolates a root cause, it returns the exact graph traversal path, eliminating LLM hallucinations.

CausalMesh Architecture Flow

1. The Solution: A Tri-Agent Swarm Across All Three Tracks

Rather than relying on an unwieldy single prompt, CausalMesh deploys a Tri-Agent Swarm that coordinates directly through FalkorDB:

The Tri-Agent Orchestration Flow:
Ingestion (Incident Alert): Ingests 504 Gateway Timeout on /checkout and activates the Sentinel Agent.
Triage (Sentinel Agent): Executes OpenCypher get_blast_radius() and native shortestPath() to trace the 3-hop cascade down to the failing database.
Investigation (Investigator Agent): Traverses code commits, Git PR diffs, and Jira tickets to pinpoint breaking PR-88 authored by Dave Kim.
Remediation (Mitigator Agent): Loads the procedural action DAG from FalkorDB, pauses for Human Approval, scales connection pool limits, and triggers rolling pod restarts via MCP.
Memory (Episodic Persistence): Writes the resolved incident episode back into FalkorDB memory so future agents can resolve identical issues instantly.
Track 01: Agents That Act on Connected Data

In Track 01, the agent uses the graph not as a passive reference, but as an active algorithmic reasoning engine.

1. Graph Algorithms as Agent Tools

Rather than having LLMs guess which service is the bottleneck, CausalMesh equips agents with FalkorDB's native graph algorithms:

Critical Dependency Shortest Path (shortestPath):

cypher
MATCH (src:Service {name: $src}), (dst:Service {name: $dst})
WITH shortestPath((src)-[:CALLS*]->(dst)) AS p
RETURN [n IN nodes(p) | n.name] AS path_nodes, length(p) AS hops

The Sentinel Agent calls find_critical_path to trace how errors propagate upstream from a failing database to user-facing gateways.

Bottleneck Centrality & In-Degree Analysis: To identify the single point of failure (SPOF) among candidate services, the agent calculates dependency in-degree:

cypher
MATCH (caller:Service)-[:CALLS]->(target:Service)
WHERE target.name IN $candidates
RETURN target.name AS service, count(caller) AS dependency_in_degree
ORDER BY dependency_in_degree DESC

1. Model Context Protocol (MCP) Tool Selection

CausalMesh executes all infrastructure changes through standardized MCP tools:

mcp_infra:patch_config (dynamically adjust connection pool limits)
mcp_k8s:rollout_restart (safe rolling restart of pods)
mcp_redis:flush_ns (targeted cache invalidation)
mcp_metrics:error_rate (verify 504 error rates return below 0.01 threshold)

1. Real-Time Explainability

Every reasoning step is broadcast live over Server-Sent Events (SSE) to an interactive Cytoscape.js frontend. When the Sentinel Agent traverses dependencies, the affected nodes animate in yellow; when the root cause is isolated, it pulses red; and when the Mitigator restores health, the entire topology transitions to vibrant emerald green.

Live Topology DAG

Track 02: Agent Memory and Coordination

Memory is more than storing raw chat transcripts. CausalMesh implements a Tri-Layer Memory Mesh directly inside FalkorDB:

1. Episodic Memory (Cross-Session Experience)

Every resolved incident is committed back to FalkorDB as an (:Episode) node linked to the involved services:

cypher
CREATE (ep:Episode {
incident_id: $incident_id,
alert_name: $alert_name,
root_cause: $root_cause,
root_cause_pr_id: $pr_id,
mttr_seconds: $mttr,
timestamp: $ts,
status: 'resolved'
})
WITH ep
MATCH (s:Service {name: $svc})
MERGE (ep)-[:INVOLVED]->(s)

When an alert triggers, the Investigator Agent queries past episodes using symptom matching, discovering in milliseconds how identical past issues were mitigated.

1. Procedural Memory (Executable Action Chains)

Runbooks in CausalMesh are not static markdown files; they are deterministic directed acyclic graphs (DAGs) stored in FalkorDB:

cypher
MATCH (p:Procedure {trigger_pattern: 'db_pool_exhaustion'})-[:STEP]->(first:Action)
MATCH path = (first)-[:NEXT*0..10]->(step:Action)
RETURN step.name, step.tool, step.params, step.order
ORDER BY step.order ASC

The Mitigator Agent traverses this chain step-by-step, guaranteeing that recovery actions follow approved architectural guardrails.

1. Semantic Memory (Failure Ontology & Risk Classification)

CausalMesh stores architectural rules and domain classifications in FalkorDB:

cypher
MATCH (r:SemanticRule {pattern: 'db_pool_exhaustion'})
RETURN r.category, r.layer, r.impact, r.suggested_mitigation, r.blast_risk

This informs the agent that database pool starvation is a ResourceStarvation issue with Critical blast risk requiring immediate pool expansion.

1. Shared State & Agent Handoffs

Agents do not communicate through ephemeral strings. When the Sentinel Agent finishes triage, it writes an (:AgentHandoff) node into FalkorDB:

cypher
CREATE (h:AgentHandoff {
from_agent: 'SentinelAgent',
to_agent: 'InvestigatorAgent',
incident_id: $incident_id,
summary: 'Isolated degraded cluster to inventory-service (blast radius: 3 services)',
timestamp: $ts
})

This guarantees that agent coordination is completely transparent, persistent across sessions, and auditable during postmortems.

Track 03: Company Brain (Connected Knowledge)

The hardest enterprise questions are never answered by a single database record:

"Who wrote the code that touches this service?"
"Which Slack channel discussed this recent change?"
"Where is the runbook for this database?"

CausalMesh connects code commits, Jira tickets, Slack discussions, and runbooks into a single Company Brain graph.

FalkorDB Cloud Multi-Dimensional Knowledge Graph

1. The Hackathon Showcase Query: "Who Knows What?"

I implemented the sponsor's exact query to identify domain specialists based on code contributions and service ownership:

cypher
MATCH (e:Engineer)-[:AUTHORED]->(pr:PullRequest)-[:MODIFIED_SERVICE]->(s:Service {name: $service})
RETURN e.name AS engineer, e.slack AS slack, e.role AS role, count(pr) AS contribution_count
ORDER BY contribution_count DESC
LIMIT 5

When inventory-service degraded, CausalMesh instantly identified Dave Kim (@dave) as the primary author and Alice Mehta (@alice) as the reviewer, tagging them in the automated postmortem.

1. Full Decision Traceability

CausalMesh connects Jira tickets to PRs, and Slack chats to services:

(:Ticket {id: 'TICK-1042'}) -> [:ATTACHED_TO] -> (:PullRequest {id: 'PR-88'})
(:PullRequest {id: 'PR-88'}) -> [:MODIFIED_SERVICE] -> (:Service {name: 'inventory-service'})
(:Doc {id: 'DOC-1'}) -> [:DOCUMENTS] -> (:Service {name: 'inventory-service'})
(:SlackMessage {id: 'MSG-902'}) -> [:REFERENCES] -> (:Service {name: 'inventory-service'})

During triage, the Investigator Agent pulls the complete picture:

Jira: TICK-1042: Memory pressure on inventory workers under peak load
Slack: @dave in #deployments: "Merged PR-88 (tuning idle timeout 30s -> 2s)."
Runbook: DOC-1: Postgres Connection Pool Starvation & Recovery Runbook

The agent doesn't guess what happened; it reads the connected history of the entire engineering organization.

1. Performance Benchmarks: 45 Minutes Down to 18 Seconds

I evaluated CausalMesh against simulated cascade outages across 25 microservices running against an active AWS FalkorDB Cloud instance:

Mean Time to Recovery (MTTR): Dropped from 45.0 minutes (traditional on-call human bridge) down to 18.4 seconds on CausalMesh (150x faster autonomous resolution).
Multi-Hop Query Latency: < 2ms with FalkorDB GraphBLAS, compared to 280ms+ with vector chunk retrieval.
Mean Time to Detection (MTTD): 0.2 seconds via automated telemetry graph ingestion.
Root Cause Isolation: 1.2 seconds with 100% deterministic Cypher graph provenance, eliminating LLM hallucinations.
Mitigation Execution: 17.0 seconds executing verified procedural action DAGs with human safety sign-off.
Explainable Audit Trail: 100% deterministic Cypher graph lineage saved into FalkorDB episodic memory.

1. Key Learnings & Feedback on FalkorDB

Building CausalMesh gave me deep first-hand experience with FalkorDB in an agentic setting:

Graphs are Essential Guardrails for Autonomous AI: Probabilistic LLMs should not execute arbitrary commands on production infrastructure. By encoding procedures as graph paths, I achieved autonomous speed with enterprise safety.
GraphBLAS Delivers Real-Time Swarm Interaction: Multi-agent swarms require frequent context queries. FalkorDB's matrix-backed sub-millisecond execution ensures agents never bottleneck on database reads.
Multigraph Isolation Simplifies Staging: Being able to isolate pre-production staging environments and production topologies in a single database instance with zero cross-tenant contamination is a massive developer experience win.
Resources & Links
Demo Video Walkthrough: https://youtu.be/skAD7R8OXp8
GitHub Repository: https://github.com/yashvirsingh09/CausalMesh
Live Cloud Database: FalkorDB Cloud (AWS ap-south-1)
Built With: FalkorDB, GraphBLAS, FastAPI, Next.js 14, Cytoscape.js, Groq, and Model Context Protocol (MCP).