Most agent memory is a pile of notes. The agent can find something that looks like your question, but it can't tell you where a fact came from, whether it's still true, or who else knows it. So it gets things wrong with total confidence. At Graph Hacks, where 7,899 developers signed up, 647 teams took on that problem in the Agent Memory and Coordination track and built agent memory on FalkorDB in four days. The best ones built memory that explains itself.
Key takeaways. The strongest agent memory projects at Graph Hacks did five things. They linked every fact to its source, closed old facts instead of piling new ones on top, gave each agent its own graph, stored relationships so the agent could explain why, and let memory change what the agent does next. All five are a few lines of Cypher on FalkorDB.
Graph memory for AI agents stores what an agent learns as nodes and relationships, so one query can follow a fact to its source, check whether it's still current, and return the path as evidence. FalkorDB is a graph database built for this, with thousands of isolated graphs on one instance, vector and full-text search next to Cypher, and fast copies for testing changes. If you want the background on why flat memory breaks down over time, start with why your agent gets dumber the longer it runs. Below are the five patterns, the real code behind them, and how to try each one.
Vector memory vs. graph memory #
| What your agent needs | Vector-only memory | Graph memory on FalkorDB |
|---|---|---|
| Find something similar to the question | Yes | Yes, with vector and full-text search built in |
| Know where a fact came from | Only if you add metadata | Yes, follow the edge to the source |
| Know whether a fact is still true | Old and new facts sit side by side | Yes, old facts are closed, not piled up |
| Keep each agent's memory separate | Filters on a shared index | One graph per agent on the same instance |
| Explain why it answered | No | Yes, the path is the explanation |
How did the best teams build AI agent memory? #
1. Link every fact to its source
When agents share memory, one bad source turns into many bad actions. A research agent reads a poisoned web page and writes a "fact." Other agents trust it. They decide tickets, pay refunds and send emails. Deleting the page afterwards fixes nothing that already happened, and rolling memory back throws away all the good work done since.
kintsugi · Rupam Golui · GitHub · Live demo · Blog
kintsugi records every read, write, handoff and side effect as a provenance graph in FalkorDB. When a source is flagged, one traversal finds everything that depended on it, even across agent handoffs. Then it re-runs only those actions against clean memory and keeps everything else.
MATCH (s:Source {id: $src})<-[:INGESTED]-(a0:Action)
MATCH (a0)-[:FEEDS|HANDED_OFF*0..]->(a:Action)
RETURN DISTINCT a ORDER BY a.seq
Try it. Add a DERIVED_FROM or READ edge every time your agent writes a fact, and you can always ask where it came from. Start free on FalkorDB Cloud.
2. Close old facts instead of piling new ones on top
Most memory layers only append. Ask an agent what a customer's plan is, and it finds three answers from three different weeks. The fix is to treat memory like a ledger. A new fact either confirms an old one or replaces it, and the old one gets an end date instead of disappearing.
Relay · Tharun Kumar, Dharani K and Thanushrie Satishkumar · GitHub · Live demo · Blog
To prove it, the team built a whole fictional internet provider, WiFight, with an AI support desk run by a team of agents. The agents never message each other. Everything one agent learns goes into one shared FalkorDB graph, with who wrote it, when it was true and what it replaced, and every answer comes with the path behind it.
MERGE (f:Fact {triple_key:$tk, active:true})
...
ON MATCH SET f.is_new=false, f.corroboration_count=coalesce(f.corroboration_count, 1) + 1
...
OPTIONAL MATCH (old:Fact {predicate:$p, active:true})-[:ABOUT {role:'subject'}]->(s)
WHERE $single AND old.fact_id <> f.fact_id AND old.object_value <> $o
WITH f, s, collect(old) AS olds
FOREACH (old IN olds |
SET old.active=false, old.valid_to=f.valid_from, old.superseded_by=f.fact_id
REMOVE old:Current SET old:Superseded
CREATE (f)-[:SUPERSEDES]->(old))
In the builder's words."Having the vector index, the full-text index and the graph in one database. Our retrieval does exact match, typo match and vector search, then walks typed edges, all in Cypher in one place, with no second store to keep in sync." The Relay team
Try it. Give each fact a valid_from and valid_to, and filter to current facts in the same query that retrieves them. Start free on FalkorDB Cloud.
3. Give each agent its own graph
Multi-agent systems fail at the seams. One agent promises a customer a refund, another rejects it in a channel the customer never sees, and a third picks up the conversation with no idea what the customer believes. Shared memory doesn't fix this. Each agent needs its own view of the world, and the system needs to know who knows what.
SecondOrder · Tushar Agarwal · GitHub · Live demo · Blog
SecondOrder gives every agent its own FalkorDB graph holding what it believes, plus nested perspectives for what it thinks other agents believe. A perspective only stores what differs from its parent, so reading "what does Shipping think the customer believes" is one walk up the tree. SecondOrder ran 10,200 graphs on one FalkorDB instance at about 2.9 ms per event.
MATCH (p:Perspective) WHERE p.chain IN $prefixes
WITH p ORDER BY p.depth DESC LIMIT 1
MATCH path = (p)-[:INHERITS*0..6]->(q:Perspective)-[b:BELIEVES {entity: $entity, active: true}]->(v:Value)
RETURN v.name, b.via, b.t, b.event, b.src, q.chain, length(path)
ORDER BY length(path) ASC LIMIT 1
In the builder's words."I've used Neo4j and Postgres before, and both would have made this project harder. ... In FalkorDB every demo visitor simply gets their own graph on one instance, next to a shared baseline and a cache graph. Creating one is writing to a new key, and removing an idle one is a single delete." Rupam Golui, kintsugi
Try it. Call select_graph with a new name per agent or user. That is the whole setup. Start free on FalkorDB Cloud.
4. Store relationships, so the agent can say why
An agent that remembers events but not relationships can't explain itself. Ask why it made a choice and it guesses. Store who did what to whom, and "why" becomes a path you can show.
Emberfall · Hemant Gaikwad · GitHub · Live demo · Blog
Emberfall is a tabletop RPG run by three AI agents that share one FalkorDB graph. In session 3, Grimma the blacksmith refuses to forge a blade for Kael. Why? In session 1, Kael mocked her brother Borin in a tavern she never visited. Click "Why?" and one query lights up the path. Kael, the insult, Borin, and the brother edge to Grimma.
MATCH (n:NPC)-[:MADE]->(d:Decision {id:$did})-[:TOWARD]->(p:Player)
MATCH (d)-[:BASED_ON]->(e:Event)
MATCH path = (p)-[:PERFORMED]->(e)-[:TARGETED]->(t)-[:KIN_OF|MEMBER_OF*0..2]-(n)
RETURN path, e.id AS event_id
ORDER BY length(path) ASC
In the builder's words."Speed: most queries ran in about 1 to 3 ms, so many graph lookups per agent turn stayed invisible to the player." Hemant Gaikwad, Emberfall
Try it. Return the path, not just the answer, and show it to your users. Start free on FalkorDB Cloud.
5. Let memory change what the agent does next
Memory isn't only for answering questions. The most surprising project at Graph Hacks used memory as the agent's entire brain.
crashgraph · Ujesh Yadav · GitHub · Live demo · Blog
crashgraph is a lunar lander with no neural network and no model file. Before every engine decision it asks its memory what happened last time it was here, and after every attempt it writes down what went wrong. It learned to land from scratch over 3,743 attempts. Wipe the memory and it lands 0 of 30. Restore it from a GRAPH.COPY snapshot and it's back to 26 of 30.
The policy itself is a fast key lookup on every frame. When you ask why an attempt crashed, a shortest-path query over the same memory shows the safe route it should have taken.
MATCH (a:Situation {k:$k}), (o:Outcome {name:'landed_pad'})
CALL algo.SPpaths({sourceNode:a, targetNode:o, relTypes:['SAFE'],
weightProp:'cost', maxLen:12, pathCount:1})
YIELD path, pathWeight
RETURN [x IN nodes(path) | coalesce(x.label, x.name)], pathWeight
In the builder's words."Queries were fast enough to run inside the agent's decision loop every frame, which is the whole premise of the project. GRAPH.COPY gave us snapshot and restore almost for free, and that became our main proof." Ujesh Yadav, crashgraph
Try it. Snapshot your agent's memory with GRAPH.COPY before a risky change, and roll back in one command. Start free on FalkorDB Cloud.
More agent memory projects worth stealing from #
Care Circle · Aniket Gupta · GitHub · Blog. One shared medicine record for a family caring for one person, with one graph per family. Erasing a family's data is deleting one graph, so privacy is built into the structure.
Living Town · Dev Kansal · GitHub · Blog. A town of 10 AI characters with episodic, semantic and procedural memory in FalkorDB. Ask "how do you know?" and it follows the chain of who told whom back to whoever saw it.
HomeOS · Naomi Pereira, Shashwath Prabhu and Harshendra M · GitHub · Blog. A smart home that remembers what actually helped each person last time, with a private memory graph per person and a shared graph for the home.
Quarantine · Ankit Singh · GitHub. When one agent in a swarm gets poisoned, it traces who's infected across agents, tools and credentials, and uses algo.maxFlow to find the cheapest way to cut the damage off.
Nodes · Abhinav Ayyagari, Mahathi Aishwarya and Padmini Raj · GitHub · Blog. A shared graph that lets several Claude Code agents work on one codebase without colliding. Ownership of each function is an atomic lease in one Cypher query.
Airspace · Sushan Shetty · GitHub · Blog. Air traffic control for parallel coding agents. Each agent's "airspace" is every caller and test two hops out from the code it touches, checked before every edit.
Frequently asked questions #
What is AI agent memory?
AI agent memory is what lets an agent keep information between steps and sessions, like facts about a user, past decisions and what worked before. It usually includes short-term working memory in the prompt and long-term memory in a database that the agent reads from and writes to.
What is the difference between vector memory and graph memory?
Vector memory finds text that looks similar to a question. Graph memory stores facts and how they connect, so it can follow a fact to its source, check whether it's still current, and answer questions that cross several relationships. Many Graph Hacks projects used both, with vector search to find a starting point and the graph to follow the connections.
How do you keep agent memory from going stale?
Give each fact a time range and close old facts when new ones replace them, instead of only appending. Then filter to current facts in the same query that retrieves them. Relay does this with a single statement that creates, confirms or replaces a fact.
How do you keep memory separate between agents or users?
Give each agent or user its own graph. On FalkorDB that means using a new graph name, and many isolated graphs run on one instance. Deleting someone's memory is deleting one graph.
How do I add graph memory to my agent?
Start FalkorDB with one Docker command or a free cloud instance, then connect your agent through the FalkorDB MCP server or the Python or Node.js client. FalkorDB also works as the graph store for agent memory frameworks like Graphiti, Cognee and Mem0. See the agent memory docs.
Give your agent a memory that explains itself #
Every project here runs on the same FalkorDB you can start with one Docker command, docker run -p 6379:6379 -p 3000:3000 -it --rm falkordb/falkordb:latest, or a free cloud instance. Pick one thing your agent keeps forgetting, store it as a graph, and ask where it came from.
Not ready to build yet? Join the FalkorDB Discord to get help from our engineers, share what you build, and hear about the next Graph Hacks first.