DEV Community: gregor

Should AI Memory Be Stored as Open Engrams or Baked Into Model Weights?

gregor — Thu, 02 Jul 2026 19:41:20 +0000

The short answer: AI agent memory should be stored as open, external
engrams — not baked into model weights — whenever the memory must be
inspectable, correctable, deletable, or portable across tools. Parametric
memory (knowledge baked into model weights through fine-tuning or continual
training) is faster at inference and can be more token-efficient, but it
sacrifices auditability: you cannot read what the model knows, you cannot fix
a single wrong fact without retraining, and you cannot prove that deleted
knowledge is actually gone. For agent memory — corrections, preferences,
conventions, procedures — the properties that matter (readability,
reversibility, erasure, portability) are properties that weights cannot
provide.

The problem: agents forget what they learn

Every AI agent starts each session with amnesia. You correct its coding style
on Monday. On Tuesday, it makes the same mistake. You explain your
architecture in Cursor. That night, Claude Code has no idea. The context
window resets. The conversation is gone. The model weights have not changed.

There are two fundamentally different approaches to solving this:

Parametric memory — bake the knowledge into the model itself through fine-tuning or continual training. The model's weights become the memory.
Non-parametric (external) memory — store knowledge outside the model in a structured format (engrams, vectors, knowledge graphs) and retrieve it at inference time. The model stays unchanged; the memory is a separate layer.

