I reverse-engineered the three biggest agent-memory tools
2 points
2 hours ago
| 1 comment
| HN
I spent weeks reading about how Cognee, Graphiti, and Neo4j's `agent-memory` build their agent memory architectures. They converged on the same heavy knowledge-graph design: an ontology, LLM extraction pipelines, deduplication, the works.

I really wanted to use them for my personal use case, but that looks like such a heavy setup that adds a lot of friction and silos. Plus, it feels like I just get my data trapped in their service, for not a ton of value.

That's why my "long-term memory" still lives in Obsidian, Readwise, and Google Drive, with per-project LLM wikis as the agent's memory. No infrastructure. And I'm fine with it.

They ship memory as a product, which, in my opinion, at a personal or small scale, is overkill. You can build the same "knowledge graph" experience via plain old `.md` files within an LLM wiki memory.

But still, graphs are strong, so I adapted the same architecture from the Cognee, Graphiti, and Neo4j `agent-memory` stacks to build a data-mining tool with just MongoDB, VoyageAI, and Gemini Flash. But I scoped it to a very particular problem and ontology domain to avoid the KG noise.

On the other end of the spectrum, if you want to ship a product at medium-to-large scale, it makes sense to start using monsters such as Neo4j, Zep, or HydraDB.

But I am curious: what is your long-term memory setup? Obsidian + LLM wikis vs. Cognee/Graphiti/Zep? Do you actually use tools such as Cognee or Zep?

In case you are curious about how Cognee, Graphiti, and Neo4j's `agent-memory` work under the hood, I wrote a full breakdown here: https://www.decodingai.com/p/unified-memory-from-scratch-knowledge-graphs

coder-pm
1 hour ago
[-]
Did any of these actually covers the invalidation? It's easy to store memory and access it but I'm curious how these tools handles the fact that something is not true anymore?
reply