I Replaced My AI Agent's Flat Fact Store with a Graph Database
The author discusses the transition from a flat fact store to a graph database for their AI agent framework, LocalClaw. This change was motivated by the need for better relationship handling and fact evolution. The new system, FalkorDB, allows for efficient multi-hop traversal and temporal queries while maintaining a small footprint of 85MB.
- ▪The initial flat fact store led to issues with duplicate facts and lack of relationship traversal.
- ▪FalkorDB was chosen for its capabilities in graph traversal, vector similarity, and hybrid keyword search.
- ▪The new system allows for temporal queries and better entity extraction through improved context referencing.
Opening excerpt (first ~120 words) tap to expand
# I Replaced My AI Agent's Flat Fact Store with a Graph Database and It Runs in 85MBI've been building LocalClaw, a local-model-first AI agent framework running on personal hardware through Ollama. No cloud, no API costs. A few weeks ago I posted about the router/specialist architecture. A lot of people asked about the memory system so here's that.## The ProblemStarted with a JSONL fact store and embedding similarity retrieval. Simple enough until it wasn't. After a few weeks of real use I had 14 near-duplicate facts about the same topics from different sessions. Layered dedup on top of dedup and it still wasn't clean.The bigger problem was relationships. "Peter works at DevMesh" and "DevMesh is building an outreach platform" were two separate embeddings.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at Ycombinator.