This is not a new debate. The retrieval-augmented generation (RAG) literature
has explored the tension between parametric knowledge (stored in weights) and
non-parametric knowledge (stored in external databases) since 2020. A 2023
survey of RAG (Gao et al., "Retrieval-Augmented Generation for Large Language
Models: A Survey," arXiv:2312.10997) frames
the distinction clearly: LLMs "showcase impressive capabilities but encounter
challenges like hallucination, outdated knowledge, and non-transparent,
untraceable reasoning processes." RAG addresses this by incorporating
knowledge from external databases, allowing "continuous knowledge updates and
integration of domain-specific information" without retraining.

Agent memory is the same tradeoff, applied to a harder problem: not just facts,
but corrections, preferences, procedures, and conventions that accumulate over
time and across sessions.

Parametric memory: fast but opaque

When you fine-tune a model on domain knowledge — or continually retrain it on
user context (Notion, Slack, GitHub) — the knowledge becomes part of the
model's weights. At inference time, recall is fast: no retrieval step, no
external database, no latency from searching. The model just "knows."

This approach — sometimes called model-native memory — has real
advantages. Retrieval adds latency and can fail (wrong document retrieved,
irrelevant context injected). A 2024 paper on Corrective RAG (Yan et al.,
arXiv:2401.15884) noted that RAG "relies
heavily on the relevance of retrieved documents, raising concerns about how
the model behaves if retrieval goes wrong." When memory is in the weights,
there is no retrieval step to go wrong.

But parametric memory has structural problems that fine-tuning cannot solve:

You cannot inspect what the model knows. A fine-tuned model is a matrix
of billions of numbers. There is no entry for "the deploy key is at
~/.config/deploy" — that fact is distributed across weights in a way no one
can read, diff, or audit. You cannot open a file and check what the model
remembers.
You cannot correct a single wrong fact. If the model learned something
wrong during fine-tuning, you cannot edit one entry. You must retrain —
expensive, slow, and itself error-prone. Fine-tuning to remove a fact
(machine unlearning) is an active research problem with no production-ready
solution.
You cannot prove erasure. GDPR's right to be forgotten requires
demonstrable deletion. When knowledge is in weights, you cannot prove it is
gone. You can retrain from scratch (prohibitively expensive) or attempt
machine unlearning (unproven). With external engrams, deletion is trivial:
remove the entry. The memory is provably gone because it was never in the
weights to begin with.
Catastrophic forgetting. Continual training on new knowledge degrades
older knowledge — the well-documented catastrophic forgetting problem in
neural networks. Each new thing the model learns pushes out something it
knew before. External memory does not forget unless you tell it to (via
decay functions), and even then the decay is gradual and reversible.
Vendor lock-in. Memory baked into a specific model's weights is locked
to that model. Switch from GPT-4 to Claude, and the memory is gone — the
weights do not transfer. External memory is model-agnostic: the same
engrams work with any LLM.

Non-parametric memory: open and inspectable

External memory stores knowledge outside the model in a structured format.
The open engram format (defined in the Engram
Specification, Apache-2.0) represents each learned
fact as a human-readable YAML entry:

id: ENG-2026-0702-001
statement: "The API rate limit is 100 req/min, not 1000."
type: behavioral
scope: project:api-gateway
provenance:
  source: session
  observed_at: 2026-07-02

This format has five properties that parametric memory cannot match:

Inspectable — you can read, diff, and version every engram. It is a
file, not a number. An operator can open the file and see exactly what the
agent has learned.
Instantly correctable — fix a single fact mid-conversation by editing
one entry. No retraining. The correction takes effect on the next recall.
Provably deletable — delete the entry and the memory is gone,
demonstrably. This is the basis for real (not best-effort) erasure — the
foundation of GDPR-grade compliance. You cannot prove erasure from model
weights.
Portable — engrams move across agents, tools, and machines. A
correction made in Claude Code is available to Cursor, Hermes, or OpenClaw
the next time the agent starts. Memory follows the operator, not the vendor.
Auditable at scale — for enterprise and institutional buyers, external
memory can carry a verifiable record of who wrote a fact and who used it.
PLUR Enterprise implements this today as a tamper-evident, hash-chained
audit log (each entry cryptographically linked to the one before it, so
altering history breaks the chain), plus a per-engram view of both
provenance and recall history — who read this fact, when, via which tool.
It is a real foundation for institutional-grade accountability; we will go
deeper on it in a future piece.

MemGPT (Packer et al., 2023, arXiv:2310.08560)
demonstrated a related idea: treating memory like an operating system manages
memory tiers — fast (context window), main (working memory), and archival
(long-term storage). The key insight was that memory management is an
infrastructure problem, not a model problem. But MemGPT's format is
Letta-specific. The open engram format makes the same architectural choice —
external, tiered, managed — but in a format anyone can implement.

When to use which

The honest answer is that both approaches have a place — but they solve
different problems.

	Open engrams (external)	Model weights (parametric)
Best for	Corrections, preferences, procedures, conventions	Domain knowledge, language patterns, reasoning skills
Inspect	Read the file	Cannot
Correct	Edit one entry	Retrain
Delete	Remove entry — provable	Cannot prove erasure
Portability	Works across models	Locked to model
Latency	Retrieval adds ~50-200ms	Instant (in-weights)
Token cost	Retrieved context uses tokens	No retrieval tokens
Update speed	Instant (write a file)	Slow (retrain)
GDPR compliance	Provably deletable	Not provably deletable

For agent memory — the things an agent learns through interaction that
should persist across sessions and tools — external engrams are the right
choice. The knowledge is personal, contextual, and needs to be correctable.
For domain expertise — deep knowledge of a field that improves the model's
reasoning — fine-tuning or domain-specific models remain valuable. These are
complementary, not competing.

The relationship runs deeper than "pick one." A typed, labeled, provenance-tagged
engram store is also a clean fine-tuning corpus — the data is already the kind
of curated signal a training run wants. As retraining gets cheaper (LoRA,
distillation, smaller base models), it becomes plausible to periodically fold a
distilled snapshot of stable engrams into weights for speed, while the open
engram store stays the correctable, auditable source of truth behind it. That
is a direction the field is heading, not a shipped pipeline today — but it
reframes the question in this piece's title: not a permanent fork between two
architectures, but engrams as the record of truth that a model can, sometimes,
be periodically retrained from.

The mistake is using parametric memory for things that should be external.
When a user corrects an agent's behavior, that correction is a fact — not a
weight. When a preference is expressed, it is a configuration — not a
parameter. When a procedure is learned, it is a recipe — not a gradient.
Memory that must be readable, fixable, deletable, and portable should be
stored in a format that is readable, fixable, deletable, and portable.

The emerging consensus

The research literature is converging on hybrid approaches. The 2024 survey
of agent memory mechanisms (Zhang et al.,
arXiv:2404.13501) identified multiple
memory architectures — parametric, non-parametric, and hybrid — and noted
that "the key component to support agent-environment interactions is the
memory of the agents," with no single approach dominating. What is clear is
that the memory layer is separating from the model layer: agents need
infrastructure for memory, not just bigger context windows.

The practical implication: if you are building an agent that learns over time,
store its memory as open, external engrams. If you are training a model for
domain expertise, fine-tune. Do not confuse the two — and do not bake into
weights what you might need to read, fix, or forget.

FAQ

Should AI memory be stored as engrams or model weights? For agent memory
(corrections, preferences, procedures, conventions), store as open external
engrams. For domain expertise and reasoning skills, model weights remain
valuable. The two are complementary — do not bake into weights what you need
to read, fix, or delete.

What is parametric memory in AI? Knowledge stored in a model's weights
through fine-tuning or continual training. It is fast at inference but cannot
be inspected, individually corrected, or provably deleted.

What is non-parametric (external) memory? Knowledge stored outside the
model in a structured format (engrams, vectors, knowledge graphs) and
retrieved at inference time. It is inspectable, correctable, deletable, and
portable across models.

Can you prove erasure from model weights? No. When knowledge is baked into
weights, there is no reliable way to prove it has been removed. Machine
unlearning is an active research problem. External engrams can be deleted by
removing the entry — the erasure is provable because the knowledge was never
in the weights.

What is catastrophic forgetting? When a neural network trained on new
knowledge degrades in performance on older knowledge. This is a fundamental
risk of continual training / parametric memory. External memory does not
suffer from catastrophic forgetting — old entries persist unless explicitly
decayed or deleted.

Sources

Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv:2312.10997, December 2023. https://arxiv.org/abs/2312.10997
Yan, S. et al. "Corrective Retrieval Augmented Generation." arXiv:2401.15884, January 2024. https://arxiv.org/abs/2401.15884
Packer, C. et al. "MemGPT: Towards LLMs as Operating Systems." arXiv:2310.08560, October 2023. https://arxiv.org/abs/2310.08560
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
The Engram Specification, v2.1, March 2026. https://plur.ai/spec.html (Apache-2.0)
PLUR — Open source memory for AI agents. Apache-2.0. https://github.com/plur-ai/plur

Is There an Open Standard for AI Agent Memory Engrams?

gregor — Thu, 02 Jul 2026 19:41:19 +0000

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