Building GraphHacks Nexus: Giving Multi-Agent AI a Real Memory on FalkorDB

How I turned a simulated agent cockpit into a load-bearing FalkorDB system — and why the graph is the product.

AI agents don't have a memory problem. They have a graph problem.

Every multi-agent demo I've built had the same dirty secret: the "memory" lived in a Python list. Restart the process and the agents wake up with amnesia. Store it in a flat table and you can retrieve facts, but you can't ask the questions that actually matter — who handed this to whom, why does this exist, what breaks if this changes?

For the WeMakeDevs × FalkorDB Graph Hacks hackathon I built GraphHacks Nexus to answer one question honestly: what happens when the graph is not a visualization on top of a database, but the database the product runs on?

What I built

GraphHacks Nexus is a multi-agent engineering cockpit. You type a feature in plain English — "Add an ElevenLabs voice-cloning endpoint" — and a four-agent squad writes a six-level maturity stack into the graph:

VibeArchitect (L0–L1) — the plain-English "what does this do" card and its unit economics.
FullStackBuilder (L2–L3) — the UI → API → database wiring and the real implementation.
SeniorAuditor (L4) — the security and spend audit.
PrincipalResearcher (L5) — complexity bounds and prior art.

The whole thing is read at six depths through a Builder Maturity Dial (L0 Vibe Coder → L5 Principal) and filtered across 17 domain lenses. The idea is simple: one connected graph, six audiences, zero lost context.

Why FalkorDB specifically

FalkorDB is a Redis-based graph database with a superpower for this exact problem: one instance holds thousands of isolated graphs. That gave me two things for free.

1. Tenant isolation as structure, not a filter

Each tenant's memory lives in its own named graph — tenant:<id>. Isolation isn't a WHERE tenant_id = ... clause that someone will eventually forget to add; it's the graph key itself. Every access goes through a single router (db.named_graph()), and there are no cross-graph reads.

2. MERGE makes agent memory idempotent

Agents re-read and re-write state constantly across handoffs. Because every write is MERGE-based, re-running anything is safe. I proved it with a concurrency test: 16 parallel writers produced 16 distinct rows and zero loss.

The memory model: three tiers in one graph

The graph isn't a message log. It composes three kinds of memory plus a coordination layer, all connected:

Episodic — :User, :Session, :Turn: what happened, when.
Semantic — :Entity, :Fact, and the L0–L5 :ConceptNode projection: what is true about the domain.
Procedural — :Workflow and :Step: what the team learned to do, replayable.
Coordination — :Agent and :Handoff: who handed what to whom and why.

Typed edges do the storytelling: [:PRODUCED], [:IN_SESSION], [:MENTIONS], [:HAS_FACT], [:DERIVED_FROM], [:HANDED_TO], [:TARGETS], and the one that makes the demo click — [:ENDANGERS], a directed edge from an L4 security risk to the L0 feature it threatens.

The part that makes it real work

Here's the honest test for any "graph" project: if you delete the graph, does the product still work? If yes, the graph is decoration.

In GraphHacks Nexus, stopping FalkorDB makes the cockpit fail — visibly. The frontend ships no fallback seed data. A dead database returns HTTP 503 and the app shows an error screen with a Retry button. Restart FalkorDB, hit Retry, and the graph is back. That flip is the whole submission, and it's the reason the memory had to live in a real database.

FalkorDB's algorithms are load-bearing, not cosmetic

Because FalkorDB ships graph algorithms and variable-length traversals, questions that would otherwise be pages of application code became single queries:

CALL algo.pageRank('Symbol', 'CALLS')
YIELD node, score
RETURN node.label, node.source_file, score
ORDER BY score DESC LIMIT 10;

That's the "hotspots" query over the repository's own AST graph. Blast radius is a [:CALLS*1..2] traversal; shortest dependency paths drive an explainable-answer feature. Every answer returns a DecisionTrace: the exact Cypher, the parameters, the node ids it touched, and the query time in milliseconds. You can't fake that with a vector store.

One graph, three tracks

The same FalkorDB instance carries three projections:

Track 02 — Agent Memory & Coordination (tenant:<id>): the four-tier model above, handoffs, isolation, concurrency.
Track 01 — Connected-Data Actions (code:<repoId>): the repo's AST graph, queried for blast radius, PageRank hotspots, and shortest paths.
Track 03 — Company Brain (company:brain): people, commits, docs and code, answering who owns this, why does it exist, and where have the docs drifted from the code.

You can paste any GitHub URL and the backend clones it, builds its AST graph, and loads it — so the demo isn't hard-coded to one repo.

The LLM can't cheat without the graph

The guidance feature feeds real graph facts — PageRank hotspots, blast radius, owners, drift — into the LLM prompt and requires every claim to cite a concrete value. Remove FalkorDB and the model has nothing to ground on. The graph isn't just the UI's source of truth; it's the reason the AI's answer is worth trusting.

What I learned

Multi-graph is an architecture, not a feature. Using the graph key as the tenant boundary removed an entire class of "oops, cross-tenant leak" bugs.
MERGE is the agent-memory primitive. Idempotency isn't a nice-to-have when agents retry and hand off; it's what makes the system safe to re-run.
Prove the dependency, don't describe it. "The graph does real work" is a claim; stopping the database and watching the app break is evidence.
Explainability comes from the database. Returning the Cypher and node ids with every answer turned a black box into something a reviewer can audit.

If you're building agents and your memory is a list, a table, or a pile of embeddings, try drawing the relationships instead. The moment the graph becomes the thing your product depends on, the whole design gets simpler — and a lot more honest.