I spent the past year building a unified memory layer for my AI assistant using knowledge graphs on MongoDB. I made basically every mistake first. Ontology design alone froze multiple projects on my laptop for months before I found what actually worked.

Naive memory fails because file search bloats the context window, and semantic search over history can't traverse the relationships between people, topics, and preferences. I had to stop treating memory as retrieval and start treating it as a data-modeling problem .

Here are the core mistakes I made:

I overthought the ontology. I tried to design the perfect schema upfront, which deadlocked the build. Lesson: Start with a tiny base called POLE+O (Person, Object, Location, Event, Organization) and add subtypes only when data exposes collisions, like "Claude Code" being extracted as a Person instead of an Object.

I confused resolution with deduplication. Naming is not identity, and conflating them corrupts the graph. Lesson: Resolution normalizes names, while deduplication decides identity using specific thresholds: ≥0.95 auto-merges, >0.85 triggers human review, and ≤0.85 creates a new node.

I skipped reasoning memory. The agent kept repeating failed strategies because it only had short-term and long-term layers. Lesson: Add a third layer to store a trace of what worked (strategy, tools, success/failure), though be careful as bad traces can reinforce bad strategies.

If you want to understand the whole reasoning behind these mistakes supported by the system of my agentic memory via KG and ontologies, consider going over my latest 6 LinkedIn posts:

3 ways to model your ontologies for GraphRAG → https://www.linkedin.com/feed/update/urn:li:share:7446856909179027456

LangGraph/CrewAI or from scratch? → https://www.linkedin.com/feed/update/urn:li:share:7449362677560221696

A year building GraphRAG from scratch → https://www.linkedin.com/feed/update/urn:li:share:7449366886603128833

The third memory type: reasoning memory → https://www.linkedin.com/feed/update/urn:li:share:7454454641939034113

Building a production-grade personal AI assistant → https://www.linkedin.com/feed/update/urn:li:share:7456973563858821120

"Designing Your Agents' Unified Memory" → https://www.linkedin.com/feed/update/urn:li:share:7464580605327060992

If you've built agent memory, did you treat it as a retrieval or a data-modeling problem? What ontology approach worked for you?

[留言]

为什么值得关注

能改变理解方式，而不只是重复常识；符合当前抓取需求；它提供了新的理解或解释，而不只是表面观点

来源：reddit，领域：projects，保留分：0.63