Agent memory needs a shared standard like OpenTelemetry

The ecosystem for AI agent memory is currently fragmented, with every tool using its own data shape and storage mechanism. Mads Thines argues that this landscape mirrors the chaotic state of software observability before 2019, requiring a unified standard to allow different agents to share context effectively.

What happened

Most development environments today rely on multiple disjointed systems to retain information across sessions. A typical setup might include instruction files like AGENTS.md or CLAUDE.md, agent-managed directories such as /memories, hosted facts from services like GitHub Copilot, and separate knowledge graphs maintained by Model Context Protocol (MCP) servers. These four common approaches cannot read each other’s data, meaning insights gained by a continuous integration agent remain invisible to an editor agent or subsequent tools.

This fragmentation has led to a surge of custom solutions, with developers frequently building their own memory layers to address specific gaps. While each individual format is logically sound, the collective result is a redundant reconstruction of basic concepts: a note stored at an address, valid for a certain duration. The core issue is not a lack of tools, but a lack of community agreement on a shared data model, a problem that the observability sector successfully solved through the creation of OpenTelemetry.

How it works

Before 2019, observability vendors competed by creating proprietary agents, instrumentation libraries, and data formats, making it difficult for users to switch providers. The industry resolved this by merging OpenTracing and OpenCensus into OpenTelemetry, which established four critical layers of agreement. These included a unified data model for spans and metrics, semantic conventions for naming, a single transport protocol called OTLP, and reference implementations like shared SDKs. Vendors then competed on storage and analysis rather than data collection, allowing users to instrument their code once.

Agent memory currently lacks this foundational agreement. A proposed shared specification would mirror the OpenTelemetry approach by defining standard address levels, such as global, project, or repo, and establishing semantic conventions for attributes. It would also define a contract for basic operations like write, read, and search, exposed via MCP, while leaving storage, ranking, and user interface decisions to individual vendors. This separation allows tools to interoperate on data structure while competing on value-added features.

Key details

• Current memory formats include instruction files, agent-managed files, hosted repo facts, context blocks, extracted facts, namespaced stores, and knowledge graphs, none of which are mutually readable.
• OpenTelemetry succeeded by agreeing on a data model, semantic conventions, a protocol, and reference implementations, allowing vendors to compete on data usage rather than collection.
• Existing proposals like Portable Memory, Open Memory Protocol, and COGX focus primarily on exporting data between vendors rather than enabling live, concurrent addressing.
• A proposed memory record structure includes fields for identity, address, key, content type, lifecycle, and attributes, with the actual memory content stored separately.
• The specification should record who wrote the memory, such as a human or an agent, to help readers assess trustworthiness and mitigate prompt injection risks.
• LoreKit offers its schema and on-disk format under an MIT license as a concrete input for developing a shared standard.

Why it matters

For engineers building agentic workflows, the current lack of standardization means that context is siloed within specific tools or vendors. This prevents agents from collaborating effectively, as a lesson learned by one component cannot be utilized by another without manual intervention or complex custom integrations. As the number of agent tools grows, the cost of maintaining these disjointed memory systems increases, leading to redundant development efforts and inconsistent user experiences.

Adopting a shared standard would allow developers to instrument their agents once and have them work seamlessly across different platforms and tools. It would enable a vibrant ecosystem where vendors compete on advanced features like better retrieval algorithms or user interfaces, rather than locking users into proprietary data formats. This shift would reduce vendor lock-in and make it easier for teams to adopt new tools without losing historical context or having to re-engineer their memory infrastructure.

What you can do

• Audit your current development environment to identify all the different places where agent memory is stored and note the incompatibilities between them.
• Review existing proposals like Portable Memory, Open Memory Protocol, and COGX to understand their approaches to data export and serialization.
• Experiment with LoreKit’s offline store by running npx @lorekit/cli install to examine how plain Markdown files can represent structured memory records.
• Compare the memory records generated by your current tools with the proposed structure to identify missing fields or necessary attributes for your use case.
• Engage with the community by sharing feedback on what a shared format would need to support your specific workflow, focusing on live addressing and trust mechanisms.
• Consider contributing to the discussion on neutral grounds, such as the Linux Foundation’s Agentic AI Foundation, to help shape the emerging standards.