Developer Urges AI Coding Tools to Adopt a Shared Memory Format

Why don't AI coding tools share memory?

Every AI coding tool seems to have its own way of remembering things. One stores notes in a Markdown file at the root of a repository. Another writes to a designated memories folder. A third keeps facts about each project on its host's servers. None of them can read what the others wrote, and a lesson learned by a continuous integration agent usually stays with that agent.

That fragmentation is the core problem a developer lays out in a recent essay, and his answer is a shared standard. He builds LoreKit, an open-source memory tool, and says his proposal is not a pitch for that product. The point, he writes, is that the field has reached the moment to agree on a common format, and that another technology sector has already shown how.

He counts four rough families of memory formats on a typical developer machine: instruction files such as AGENTS.md and CLAUDE.md, agent-managed files like Anthropic's memory tool, hosted repository facts from GitHub Copilot, and memory servers that keep a JSONL knowledge graph. Each is reasonable alone. Together, he argues, they keep rebuilding the same idea, a note an agent leaves for its future self, stored at some address and assumed to remain true for a while.

The writer points to the volume of independent projects as evidence the need is real. Posts in developer communities regularly describe a new memory layer built for a specific agent, each with its own storage, schema and tool interface. Every new entry, however, adds another format that nothing else can read.

How observability got its common language

Could AI agent memory follow the OpenTelemetry model?

The essay compares this to the observability industry before 2019. Each vendor shipped its own agent, instrumentation library and data format, so switching providers meant instrumenting code again. Two open projects, OpenTracing and OpenCensus, tried to address this and competed with each other. In 2019 they merged into OpenTelemetry.

According to the writer, the key was agreement on what companies would stop competing over. That included a shared data model, defining what a span, metric and log record are; semantic conventions with common names; a single transmission protocol; and reference implementations such as shared software development kits and a collector. Vendors kept competing on storage, querying and analysis. Users instrument their code once. The writer, who works with OpenTelemetry daily at Dash0, says that agreement is why many tools can read each other's data.

He argues agent memory is at a similar point. The formats are young enough to change, and there is already a neutral venue for agent standards. The Model Context Protocol and AGENTS.md both sit under the Linux Foundation's Agentic AI Foundation.

What a shared specification could cover

What would a shared AI memory format include?

The essay sketches a record format built around a few fields: where a memory applies, a unique identifier, a key, the kind of memory, who wrote it, how it should be read, when it expires and any extra attributes a tool needs. It emphasizes that the example is an illustration of the data model, not a formal proposal for field names.

Around that record, the writer proposes three layers that mirror OpenTelemetry. The first is shared conventions, including standard address levels, memory kinds and attribute namespaces kept in a versioned registry. The second is a small contract of operations, such as write, read, list, search and archive, exposed over the Model Context Protocol. Many memory servers already offer an interface of that kind, he notes, but each exposes different tools with different meanings. The third is conformance tests in place of a reference implementation, checking whether a record survives a round trip, whether unknown attributes survive a rewrite and whether expiry works as described.

Storage, ranking, embeddings and user interfaces would stay out of scope. The writer says those are where tools should compete. He also argues the specification should live in a neutral home rather than in his project's repository or any single vendor's.

The essay acknowledges one structural question that a standard would need to settle: who writes a memory. In some systems a person does, in others the model does, and in some a service extracts facts from conversations. The writer suggests a standard should not choose one approach but should record which applies, so readers know how much to trust what they read.

Open questions and objections

The writer addresses several objections. He concedes that a tool builder would naturally favor a standard shaped like his own, and says LoreKit should adopt a different shared design if one emerges. He argues that the Model Context Protocol standardizes the call but not the record. On security, he acknowledges that shared memory can be a channel for prompt injection and says a spec should make the writer of each memory visible, allow signatures and let records point to the code they depend on.

He lists four questions he says he cannot yet answer. They include which address levels a standard should define, whether forgetting should be the default, whether a record should link to the code it depends on, and who should coordinate the work, whether a working group, a foundation or a draft that people submit changes to.

He invites builders of the tools he compares, and authors of existing proposals, to compare notes. The essay notes that LoreKit's schema and on-disk format are available under an MIT license as one concrete input.

This article was written with the assistance of AI.
News Factory APP - agentic news to boost your SEO & AEO.