If you're building AI agents, you've probably hit the wall where naive file-based memory stops scaling. Context windows blow up, semantic search can't traverse relationships between people, topics, and preferences, and suddenly your agent is repeating mistakes it made months ago. One developer just published a year-long retrospective on building a unified memory layer using knowledge graphs and ontologies on top of MongoDB—and the takeaways are brutal but valuable for anyone going down this path.
Mistake 1: Framework First, Architecture Later
The author started with LangGraph and CrewAI because they were trending. The honeymoon lasted until custom ontology constraints, immutable observation logs, composite IDs, and multi-hop traversal became requirements. Then came the fight against framework assumptions that never matched the system's actual needs. The lesson here cuts deep: own your memory layer and harness yourself. Frameworks encode opinions about how systems should work—and those opinions rarely survive contact with production complexity.
Mistake 2: Designing the Perfect Ontology Upfront
Treating knowledge graph development as a data-modeling problem is correct, but treating it as something you can solve in one shot upfront is where projects freeze for months. The author's solution came from hard experience: start with POLE+O (Person / Object / Location / Event / Organization) and extend only on collisions. A real example from their work: Claude Code got tagged as a Person when it's clearly an Object, creating messy graph relationships that cascaded through the system.
Mistake 3: Confusing Resolution With Deduplication
This one sounds academic until it corrupts your entire graph. Naming is not identity—confusing these two concepts breaks everything. Resolution normalizes names (turning "Apple Inc." and "APPLE" into a canonical form), while deduplication determines actual entity identity from context. The author settled on specific thresholds that actually work: ≥0.95 similarity triggers auto-merge, >0.85 goes to human review, and ≤0.85 creates a new node entirely. This prevents "Apple" the company from merging with "Apple" the fruit—a problem that sounds trivial until it tanks your product recommendations.
Mistake 4: Skipping Reasoning Memory
The system only had short-term and long-term memory implemented. The result? Agents repeatedly executed failed strategies because nothing captured what didn't work. Reasoning memory is a trace per run, including strategy decisions, tools used, and outcomes—essentially reinforcement learning at the database layer instead of in model weights. The author admits this can backfire (bad traces reinforce bad patterns) and it's overkill for one-off tasks, but for persistent agents? It's non-negotiable.
Mistake 5: Premature Immutable Log Optimization
The shiny-object temptation hit hard here: building an immutable log layer with versioning and temporality before the graph was even materialized into the database. It sounded sophisticated until the RAM pressure from a ton of in-memory operations crashed VMs. The lesson is brutal simplicity: materialize your graph first, add immutability only when you actually need it.
Key Takeaways
- Treat agent memory as a data-modeling problem, not just retrieval—relationships are first-class citizens
- Start with POLE+O ontology and extend on collisions; perfect upfront design is a trap
- Separate name resolution from entity deduplication; use explicit thresholds (≥0.95 auto-merge, >0.85 review, ≤0.85 new node)
- Add reasoning memory for persistent agents to avoid repeating failed strategies
- Materialize your graph before optimizing—RAM bills will humble you fast
The Bottom Line
This dev did it the hard way so you don't have to. The knowledge graph path for agent memory is real and powerful, but it's architecturally intensive—you're essentially building a database layer that happens to run LLM inference alongside it. Skip the frameworks, skip the upfront ontology perfectionism, and get something working first. The lessons are free; the mistakes cost a year.