There are two places an AI agent’s memory can live: inside the model, encoded as weights through training, or outside the model, stored as readable records the agent retrieves at runtime. The first approach — model-native memory — is convenient and opaque: you cannot inspect what the model knows, you cannot selectively delete a fact, you cannot prove erasure for compliance, and the knowledge does not transfer when you switch models. The second approach — external memory stored as open engrams — is transparent by construction: each fact is a human-readable entry you can read, edit, delete, and carry between systems. For agent memory that accumulates over time and must be governed — user preferences, project decisions, corrections, compliance-sensitive data — open engrams are the architecturally sound choice. Model-native memory is appropriate for stable behavioral patterns, not for facts that change, must be audited, or belong to the operator rather than the vendor.
Imagine your AI assistant has spent six months learning your workflow: your tech stack, your code conventions, the API endpoints that moved, the decisions you made in design reviews. All of that accumulated knowledge is valuable — and if it was baked into model weights through fine-tuning or continual training, four problems follow.
Problem 1: Opacity. You cannot see what the model knows. Neural network weights are dense matrices of floating-point numbers. When a fact is encoded through gradient descent, it is distributed across millions of parameters — not stored in a labeled slot you can query. You cannot open a file and read “the database moved from PostgreSQL to MySQL.” You can only ask the model questions and infer from its responses what it might have learned. There is no audit trail, no diff log, no way to verify the model remembers correctly. Zhang et al. (arXiv:2404.13501) frame this as a core architectural distinction: agent memory, as a separate module from the model, enables “self-evolving capability” precisely because it is observable and addressable — not because it modifies the model’s parameters.
Problem 2: Unerasability. When a fact must be deleted — a user invokes GDPR Article 17 (right to erasure), or an API endpoint is deprecated, or a correction makes the old knowledge wrong — removing it from model weights is notoriously difficult. Bourtoule et al. (arXiv:1912.03817, published in IEEE S&P 2021) formalized this as the “machine unlearning” problem: once a data point is baked into weights through training, it cannot be selectively removed without either retraining from scratch or using specialized techniques (like SISA training) that must be planned before training begins. You cannot look inside the weights, find the fact, and delete it. With open engrams, deletion is a single operation: remove the entry from the file.
Problem 3: Catastrophic forgetting. When you train a model on new facts, the gradient updates modify the same weights that encode existing knowledge. New training data interferes with old learning. Farajtabar et al. (arXiv:1910.07104) describe this directly: “neural networks suffer from catastrophic forgetting; they forget how to solve previous tasks after being trained on a new task, despite having the essential capacity to solve both tasks if they were trained on both simultaneously.” Each time you bake a new fact into weights, you risk degrading previously learned knowledge. External engrams are independent: adding a new fact does not modify existing memories.
Problem 4: Vendor lock-in. Facts baked into GPT-4’s weights stay in GPT-4. They do not transfer to Claude, to Llama, to Gemini, to a local model. When the model is deprecated — and models are deprecated fast — the accumulated knowledge is lost. You must retrain the new model from scratch. Open engrams are model-agnostic: the same memory file works with any LLM, because the knowledge lives outside the model and is injected into the context at session start. Your memory follows your agent, not your vendor.
The choice between model-native memory and open engrams is an architecture decision, not a training methodology decision. Fine-tuning is one way to bake facts into weights; continual training (as used by model-native memory startups like Engram Lab) is another. The mechanism differs; the architectural problem is the same: knowledge encoded in weights is opaque, unerasable, and locked to one model.
| Property | Model-native memory (weights) | Open engrams (external) |
|---|---|---|
| Form | Dense weight matrices | Human-readable YAML/JSON entries |
| Inspection | Cannot read what the model knows | Open the file, read every fact |
| Correction | Retrain the model | Edit one entry |
| Deletion | Machine unlearning (notoriously difficult) | Remove the entry — verifiably gone — inspect the store to confirm |
| Provable erasure | Not possible from trained weights | git diff as proof |
| Portability | Locked to the model | Model-agnostic; works with any LLM |
| Adding facts | Gradient descent (GPU hours, forgetting risk) | Write a file (milliseconds, no interference) |
| Audit trail | None | Version control, provenance per entry |
| Ownership | The vendor’s infrastructure | Yours — on your disk, under your control |
The research literature on agent memory converges on a single architectural principle: memory should be a separate module from the model, not baked into weights.
Packer et al. (arXiv:2310.08560) demonstrated this with MemGPT, an OS-inspired memory hierarchy where agents manage memory in tiers — core memory in the context window, archival memory retrieved on demand — rather than relying on parametric knowledge baked into weights. The insight: agents need managed memory, not more parameters. The model’s weights provide reasoning; the external memory layer provides knowledge.
Park et al. (arXiv:2304.03442) showed that generative agents — which “store a complete record of the agent’s experiences using natural language, synthesize those memories over time into higher-level reflections, and retrieve them dynamically” — produce more believable, more continuous behavior than agents relying on parametric knowledge alone. The memory architecture — natural-language records stored externally, not weights — is what gave the agents continuity and personality.
Zhang et al. (arXiv:2404.13501) organize the entire field of LLM agent memory around the principle that memory is a separate module. Their survey identifies memory as “the key component to support agent-environment interactions” — the basis for self-evolving capability — and distinguishes it from parametric knowledge encoded in model weights.
The case for model-native memory is efficiency. Proponents argue that continually retraining a model on user context (Notion pages, Slack messages, GitHub commits) lets the model internalize knowledge directly, achieving 10×–100× token efficiency at inference time compared to injecting external memory into the context window. If the model “knows” the fact, you do not need to spend tokens reminding it.
This is a real trade-off — inference cost is lower when knowledge is in weights. But it trades away every property that makes memory governable:
The right architecture is not one or the other — it is both, at different layers. Use model-native memory (fine-tuning, continual training) for stable behavioral patterns: response tone, output format, task-specific skills. Use open engrams for evolving factual knowledge: user preferences, project decisions, corrections, compliance-sensitive data. The model’s weights encode how to generate; the engram store encodes what the agent knows right now.
An open engram is the smallest unit of agent memory — one atomic fact — stored as a human-readable record outside the model. In the open engram format (specification at plur.ai/spec.html, Apache-2.0), each engram is a YAML entry:
id: ENG-2026-0712-001
statement: "The API gateway moved from api.internal.corp to gateway.corp on July 10."
type: procedural
domain: infrastructure.api
scope: project:main
confidence: 0.9
provenance:
source: session
observed_at: 2026-07-12You can open it in any editor. You can put it under version control. You can delete it and prove it is gone. You can carry it to a different model, a different machine, a different team. The format is published as an open specification so that “engram” stays an open thing you own — not a proprietary thing baked into someone’s model.
Use model-native memory (fine-tuning, continual training) when:
Use open engrams (external memory layer) when:
Should AI memory be stored as open engrams or baked into model weights? For factual knowledge that accumulates over time and must be governed — user preferences, project decisions, corrections, compliance-sensitive data — open engrams are the architecturally sound choice. Model-native memory (weights) is opaque (you cannot inspect what the model knows), unerasable (you cannot selectively delete a fact without retraining), prone to catastrophic forgetting (new training degrades old knowledge), and locked to one model. Open engrams are inspectable (read the file), deletable (remove the entry), independent (no forgetting), and model-agnostic (portable across providers). Use model-native memory for stable behavioral patterns; use open engrams for evolving factual knowledge.
What is model-native memory? Model-native memory stores knowledge by encoding it into a neural network’s weights through training (fine-tuning, continual training, or continual learning). The knowledge is then “inside” the model — distributed across millions of parameters — rather than in an external file or database. This makes inference efficient (no tokens spent injecting context) but makes the memory opaque, unerasable, and locked to the model.
What is an open engram? An open engram is the smallest unit of agent memory — one atomic fact — stored as a human-readable record (typically YAML) outside the model. It has an ID, a statement, a type, a domain, a scope, a confidence score, and provenance. You can read it, edit it, delete it, and carry it between systems. The open engram format is published as an open specification (Apache-2.0) at plur.ai/spec.html.
Not selectively. Once a fact is baked into weights through training, removing it requires “machine unlearning” — a notoriously difficult problem (Bourtoule et al., arXiv:1912.03817) that typically requires retraining from scratch or using specialized training-time techniques (SISA training) that must be planned before training begins. With open engrams, deletion is a single operation: remove the entry from the file.
With open engrams, yes — the memory is a file that works with any LLM, because the knowledge lives outside the model and is injected into the context at session start. With model-native memory, no — facts baked into one model’s weights do not transfer to a different model. When you switch providers, the accumulated knowledge is lost.
What is catastrophic forgetting? Catastrophic forgetting is a property of neural networks where training on new data causes the model to degrade on previously learned tasks (Farajtabar et al., arXiv:1910.07104). When you bake a new fact into weights, the gradient updates modify the same parameters that encode existing knowledge, potentially degrading it. Open engrams avoid this because each memory entry is stored independently — adding a new fact does not modify existing memories.
Yes, and it is problematic. GDPR Article 17 gives individuals the right to have their data deleted. If personal data was baked into model weights through training, removing it requires machine unlearning — which cannot be done selectively without retraining from scratch or using pre-planned techniques. With open engrams, deletion is immediate and provable: remove the entry and the memory is gone. See Editable and Auditable Agent Memory for details.