LoreKit Proposes Standardized Memory Format for AI Agents

Current AI agent memory is fragmented across at least four distinct formats, ranging from Markdown files like `CLAUDE.md` to JSONL knowledge graphs and hosted repository facts. Because these formats are incompatible, a lesson learned by a CI agent in one tool cannot be accessed by an editor agent in another, creating a siloed experience for developers using multiple AI tools.

The Fragmentation of Agent Memory

As the ecosystem of AI agents grows, developers are building bespoke memory layers with unique schemas and storage methods. These include local files, namespaced stores, and temporal knowledge graphs, but none of these systems can natively communicate with one another.

The author of LoreKit argues that the problem is not a lack of tools, but a lack of a shared agreement. Without a common data model, every new solution adds another isolated format that prevents cross-tool context sharing.

The OpenTelemetry Model

The proposal draws a direct parallel to the observability industry. Before 2019, different vendors shipped proprietary instrumentation libraries and data formats, forcing users to re-instrument code when switching providers.

The industry solved this by merging into OpenTelemetry, which standardized what a span, metric, and log record are, along with shared names (semantic conventions) and a common protocol (OTLP). This allowed a whole ecosystem of tools to read each other's data while still competing on storage and analysis.

The article explains how the proposal draws a direct parallel to the observability industry's move toward OpenTelemetry to solve fragmentation.

Agent memory is currently in a similar state, where the formats are young enough to be standardized before they become entrenched.

Export vs. Live Addressing

The proposal distinguishes between two primary problems: 'export' and 'live addressing.' Export refers to moving a user's memory from one vendor to another, which several existing drafts like the Open Memory Protocol attempt to solve.

Live addressing is the more complex challenge of allowing a CI job, an editor agent, and a review bot to work in the same repository at once. A shared specification would provide a common 'address' (e.g., a specific repo or branch) where these tools can agree on what a memory record means in real-time.

This visual clarifies the two primary problems discussed: moving data between tools versus real-time shared access.

Proposed Architecture and Trade-offs

A proposed record would include a unique ID, a scope (address), a key, a lifecycle (expiry), and a 'written_by' field to identify if a human or an agent created the memory. This structure allows tools to decide how much to trust the information based on its origin.

The article describes the specific fields a proposed record would include to facilitate interoperability.

Critics note that a shared standard might be a 'premature abstraction' or a prompt-injection risk. The proposal suggests mitigating these risks by including signatures and linking records to specific code versions, though it remains an open question which address levels (e.g., repo vs. branch) should be standard.