The two products start from different places
Letta, the project that grew out of MemGPT, starts with the agent. Its memory model is part of the agent runtime: memory blocks, a context constitution, stateful agents and a development environment designed around that architecture.
AI Memory starts with the application. You already have an agent loop, a framework or a product with real users. The memory layer sits beside it: one endpoint to write events, one to retrieve context, and a graph you can inspect and export.
Neither starting point is wrong. They answer different questions. Letta asks, “How should an agent be built if memory is central?” AI Memory asks, “How do I add durable memory to the agent I already shipped?”
Letta and AI Memory at a glance
Letta publishes an open-source agent framework and a hosted agent product. Its public homepage emphasizes research and the Letta Agent rather than a self-serve memory API price list. AI Memory is positioned as a memory layer with published Pro and Scale plans.
| Dimension | Letta | AI Memory |
|---|---|---|
| Primary product | Agent framework and agent runtime | Memory layer and memory API |
| Integration model | Build or adopt an agent around Letta | Add memory to an existing agent or app |
| What you keep | Letta’s agent architecture and tooling | Your orchestration, prompts, tools and model |
| Memory model | Memory blocks and stateful agents | Extraction, merge, graph retrieval and compression |
| Portability | Open-source framework and agent state | JSON memory graph export |
| Best fit | Teams that want a memory-native agent runtime | Teams that want a smaller layer beside their current stack |
Sources: https://www.letta.com/ and https://ai-memory.lol/, checked October 19, 2026. Letta’s packaging and hosted pricing may change; verify directly before purchasing.
What you keep when you choose the layer
The most expensive part of an agent is usually not the model call. It is the orchestration, the tool contracts, the evaluation suite and the operational knowledge that took months to build. Replacing all of that to get memory is a large bet.
AI Memory is designed to avoid that bet. You keep your existing agent loop and add a write before the model call and a read before the prompt is assembled. If the memory layer is wrong for you, the export is a JSON file rather than a rewrite.
- Keep your framework: LangChain, LlamaIndex, Vercel AI SDK, a custom loop or plain HTTP.
- Keep your model: any provider, any mix, including open models.
- Keep your tool contracts and your evaluation suite.
- Add scoped memory, extraction, merging, retrieval and deletion.
What the memory layer adds
A layer is useful only if it removes work from the application. AI Memory takes over the parts that are tedious to build and easy to get wrong.
| Job | What AI Memory does | What you stop maintaining |
|---|---|---|
| Extraction | Pulls facts, preferences, decisions, constraints and episodes out of raw events. | A growing pile of prompt instructions and regexes. |
| Merging | Deduplicates, updates and supersedes memories instead of appending. | A summary table that slowly contradicts itself. |
| Retrieval | Scores similarity, recency, memory kind and graph relations, then reranks. | A hand-tuned retrieval pipeline for every agent. |
| Deletion | Deletes by memory, user, tenant or TTL with an audit trail. | A separate compliance script that nobody tests. |
| Export | Returns the graph as JSON. | A migration project when you change vendors. |
When Letta may be the better choice
Letta is the better choice when you are designing an agent from scratch around memory, and you want the runtime, the memory model and the tooling to come from one team. Its research lineage and open-source framework are real advantages for teams that want to explore memory-native agent architectures.
Letta may also be the better fit if you want an opinionated agent development environment rather than a small API surface.
AI Memory is the better fit when the agent already exists and memory is the missing infrastructure piece, not the whole product.
Moving from Letta without losing the plot
- Inventory what lives in memory blocks today: persona, user facts, task state and tool observations.
- Separate durable facts from working state. Not every memory block should become a long-term memory.
- Map Letta agents to AI Memory agent scopes and keep the user and tenant ids explicit.
- Replay a sample of real conversations and compare the retrieved context, not only the final answer.
- Keep the old state export until the new retrieval has passed your evaluation suite.
Frequently asked questions
Is AI Memory a Letta replacement?
Not exactly. Letta is an agent framework and runtime; AI Memory is a memory layer. You can use AI Memory beside an existing agent stack without adopting a new runtime.
Does AI Memory support memory blocks like Letta?
AI Memory organizes memories by kind, scope and entity graph rather than by named blocks. The API exposes add, search, update, delete and export operations.
Can I use AI Memory with an open-source model?
Yes. The memory layer is model-agnostic. It sits beside the model call and does not require a specific provider.
Why would I choose a layer over an agent OS?
If your agent already works and you only need durable context, a layer has a smaller blast radius. You avoid replacing orchestration, tools and evaluation while adding memory.
Can I migrate Letta memory into AI Memory?
You can export the durable parts of your Letta state and replay them as events or memories. Separate durable facts from working state first, then compare retrieval against real questions.
Does AI Memory lock me in?
The graph exports as JSON, and the same API can run against your own infrastructure when the self-hosted path fits your environment. You should still test the export before you depend on it.