10. Open Problems
These gaps have no tooling answer as of May 2026:
Cross-project memory: "What did I learn about connection pooling in project A that applies to project B?" Current solutions scope memory to a single repo or user. ICM gets closest (shared DB across tools) but remains single-user.
Memory versioning: Zep/Graphiti is the only tool with bitemporal modeling. Every other tool's store is a snapshot. The database-backed tools have no Git equivalent for memory, no branches, no merges, no rollback. If a major refactor invalidates a year of accumulated memory, the only recovery path is delete_all_memories. The file-based playbook track (§3.7) is the partial exception: ORF and DiffMem store memory as committed files, so branches, diffs, and rollback come free from Git, and DiffMem uses git blame to answer point-in-time queries. What Git does not give them is semantic merge, which is why consolidation stays an open problem below.
Consolidation and staleness of experience playbooks: The file-based track (§3.7) trades a database for plain files, and inherits two unsolved problems its authors name openly. Overlapping or contradictory playbooks are not merged (Git resolves text conflicts, not "these two lessons say opposite things"). Playbooks go stale silently as the frameworks they describe evolve, with no decay model and no re-validation trigger. A cheap partial fix is a lexical or BM25 pre-filter over playbook frontmatter so near-duplicates surface at write time, but detecting semantic contradiction still needs an LLM pass no tool ships today.
Conflict resolution between agents: When two agents store contradictory memories about the same entity, the implicit policy is last-write-wins. CRDTs, vector clocks, and operational transforms are standard in collaborative editing and absent from every memory system here.
Memory provenance: Which agent wrote this memory? Based on what observation? Linked to which session and tool call? No tool surfaces this. When memory leads to a bad decision, post-mortem analysis is impossible.
Cost attribution per feature: Mem0 reports ~10-15% token overhead per turn. agentmemory reports ~170K tokens/year. These are aggregate figures. No tool provides a per-feature cost breakdown. Teams cannot answer "is the memory layer worth its token cost on this project?"
Schema migration: codebase-memory-mcp depends on tree-sitter parsers across 155 languages; ICM Memoirs use user-defined typed relations. Neither tool documents what happens when a relation type is renamed or a parser updates its AST output.
The core diagnosis: the industry is treating memory as a storage problem when it is a coordination problem. Storage is largely solved: SQLite-vec, pgvector, Neo4j, and Cloudflare D1 all work at the required scale. The unsolved problems are concurrent writes, conflict resolution, causal consistency, prompt-injection-resistant writes, and auditable provenance. The tools winning today won because they solved lifecycle integration via hooks. The tools that win next will solve coordination.
Sources:
- Internal research document:
claudedocs/research/memory-management-multi-sessions-2026.md(May 2026, with Perplexity deep search and GitHub analysis)- claude-mem GitHub
- agentmemory GitHub
- ICM GitHub + ICM README
- doobidoo/mcp-memory-service GitHub
- Zep/Graphiti GitHub
- mem0ai/mem0 GitHub
- OpenMemory MCP (subproject path removed, mem0ai/openmemory now hosts an unrelated CLI tool)
- Sleep-time Compute paper (arXiv:2504.13171, UC Berkeley + Letta, April 2025)
- CLAUDE.md impact study (Gloaguen et al., arXiv 2602.11988, Feb 2026)
- Auto Dream system prompts
- ORF blog post (Guillaume Laforge, July 2026)
- ReasoningBank (Google, arXiv 2509.25140, "Scaling Agent Self-Evolving with Reasoning Memory")
- DiffMem GitHub
- Claude Code release notes: v2.1.33, v2.1.59, v2.1.63, v2.1.83+