I spent the past year building a unified memory layer for my AI agents using knowledge graphs and ontologies on top of MongoDB. I followed every trend first and made basically every mistake possible.

Naive memory fails once you move past toy examples. File search bloats the context window when memory gets big. This is exactly how Claude Code handles it out of the box.

Semantic search over history still can't traverse the relationships between people, topics, objects, locations, and preferences. Flat search simply can't handle multi-hop traversals across these entities.

So I wanted more to actually scale my knowledge work. I built memory on knowledge graphs and ontologies on MongoDB to make these relationships first-class citizens.

Here are the 5 mistakes I made during the build:

Reached for frameworks. LangGraph and CrewAI broke down at custom ontology constraints, immutable observation logs, composite IDs, and multi-hop traversal. Lesson: own the memory and the system logic yourself because frameworks encode assumptions your production system rarely matches.

Overthought the ontology. I tried to design it perfectly upfront and froze my projects for months. Lesson: it's a data-exploration loop where you start with a POLE+O base (Person, Object, Location, Event, Organization) and extend on collisions, like when "Claude Code" is extracted as a Person instead of an Object.

Confused resolution with deduplication. Naming doesn't equal identity and conflating them silently corrupts the graph, like merging Apple the company with Apple the fruit. Lesson: resolution normalizes names using same-type matching with no merges yet. Deduplication decides identity from full context using thresholds like ≥0.95 for auto-merge, >0.85 for human review, and ≤0.85 for a new node.

Only built short-term and long-term memory. The agent repeated failed strategies and re-planned from scratch. Lesson: add reasoning memory to store a trace per run including strategy, tools, success or failure, and cost. This is like RL at the database layer instead of the weights. Honest caveat: bad traces reinforce bad strategies and it's overkill for one-off tasks.

I tried to build an immutable log layer before materializing the graph into the database because it sounded fancy, as it adds versioning and temporality to the graph. The con is that it puts a ton of pressure on your VM's RAM, which is crazy expensive. Lesson: Do that ONLY if you really need it.

I eventually moved to a single collection, treating edges as first-class documents. This model allows for native $graphLookup and simpler writes without relationship duplication. It is the most practical approach for production.

Have you tried building your own agent memory via knowledge graphs and ontologies? If so, what are your biggest mistakes or takeaways?

TL;DR: Agent memory is a data-modeling problem, not retrieval. Model edges as first-class documents so the graph scales, and add reasoning memory so the agent learns what works.

[留…

为什么值得关注

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

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