How Ripple uses FalkorDB to remember who was told what, and to come back and correct them when a policy changes.

Team: Sahil Mane and Harsh Gupta Hackathon: WeMakeDevs × FalkorDB, Graph Hacks: Context for AI Agents (Oct 15–18, 2026), all three tracks Try it live: ripple-2.up.railway.app · Code: github.com/sahil1330/ripple

The problem: your AI is confidently out of date

On Jul 14, 2026, GitLab merged a change into its public handbook: personal VPN subscriptions stopped being reimbursable. Before, you could claim up to $150 a year. After, the answer is NordLayer, the company VPN.

The handbook page updated, and for most tools that is the end of the story. But think about everything that still holds the old answer:

• An employee, Priya, already asked the company assistant "Can I expense my ExpressVPN?" and was told yes, up to $150.

• An accounts-payable agent has a cached rule that auto-approves personal VPN claims, and Priya's $150 claim is sitting in its queue.

• Wiki pages and FAQ copies still cite the old rule.

Search can find the new page. A vector index can embed it. Neither knows who was told the old version. That is a relationship problem, so we solved it with a graph.

Meet Ripple

Ripple is a company's own AI assistant. It answers questions from a FalkorDB graph, records every answer it gives, and when a fact changes it finds everyone affected, blocks stale agent actions, and comes back to fix them.

Every company is its own graph in one FalkorDB instance. Switch the company in the UI and you get a different graph, different people, and a different assistant.

What actually happens (try it yourself)

We ran the live demo end to end. Here is the real sequence:

1. Ask.** As Priya, we asked: "Can I expense my ExpressVPN subscription?"

   "Yes — personal VPN subscriptions are reimbursable up to $150 per year, and a yearly subscription can be submitted in one claim."

   The answer cites the exact fact version it came from, and a "How I found this" panel shows the actual Cypher the agent ran. Ripple also records that it told Priya this version. That record is the whole trick.

2. The policy changes. The demo replays the real GitLab commit. A Sentinel agent writes the new fact version, which supersedes the old one, and a change card lands in every department's inbox: "Personal VPN subscriptions no longer reimbursable."

3. Trace. A Tracer agent follows every path from the old version and finds everyone and everything still holding it: people who were told, agents that cached the rule, docs that cite it, plans and pending actions that depend on it. Each one is ranked by time-to-harm, so what breaks soonest gets fixed first.

4. Guard. Before the accounts-payable agent approves Priya's claim, it calls check_fresh over MCP. Its rule derives from a superseded version, so the action is blocked, with the stale version, the current version, and the source change attached.

5. Fix. Fixer agents claim tasks from the graph, patch the docs, refresh the caches, and replan the actions, until coverage reaches 100%.

6. Correct. We asked again: "Can I expense my ExpressVPN now?"

   "Earlier I told you: reimbursable up to $150 per year. That changed on Jul 14, 2026 (MR !20421). Starting July 15, 2026, ExpressVPN and other personal VPN subscriptions are not reimbursable; use NordLayer instead."

   That opening line is not the model improvising. It is enforced in code, from the record of what Ripple previously told this person.

Hit "Get explanation" on any change card and you get the before and after side by side, the graph path showing exactly why it reaches you (change → old version → WAS_TOLD → you), who else is affected, and what to do now.

How it works

The graph model is simple on purpose. Facts have versions. New versions SUPERSEDE old ones. People WAS_TOLD a version. Agents CACHED one. Plans DEPEND_ON derived facts. Because dependency edges point from the dependent to the dependency, a single breadth-first traversal from an old version answers the question no search engine can: who is still acting on this?

On top of that:

• An LLM agent grounded in Cypher. The assistant picks graph tools, runs real Cypher, and writes its answer only from tool results, with citations. Every answer shows its tool trace.

• A freshness guard over MCP. Any agent can ask the graph "is what I'm about to act on still current?" before it acts.

• Graph algorithms as ranking tools. PageRank over the real handbook link graph and betweenness centrality find the hubs that spread a stale fact furthest.

• Task nodes for coordination. Fixer agents claim work atomically from the graph, so nothing gets fixed twice and nothing gets missed.

• One graph per company. Tenants are separate graphs, not rows with a filter, so cross-company leaks are structurally impossible.

Did it work? Our eval

We wrote a live evaluation that runs against the deployed app: 31 questions across both demo companies, covering policy before and after the change, team membership, multi-hop questions like "which agents rely on the VPN rule?", explain-why, corrections, unknown questions, a prompt-injection attempt, and a cross-tenant leak attempt.

Result: 100% correct, 0 hallucinations, median latency about 1.66 seconds, with the full agent pipeline (change written, impact traced, stale actions blocked, tasks completed, coverage at 100%) verified at every step. The eval earned its keep too: early runs caught the model swapping names and one cross-tenant leak, which we fixed and re-ran.

Why FalkorDB

The questions Ripple exists to answer ("who was told this?", "which agent cached it?", "what pending action depends on it?") are edges, not embeddings. FalkorDB's built-in algorithms (BFS, PageRank, betweenness, shortest paths) run inside the same database our agents query, its serialised writes make atomic task claims free, and separate graphs per tenant gave us isolation without filtering hacks. We tested against both FalkorDB v4 and v6 and documented the quirks we hit in the repo.

Try it

• Live: ripple-2.up.railway.app — ask "Can I expense my ExpressVPN?", click Next step through the demo, then ask again.

• Code: github.com/sahil1330/ripple

Team: Sahil Mane (graph, agents, MCP, API) and Harsh Gupta (web UI, deployment, docs, demo video).

AI disclosure: we used AI coding assistants while building Ripple. We reviewed, tested, and can explain every part of the code and architecture.

Built with FalkorDB for WeMakeDevs Graph Hacks.