Talk to most AI agents and you are talking to a goldfish. Three seconds of memory, then the conversation ends and everything you said is gone. Next session you re-introduce yourself, re-explain your project, re-state your preferences.
We want an elephant instead, one that never forgets and knows how everything connects. The usual fixes fall short. Markdown memory files, like Karpathy’s LLM Wiki, store flat text with no relationships, so the agent re-reads everything each turn, slow and token-hungry. Vector databases fetch similar snippets but miss relationships. Ask “who are the CTOs of the companies in Tokyo?” and you get chunks about Tokyo or chunks about CTOs, never the join.
What a graph gives you
A graph stores knowledge, not text, and the unit of knowledge is the relationship: two entities joined by a named edge. “EdoMatrix is headquartered in Tokyo” becomes EdoMatrix -[:headquartered_in]-> Tokyo, and “Aiko is its CTO” becomes Aiko -[:cto_of]-> EdoMatrix. Relationships are the key to everything here. They let the agent answer by following connections instead of re-reading text, and every other benefit builds on them.
- Isolation. Each agent gets its own memory, a graph of its own. With no cross-agent data to wade through, the agent stays accurate and efficient: it reasons only over its own context, so nothing bleeds in to skew an answer or slow a query. One agent’s facts never color another’s.
- Context that evolves. The memory is not a static file. Ordinary conversation and agent actions keep adding to it, and each new fact writes only its own nodes and edges. The agent’s context grows and sharpens without growing more expensive: you append the right piece instead of rewriting or re-embedding the whole memory, and retrieval still traverses only the slice of context a question needs. Token cost stays flat as the graph grows.
Two agents, two memories: Will and Liz
Six months ago I started using OpenClaw to see how much it could lift my day-to-day productivity. Now I lean on two agents. Will runs my work, projects, infra, and meetings. Liz runs my personal life, family, travel, and errands. I use both every day, and each keeps its own memory in a separate FalkorDB graph, agent_will and agent_elizabeth, so the two never mix. The rest of this post follows Will, the work agent.
The stack
FalkorDB is the memory and the reason this works. It is a graph database that answers multi-hop questions in sub-milliseconds with no second database to run. One instance holds 10,000+ isolated graphs, a private memory per agent. It even ships a browser at localhost:3000 to click around what your agent knows.
Two helpers wrap it. Cognee is the brain that builds the memory, and OpenClaw hosts the chat. Cognee turns messy chat into a clean graph: it reads each message, extracts the entities and relationships, and resolves duplicates so “Tokyo” said twice stays one node. Its extract, cognify, load pipeline writes straight into FalkorDB, on whatever LLM you point it at.
Cognee is the memory layer agents plug into, and OpenClaw picks it up as a skill. The official cognee-openclaw plugin and its FalkorDB setup skill let OpenClaw store everything it learns in FalkorDB, in one command and one env block:
openclaw plugins install @cognee/cognee-openclaw
openclaw cognee setup
GRAPH_DATABASE_PROVIDER=falkor
VECTOR_DB_PROVIDER=falkor
ENABLE_BACKEND_ACCESS_CONTROL=True # one graph per agent
Watch the memory build itself
I go to a lot of events. Conferences, customer dinners, prospect meetings, and each one leaves me with a pile of new people: who they are, which company, what role, who they used to work with. Keeping that straight is exactly the kind of work I want Will to handle.
So I never tell Will to “save this.” I just brief it after the event, the way I would a colleague:
EdoMatrix is a DevOps company headquartered in Tokyo.
Hiro Tanaka is its founder and CEO. Aiko Watanabe is the CTO; she previously built the search engine at SilverShard.
ShibuyaWorks is also in Tokyo, CEO Kenji Saito, CTO Mio Nakamura (ex OnyxStream).
I keep briefing Will after every event, the people I meet and their role, company, and location, expecting it to store all of that efficiently. OpenClaw hands each turn to Cognee, which writes the people and their connections into agent_will, Will’s graph in FalkorDB. It also gives each entity a vector embedding, so the same memory supports semantic search, not just exact graph lookups. The graph grows as I talk: new people and companies become nodes, and the second mention of Tokyo reuses the existing node instead of duplicating it:
Weeks later, prepping for a follow-up, I ask the question we opened with. Will answers in one Cypher hop:
MATCH (city:Entity {name:'tokyo'})<-[:headquartered_in]-(co:Entity)
<-[:cto_of]-(cto:Entity)
RETURN co.name AS company, cto.name AS cto
company cto
edomatrix aiko watanabe
shibuyaworks mio nakamura
Two hops, one query, both CTOs, plus any follow-up I never planned for.
None of this is staged. Here is the same subgraph in the live FalkorDB browser, the real agent_will graph at 1,596 nodes:
Stored this way the data stays clean: one node per entity, no duplicates, typed relationships, and only the small subgraph is read per query, so token cost stays low. That is the difference between an agent that quotes you back to yourself and one that understands you.
Build it yourself
The whole recipe is open source:
- FalkorDB: falkordb.com and github.com/FalkorDB/FalkorDB
- Cognee: cognee.ai and github.com/topoteretes/cognee
- OpenClaw plugin: @cognee/cognee-openclaw and the OpenClaw + FalkorDB setup skill
- The recipe: FalkorDB/falkordb-cognee and topoteretes/cognee-integrations
docker run -p 6379:6379 -p 3000:3000 falkordb/falkordb:latest
