AI Tools Each Remembering Separately? Unify Memory with a Graph Database

In today's world where AI coding tools are increasingly widespread, there's an awkward reality: every tool is smart, but none of them remember each other. You finalize a tech decision in Claude Code, then switch to Cursor and it knows nothing about your project's framework. This isn't a model capability problem—it's a missing storage architecture. A developer built Engram at FalkorDB's Graph Hacks hackathon, using a graph database to provide shared memory for all AI tools, and shared the design trade-offs and pitfalls encountered along the way.

Why Vector Storage Is Not Enough

The most common approach to adding memory to AI agents is embedding a vector database for similarity search. But the author points out that when memory truly carries critical decisions, the flaws of vector databases become apparent: it can't distinguish old from new. If you tell the agent on Monday "we're using Express," and then on Thursday say "actually we switched to Hono," the vector database will return both when answering "what framework are we using?" because both are semantically about frameworks and score highly. Nothing in the vector representation encodes a "supersedes" relationship. You could add time-decay weights, but that just makes the old wrong answer gradually fade out rather than disappear.

The graph database solution is direct: a supersedes relationship is just an edge. New memories point to old memories via a SUPERSEDES edge, and old memories are marked as superseded but not deleted. Recall filters for active status by default, history remains traceable with reasons for change attached. This design ensures the memory system doesn't confidently give already-overturned decisions.

Embeddings and Vector Databases: An embedding maps text to a dense vector in a high-dimensional space, where semantically similar texts are closer together. Vector databases retrieve similar vectors quickly via approximate nearest neighbor search (such as HNSW, IVF) and are the mainstream approach for semantic search. However, this representation only encodes "similarity," not "temporality" or "logical relationships." Therefore, when two semantically similar but temporally conflicting memories exist simultaneously, vector databases lack a mechanism to determine which is the currently valid version, relying only on extra metadata fields or decay functions, which can introduce errors in high-stakes decision scenarios.

Three Scenarios Where Graph Structure Truly Shines

The author initially thought "graph" was just marketing hype, but after actually building it, three points changed his mind.

Provenance Is a Traversal Path, Not a Field

"Which tool, in which session, when said what, and superseded what" naturally corresponds to a path: Tool -[:RAN]-> Session -[:CAPTURED]-> Memory -[:SUPERSEDES]-> Memory. There's no need to design a provenance JSON field and keep it in sync—explaining memory is just following edges, always correct because nothing can fall out of sync.

Recall Genuinely Improves Through Graph Expansion

Full-text search for "what framework does relayer use" can only find memories that literally mention "relayer." But if a memory only says "uses Hono" without mentioning "relayer," a one-hop traversal through RELATED_TO entity edges can still discover it—this edge is strengthened whenever two entities co-occur in the same memory. The author admits this was the part he initially doubted but that worked on the very first real test.

Multi-Graph Isolation Comes for Free

FalkorDB hosts a named graph per project on a single instance, plus a global graph, with no additional infrastructure. Project A's decisions don't leak into Project B's recall, not because filters are written, but because they are different graphs.

Graph Databases and the Property Graph Model: Graph databases use nodes (entities) and edges (relationships) as their core data model, and edges can carry properties (such as time and reason). Unlike relational databases, graph databases store relationships as first-class citizens, so multi-hop traversals (e.g., from tool to session to memory to old memory) don't require complex JOINs at query time, and performance degrades more slowly with depth. The property graph model (used by Neo4j, FalkorDB) allows edges to have direction and labels, naturally suited for expressing semantic relationships like "supersedes" and "related to," and provides structured paths for provenance.

The Actual Pitfalls (The More Interesting Part)

Behind seemingly simple APIs are undocumented behaviors that only reveal themselves when you run real queries against real data.

FalkorDB query results are objects keyed by RETURN aliases, not positional arrays. The author's first version of all query functions assumed the second shape—compiled and ran fine, but silently returned useless results: indexing an object with [0] just yields undefined, no error. Finding the problem took an hour; fixing it took two minutes.

Its full-text index is powered by RediSearch under the hood, and ordinary multi-word query strings are parsed as implicit AND/phrase matching. A normal question like "what framework does relayer use" matches nothing, even if a memory containing "relayer" is right there, because the query doesn't literally contain all the other words in the sentence. The fix is small (remove stop words, connect remaining words with OR), but impossible to guess from the docs.

The extraction model the author wanted to use, Moonshot Kimi K2, is listed as a hosted model in Groq's docs, but was completely unavailable on the tested API key—not a permission error, just a direct 404. The solution is to call /v1/models to see what's actually available. This is a reminder: a model being documented and a model being available for your key are two different things.

These aren't rare bugs—they're the regular tax of building on unfamiliar infrastructure. The only lesson is plain: run real queries, read real response shapes, don't trust what the code "should" do.

RediSearch Full-Text Indexing: FalkorDB's full-text index relies on the RediSearch module under the hood. RediSearch by default parses multi-word queries as implicit AND or phrase matching, emphasizing precision over recall. For natural language questions, this leads to many missed recalls because query terms must all appear. Developers typically need to explicitly handle stop words, use OR connections, or adopt tokenization strategies to match search intent. This behavior is often not prominently documented and easily causes confusion during integration.

Final Form and Core Value

Claude Code automatically captures memories through session hooks—you never say "remember this," you just have normal conversations, and decisions fall into the graph at session end. Cursor and Gemini CLI read the same graph via MCP, only needing an engram_recall hint at task start to compensate for their lack of a hook system. The local Web UI draws the real graph, with nodes colored by status and SUPERSEDES edges highlighted—this is the most convincing part of the demo because it's real data, not a conceptual diagram.

If he could show only one thing, the author would choose: let a different tool ask the tool that made the decision, and it gets the current answer with historical justification. That's the entire selling point, and it works because the underlying layer is a graph.

Implications for Cross-Tool Memory

Engram's practice reveals a neglected dimension: the fragmentation of the AI tool ecosystem is not just an interface problem, but a memory architecture problem. Vector databases are suitable for fuzzy retrieval, but in scenarios requiring state evolution and relational reasoning, graph structures provide a more natural expression. For developers using multiple AI coding tools simultaneously, unified graph memory means decisions are no longer lost when switching tools, and context truly flows.

Of course, this approach still has limitations: MCP reads depend on prompt self-awareness, and automatic capture is only available in tools that support hooks. But the direction is clear—letting AI tools share a "brain," and graph databases are currently the answer that best fits the problem.

One-line Summary

A developer builds Engram, a cross-AI-tool shared memory system using a graph database, solving the problem that vector storage cannot express supersedes relationships.

Paragraph Summary

The article introduces the Engram project built at the FalkorDB hackathon, which uses a graph database to provide shared memory for AI coding tools like Claude Code and Cursor. The author points out that vector databases cannot encode supersedes relationships in memory, while graph databases naturally resolve old-new decision conflicts via SUPERSEDES edges. The graph structure provides real value in three scenarios: provenance traversal, recall expansion based on entity edges, and multi-project graph isolation. The article also shares pitfalls with undocumented FalkorDB behaviors such as query results being objects rather than arrays and full-text index implicit AND matching, ultimately demonstrating the core value of cross-tool memory: any tool can retrieve the current decisions made by other tools along with historical justification.