AI agent memory looks for a common standard inspired by OpenTelemetry

The inventory every dev team already has without noticing

Open the repository of a team that uses AI agents to code and you'll likely find an AGENTS.md or CLAUDE.md, maybe rules in .cursor/rules/*.mdc, an agent writing files to a /memories folder via Anthropic's memory tool, GitHub Copilot storing facts about that repo server-side, and an MCP memory server maintaining a knowledge graph in JSONL. A post on the LoreKit blog adds this up and arrives at four different formats running at the same time, and none of them reads the other.

In practice, this means a lesson the CI agent learned stays trapped with whoever wrote it. The code editor's agent can't see it, and neither will the next tool the team tries. The post's author, who builds LoreKit itself (one of the candidate formats) and also works on observability at Dash0, argues the problem isn't a lack of tools: it's a lack of agreement. He lists a steady wave of posts in communities like r/ClaudeAI and r/LocalLLaMA from people building their own memory layer, each with its own schema and MCP tools, proving the problem is real and growing.

The precedent: before 2019, every observability vendor had its own agent

The comparison underpinning the article is direct. Before 2019, every observability vendor shipped its own instrumentation agent, its own library, and its own data format: switching vendors meant reinstrumenting the entire codebase. Two open projects, OpenTracing and OpenCensus, tried to solve this and competed with each other.

In 2019 they merged into OpenTelemetry, and what got agreed on were four layers: a data model (what a span, a metric, a log record is), semantic conventions (names like service.name and http.*), a single protocol (OTLP), and shared reference implementations (SDKs and the Collector). Vendors kept competing on what they do with the data once it arrives: storage, querying, analysis.

The post's central argument is that agent memory is exactly where observability was before 2019: lots of implementation, nothing agreed underneath. And the timing would help, because the formats are still young enough to change, and a neutral home already exists: both MCP and AGENTS.md live under the Agentic AI Foundation, part of the Linux Foundation.

The map of today's formats

The post puts together an overview (which the author himself flags as a snapshot from late 2026, subject to fast change) of how each family answers the same four questions: where the memory is true, what its identity is, what it says, and when it stops being valid.

Some of these choices got right something a standard should preserve: Copilot Memory combines citations verifiable against the code with forgetting by default, but stays locked into a single product. LangGraph shows how the core can be small, summed up in put(namespace, key, value). Graphiti models the time a fact was true, with separate timelines for when a fact was true and when it was recorded. And AGENTS.md proves that a simple file at a known path can already become a de facto standard.

What proposals already exist, and what they're missing

The post lists three ongoing initiatives. Portable Memory, from MacPaw Research, is a .mem package with byte-for-byte reproducible serialization, deletion tombstones, and optional signing, but the authors themselves admit it still lacks broad adoption. The Open Memory Protocol is an April 2026 draft for moving conversations and the memories derived from them between platforms, like a ZIP with a manifest. The COGX format, from Cognee, bridges imports between Mem0, Letta, and Zep.

These three mostly solve export: taking a person's memory out of vendor A and moving it to vendor B. But coding tools have a second problem, more specific to engineering: live addressing. When a CI job, an editor agent, and a review bot work on the same repository at the same time, how do they read and write to the same place and agree on what it means? A complete standard would need to cover both cases, and today's proposals only cover the first.

What a standard record would look like, in practice

The post proposes (making clear that the field names are illustrative, not a closed proposal) a record format with a frontmatter envelope and the memory's content in Markdown right below:

---
spec: agent-memory/0.1
id: 8f0c2a6e-4b1d-4c7a-9e2f-3a5b6c7d8e9f
address: { level: repo, value: github.com/acme/checkout }
key: tests-need-local-postgres
kind: lesson
written_by: { type: agent, name: claude-code }
content_type: text/markdown
lifecycle: { expires_at: null, extended_by: write }
attributes: { vcs.pr: 482, ci.run_url: "https://ci.example/runs/123" }
---
Integration tests fail with `ECONNREFUSED 127.0.0.1:5432` unless Postgres
is already running. Start it before `pnpm test`:

 docker compose up -d db

The address field and the key say where that's true, id gives the record identity, lifecycle says when it expires, and written_by answers the question that, according to the post, is the only real branching point among existing formats: who writes the memory. In instruction files it's a person; in the memory tool, in Letta, and in LoreKit it's the model itself; in Mem0 and Graphiti it's a service that extracts facts from the conversation. A standard doesn't need to pick a single owner, it just needs to record which one it was, so whoever reads it knows how much to trust it.

Around this record, the post mirrors OpenTelemetry's same four layers: conventions (shared names for address levels like global, project, repo, branch, and attribute namespaces like vcs.*, ci.*, agent.*), a contract (fixed operations for writing, reading, listing, searching, and archiving, exposed via MCP), and conformance tests in place of a single reference implementation, checking whether a round-trip of the record preserves everything and whether unknown attributes survive a rewrite.

The objections, answered in the post itself

The author anticipates four criticisms. To the first, that anyone building a memory tool only wants a standard shaped like their own tool, he responds that this is why LoreKit appears as just one more row in the table, not as the model to follow. To the second, that MCP would already be the standard, he distinguishes that MCP standardizes the call, not the record: just as observability needed both a protocol and a data model, memory needs both too.

To the third, that shared memory becomes a prompt injection channel, the response is to agree: anything an agent reads can steer it, and sharing memory widens who can write to it. That's why a standard should make this visible, recording who wrote each memory, allowing signatures (Portable Memory already does this), and letting a record point to the code it depends on. To the fourth objection, the strongest according to the author himself, that yet another standard would only worsen fragmentation (the classic xkcd 927), the response points to OpenTelemetry itself: the agreement came when existing projects merged, not when someone launched one more.

What remains open, and what changes for those building with agents today

The post leaves four questions without a closed answer: which address levels make sense (monorepos call for something between repo and branch), whether forgetting should be the default, whether a record should point to the code it depends on, and who would coordinate this work (a working group, a foundation, or a draft open to contributions).

For those who already have a CI agent, a review bot, and a code assistant running on the same repository, the practical takeaway is simple: today, each of these probably stores memory in a different place, and switching tools means losing what was learned. There's no standard to adopt yet, but you can already map how many of these four formats coexist in your own setup, and demand interoperability from the vendors you use. Anyone who wants to see one of these formats in practice can run npx @lorekit/cli install, which writes records as plain Markdown, readable with grep and diff, and compare that with what the other tools in your stack already write.