Agent memory has nine formats and none can read the others
Your CLAUDE.md, Copilot Memory, Mem0 and a LangGraph store all remember things about the same repo, and none of them can read each other. That is the starting point of "Agent memory needs its OpenTelemetry moment", a Nov 7 essay from LoreKit that hit 159 points and 90 comments on Hacker News on Sunday.
The author builds LoreKit, an open-source memory tool, works on OpenTelemetry at Dash0, and says both up front. The argument borrows from observability. Before 2019 every vendor had its own agent and data format. OpenTelemetry fixed that by getting vendors to agree on four things: a data model, shared naming conventions, a protocol, and reference implementations. Then they kept competing on storage and analysis. Agent memory, the essay says, is where observability was before 2019.
The survey is the useful part. Nine families, from instruction files (a person edits them, never forgotten) to Copilot Memory (facts with code citations, deleted after 28 days unused) to Graphiti's temporal graph (facts invalidated, not deleted, on two timelines). They all answer the same four questions differently: where a memory is true, what its identity is, what it says, and when it stops being true. The one real split is who writes it: a person, the model, or a service extracting facts. The proposal doesn't pick one; it records which, so a reader knows how much to trust it.
The essay also separates two problems. Export (moving your memory from vendor A to B) already has drafts like MacPaw's Portable Memory and the Open Memory Protocol. Live addressing (a CI job, an editor agent and a review bot writing the same repo memory at once) has nothing. That second one is what teams running several agents hit first.
A Friday paper makes the same point from the research side. EvoMemState (arXiv 2611.03743, 33 upvotes on Hugging Face) argues that storing memories as independent facts misses how new facts update or conflict with old ones, and adds relational states for validity and scope. Different words, same field: "when does this stop being true" is the hard part of memory.
Sources: https://www.lorekit.io/blog/open-agent-memory-format and https://arxiv.org/abs/2611.03743
← Back to all articles
The author builds LoreKit, an open-source memory tool, works on OpenTelemetry at Dash0, and says both up front. The argument borrows from observability. Before 2019 every vendor had its own agent and data format. OpenTelemetry fixed that by getting vendors to agree on four things: a data model, shared naming conventions, a protocol, and reference implementations. Then they kept competing on storage and analysis. Agent memory, the essay says, is where observability was before 2019.
The survey is the useful part. Nine families, from instruction files (a person edits them, never forgotten) to Copilot Memory (facts with code citations, deleted after 28 days unused) to Graphiti's temporal graph (facts invalidated, not deleted, on two timelines). They all answer the same four questions differently: where a memory is true, what its identity is, what it says, and when it stops being true. The one real split is who writes it: a person, the model, or a service extracting facts. The proposal doesn't pick one; it records which, so a reader knows how much to trust it.
The essay also separates two problems. Export (moving your memory from vendor A to B) already has drafts like MacPaw's Portable Memory and the Open Memory Protocol. Live addressing (a CI job, an editor agent and a review bot writing the same repo memory at once) has nothing. That second one is what teams running several agents hit first.
A Friday paper makes the same point from the research side. EvoMemState (arXiv 2611.03743, 33 upvotes on Hugging Face) argues that storing memories as independent facts misses how new facts update or conflict with old ones, and adds relational states for validity and scope. Different words, same field: "when does this stop being true" is the hard part of memory.
Sources: https://www.lorekit.io/blog/open-agent-memory-format and https://arxiv.org/abs/2611.03743
Comments