The short answer: both, and the split matters. The major agent-memory engines — Mem0, Letta, Cognee, Graphiti, LangMem, and PLUR — are all Apache-2.0 or MIT licensed on GitHub. But “open source” and “open format” are not the same thing. A project can ship under Apache-2.0 while storing your memories in opaque vector blobs you cannot read, edit, or export. The real question is not whether the software is open — it usually is — but whether your memories are.
This distinction separates the field into three tiers: fully open (software + format + data you own), open-core (software is open, but the hosted memory is not portable), and fully proprietary (memory baked into a model provider’s infrastructure, no export at all).
AI agents face a brutal constraint: they forget. Every new session starts blank. Every context window overflows. The fix is persistent memory — but persistent where, and in whose format?
The term “engram” comes from neuroscience. Richard Semon coined it in 1904 for the physical trace a memory leaves in biological tissue (Semon, 1904; cited in Wikipedia, “Engram (neuropsychology)”). Applied to AI agents, an engram is one discrete thing an agent has learned — a correction, a preference, a procedure — stored so it survives across sessions.
The question “open source or proprietary?” asks two things at once:
Conflating the two is how vendors end up with open-source repos and locked-in data.
These projects ship under permissive licenses (Apache-2.0 or MIT) AND store memory in a format you can inspect, edit, and export.
| Project | License | Stars (Jul 2026) | Memory format | Data ownership |
|---|---|---|---|---|
| PLUR | Apache-2.0 | ~215 | Human-readable YAML engrams | Yours — plain files |
PLUR stores each engram as a plain-text YAML entry — an id, a statement, a type, a domain, a scope, a confidence, and provenance — in a file you can open in any editor, put under version control, and carry between machines. The format is published as an open specification, the Engram Specification (plur.ai/spec.html, Apache-2.0), and the implementation is Apache-2.0 on GitHub (github.com/plur-ai/plur).
The tier is small but growing. The “engram” name itself is spreading fast: GitHub now hosts a dozen-plus young projects named engram, most of them early-stage local-first memory experiments. That crowding is the signal — “engram” is becoming the default word for a unit of agent memory. It is also why a published open specification matters: without one, every project that adopts the term defines it differently, and the word stops meaning anything portable.
The common thread of Tier 1: you can read the memory, you can fix it, and you can prove you deleted it. That is only possible when the format is open, not just the engine.
These projects have open-source engines on GitHub under permissive licenses, but their hosted/cloud products store memory in formats that are not easily portable, and the commercial tier is where revenue lives.
| Project | License | Stars (Jul 2026) | Open format? | Hosted tier |
|---|---|---|---|---|
| Mem0 | Apache-2.0 | ~60,500 | No — vector + graph store | $19–$249/mo |
| Letta | Apache-2.0 | ~23,700 | Partial — agent state, not portable engrams | $20/mo (Pro) |
| Cognee | Apache-2.0 | ~27,400 | No — knowledge graph internals | Self-host or cloud |
| Graphiti | Apache-2.0 | ~28,500 | No — temporal knowledge graph | Via Zep cloud |
| LangMem | MIT | ~1,500 | No — LangGraph storage layer | Via LangSmith |
Mem0 is the clearest example. The repo (github.com/mem0ai/mem0) is Apache-2.0 with nearly 60,000 stars — you can self-host the engine. But Mem0’s commercial product (mem0.ai) charges $19–$249/month for hosted memory with graph memory, audit logs, and on-prem deployment reserved for the Enterprise tier. The memory format under the hood is a vector store with entity linking — not a human-readable file you can diff.
Letta (formerly MemGPT) is similarly split. The Letta SDK is Apache-2.0 on GitHub (github.com/letta-ai/letta, ~23,700 stars). The hosted “Constellation” platform — with managed state, remote environments, and an LLM gateway — requires an account. Free accounts support up to three agents with managed state; Pro is $20/month. Memory is stored as agent state (blocks of text managed by the agent), not as individual portable engrams you can export and edit.
Graphiti (github.com/getzep/graphiti, ~28,500 stars) builds real-time knowledge graphs for agents under Apache-2.0, but its commercial path is through Zep’s cloud platform.
Cognee (github.com/topoteretes/cognee, ~27,400 stars) is an open-source AI memory platform using knowledge graphs, also Apache-2.0, with self-host or cloud options.
The pattern: the engine is open, the data format is not. You can run the software, but the memories live in vector embeddings, knowledge graphs, or agent state blocks that are not designed to be read by humans or exported to a different system.
This is not a criticism — open-core is a legitimate model. But it means “open source” answers the wrong question. The right question is: can I take my memories with me?
The third tier is memory that is neither open-source software nor an open format. It lives inside the model provider’s infrastructure, and you cannot inspect, export, or port it.
OpenAI’s ChatGPT memory is the canonical example. When ChatGPT “remembers” facts about you across conversations, those memories are stored in OpenAI’s infrastructure. There is no open-source engine, no documented format, no export API. You can toggle memory on or off, and you can view and delete individual memories in the UI — but you cannot extract them in a structured format, run them locally, or feed them to a different model.
Anthropic’s Claude memory tool takes a similar approach. The memory tool is a feature of the Claude platform — agents can store and retrieve context — but the storage format, the retrieval mechanism, and the data itself are proprietary. There is no GitHub repo, no format spec, no portability guarantee. (Note the distinction: Claude Code’s CLAUDE.md and auto-memory files are a separate, file-based mechanism — plain markdown on your own disk — and do not belong in this tier.)
Google Gemini’s context operates the same way. Long-term context is managed inside Google’s infrastructure with no documented open format.
The risk here is not that these features are bad — they are convenient and often work well. The risk is vendor lock-in for your most personal data. When your agent’s accumulated knowledge about your preferences, projects, and workflow lives inside a single provider’s black box, switching costs become prohibitive. You cannot audit what it knows. You cannot prove what it forgot. You cannot carry it elsewhere.
Three tiers, but the meaningful boundary is between Tier 1 and everything else:
| Property | Tier 1 (Fully open) | Tier 2 (Open-core) | Tier 3 (Proprietary) |
|---|---|---|---|
| Engine open source? | Yes | Yes | No |
| Memory format documented? | Yes | No | No |
| Data human-readable? | Yes | No (vectors/graphs) | No |
| Can edit individual memories? | Yes | Via API only | Via UI only |
| Can prove erasure? | Yes (delete the entry; git diff as proof) | Best-effort | Best-effort |
| Can export to another system? | Yes (it’s a file) | No standard export | No export |
| Portable across model providers? | Yes | No | No |
The agents that need open memory most are the ones operating across multiple tools, models, and providers. An agent that uses Claude for analysis, GPT-4 for coding, and a local model for privacy needs a memory layer that is none of those — it needs a format that belongs to the operator, not the model.
This is where the Model Context Protocol (MCP) enters. MCP (specification version 2025-11-25, modelcontextprotocol.io) is an open protocol — JSON-RPC 2.0 based, inspired by the Language Server Protocol — that standardizes how LLM applications connect to external data sources and tools. It is transport-level: it says how an agent talks to a memory server, not what format the memories are in. But it makes format-level openness newly relevant, because any MCP-compatible agent can now connect to any MCP-compatible memory server. The format question — can I read, edit, and port my memories? — becomes the differentiator.
If the answer to all six is yes, you are in Tier 1. If the engine is open but the format is not (questions 3–6 fail), you are in Tier 2. If there is no open engine at all, you are in Tier 3.
Are AI agent engrams open source? The major engines are — Mem0, Letta, Cognee, Graphiti, LangMem, and PLUR all ship under Apache-2.0 or MIT. But the memory format is often not open. Very few projects store memory in a human-readable, documented, portable format you can inspect and export — PLUR publishes its engram format as an open Apache-2.0 specification (plur.ai/spec.html) precisely so that “engram” stays an open, implementable thing rather than a vendor label.
What is the difference between open source and open format for AI memory? Open source means the software engine is on GitHub under a permissive license. Open format means the memory data itself is stored in a documented, human-readable structure you can read, edit, and carry between systems. A project can be open source without being open format — most are.
Can I export my agent’s memory from a proprietary system? Generally, no. OpenAI’s ChatGPT memory, Anthropic’s Claude memory tool, and Google Gemini’s context all store memory inside the provider’s infrastructure with no structured export. You can view and delete memories in the UI, but you cannot extract them in a portable format.
What license is PLUR’s engram format under? Apache-2.0. The engram format is documented in the Engram Specification at plur.ai/spec.html and the implementation is at github.com/plur-ai/plur. Each engram is a YAML entry you can open, edit, and version-control.
Is MCP an open standard for agent memory? MCP is an open transport protocol (JSON-RPC 2.0, specification 2025-11-25) that standardizes how agents connect to external tools and data sources — including memory servers. It does not define a memory format. But it makes format-level openness more valuable, because any MCP-compatible agent can connect to any MCP-compatible memory server regardless of vendor.