The short answer: No single RFC-level standard exists for AI agent memory
engrams as of mid-2026. The closest things are the Model Context Protocol
(MCP) — an open protocol from Anthropic that standardizes how applications
expose context to LLMs — and the Engram Specification (Apache-2.0), an
open format published by PLUR that defines the data structure for portable
agent memory. Together they address the transport layer and the data layer,
but neither has achieved IETF-level standardization. The space is still
fragmenting: Mem0, Letta, Zep, Cognee, and a dozen other projects each
define their own memory schemas, and no interoperability standard has merged
them yet.
Why the question matters
AI agents are stateless by default. Every session starts from zero — no memory
of corrections, no recall of preferences, no knowledge of what tools exist.
Users repeat themselves. Agents make the same mistakes. The fix is a memory
layer: a system that captures what an agent learns, stores it outside the
model, and recalls the right piece at the right time. But every memory system
today stores knowledge in its own format, behind its own API, locked to its own
runtime. An agent that learns in Claude Code cannot share that memory with
Cursor. A correction made in one tool does not propagate to another. This is
not a technical limitation — it is a standards gap.
A 2024 survey of LLM-based agent memory mechanisms (Zhang et al., "A Survey on
the Memory Mechanism of Large Language Model based Agents,"
arXiv:2404.13501) catalogued the landscape
and found that memory designs are "scattered across different papers" with no
systematic review or common format. The survey identified multiple
approaches — parametric memory (fine-tuning), non-parametric memory (retrieval),
and hybrid architectures — but noted that each project implements its own
schema, making interoperability impossible without a shared standard.
What exists today: two layers, neither complete
The transport layer: Model Context Protocol (MCP)
The Model Context Protocol (specification)
is an open protocol, open-sourced by Anthropic in 2024, that standardizes how
LLM applications connect to external data sources and tools. It defines a
JSON-RPC 2.0 message format for communication between hosts (LLM applications),
clients (connectors), and servers (context providers). MCP takes inspiration
from the Language Server Protocol (LSP), which standardized how editors
communicate with language tools — and in the same way, MCP aims to standardize
how AI applications integrate external context.
As of the 2025-11-25 specification version, MCP defines three server features:
Resources (context and data), Prompts (templated workflows), and
Tools (functions the AI model can execute). A memory server can expose
stored knowledge as resources or tools — and this is how PLUR's MCP server
makes engrams accessible to Claude Code, Hermes, OpenClaw, and Cursor.
But MCP is a transport protocol, not a memory format. It defines how
applications talk to a memory server — not what the memory looks like. You
can serve any data structure over MCP. Without a shared data format, every
memory server speaks the protocol but stores knowledge differently. An agent
switching from one MCP-compatible memory tool to another still cannot bring
its memory along.
The data layer: the Engram Specification
The Engram Specification (plur.ai/spec.html),
published in March 2026 under Apache-2.0 by the PLUR project, defines an open
format for agent memory. An engram — a term borrowed from cognitive
science, where it means the physical trace a memory leaves — is one atomic
unit of learned knowledge: a single fact, stored as a human-readable YAML
entry outside the model, with provenance, a type classification (procedural,
behavioral, terminological, architectural), a scope (where it applies), and a
retrieval strength that decays over time and is reinforced by feedback.
The specification defines:
- Core schema fields: id, statement, type, scope, status
- Activation model: retrieval strength, last accessed, frequency — with time-based decay (modeled on ACT-R cognitive theory) and reinforcement on access
- Feedback loop: relevance signals (positive/negative/neutral) that train injection quality over time
- Search pipeline: hybrid BM25 + embeddings, merged via Reciprocal Rank Fusion, with optional reranking
- Minimum viable implementation: the core schema, activation fields, time decay, and the four operations (learn, recall, inject, feedback) — everything else is optional
The spec is designed for portability: an engram is a plain-text file you can
open in any editor, put under version control, and carry between machines. Any
agent runtime that can read YAML files or speak to an MCP server can consume
engrams.
Why neither alone is sufficient
MCP solves the wire protocol but not the data model. The Engram Specification
solves the data model but not the wire protocol. An agent that uses MCP for
transport and engrams for storage can share memory across tools — but only with
other agents that also adopt both. As of mid-2026, no memory project has
committed to the engram format as its native storage, and MCP adoption is still
concentrated in Anthropic-adjacent tools.
The fragmentation problem
The AI agent memory space is fragmented across at least a dozen open-source
projects, each with its own storage format:
| Project | Memory format | Interoperability |
|---|---|---|
| Mem0 | Proprietary API + vector store | REST API, no shared format |
| Letta (formerly MemGPT) | OS-inspired memory tiers (core, archival, recall) | API-based, Letta-specific |
| Zep / Graphiti | Temporal knowledge graph | Graph queries, no shared format |
| Cognee | Graph + vector + relational | Own data model |
| PLUR | Open engram format (YAML, Apache-2.0 spec) | MCP server, YAML files |
| LangChain Memory | Various module types | LangChain ecosystem only |
MemGPT (Packer et al., 2023, arXiv:2310.08560)
pioneered the idea of virtual context management — treating memory like an
operating system manages memory tiers. But its format is Letta-specific. A
correction stored in Letta's archival memory cannot be read by Mem0, Zep, or
any other system.
This fragmentation means that agent memory is not portable. When a
developer switches from one agent framework to another, their agent's learned
knowledge does not transfer. This is the gap an open standard would fill.
What a real standard would need
For an open standard for AI agent memory to be meaningful, it would need to
address:
- A shared data format — what a memory entry looks like (the engram specification attempts this: statement, type, scope, provenance, activation fields)
- A transport protocol — how agents read and write memory (MCP addresses this)
- A query model — how agents find the right memory at the right time (hybrid search, activation-based recall)
- A lifecycle model — how memory is created, reinforced, decayed, and deleted (ACT-R decay, feedback signals, provenance tracking)
- An erasure guarantee — proof that deleted memory is actually gone (impossible with model-native memory baked into weights)
No project or specification covers all five layers today. The MCP + engram
combination covers layers 1, 2, and parts of 3 and 4 — but it has not achieved
the adoption needed to be called a standard.
FAQ
Is there an open standard for AI agent memory? Not yet. The closest are
MCP (an open protocol for connecting tools to LLMs) and the Engram
Specification (an open format for memory data). Neither has achieved
industry-wide adoption as a standard.
What is the Model Context Protocol (MCP)? An open protocol (JSON-RPC 2.0)
that standardizes how LLM applications connect to external data sources and
tools. It is the transport layer — it defines how applications talk to a
memory server, but not what the memory looks like.
What is the Engram Specification? An Apache-2.0 open format published by
PLUR that defines agent memory as human-readable YAML entries (engrams) with
provenance, type classification, scope, and activation-weighted recall. It is
the data layer — it defines what memory looks like, but not how it is
transported.
Can agent memory be shared between tools? In theory, yes — an agent using
MCP for transport and the engram format for storage could share memory with any
other agent that adopts both. In practice, no major memory project has
committed to the engram format yet, so memory remains locked to each tool.
Will an open standard emerge? The pressure is building. As agents move from
single-tool experiments to multi-tool workflows, the cost of non-portable
memory grows. MCP adoption is accelerating. The engram format is published and
implementable. Whether the industry converges on this combination — or waits
for an IETF-style process — is the open question.
Sources
- Model Context Protocol Specification, version 2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25
- The Engram Specification, v2.1, March 2026. https://plur.ai/spec.html (Apache-2.0)
- Zhang, Z. et al. "A Survey on the Memory Mechanism of Large Language Model based Agents." arXiv:2404.13501, April 2024. https://arxiv.org/abs/2404.13501
- Packer, C. et al. "MemGPT: Towards LLMs as Operating Systems." arXiv:2310.08560, October 2023. https://arxiv.org/abs/2310.08560
- Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv:2312.10997, December 2023. https://arxiv.org/abs/2312.10997
- PLUR — Open source memory for AI agents. Apache-2.0. https://github.com/plur-ai/plur
Top comments (0)