Engraphy vs Letta
Checked 24 August 2026 · Engraphy v0.1.0
The short answer
These are different categories, and the choice is usually settled before you compare features. Letta is an agent runtime, descended from the MemGPT research: you build your agent on Letta, and the agent manages its own context, editing named memory blocks and paging facts in and out of archival storage with tools. Engraphy is a memory server: you bring whatever agent you already have, whether VS Code, a desktop client or your own code, and point it at Engraphy over MCP.
If you want the model to be in charge of what it remembers, that is Letta's thesis and it is a good one. If you want the store to hold the line regardless of what the model decides, with schema enforced in Postgres, tenants separated by the database and superseded facts retired rather than deleted, that is Engraphy's.
At a glance
| Capability | Engraphy | Letta |
|---|---|---|
| What it is | A memory server. Any MCP client connects to it. | An agent runtime and framework. You build agents on it. |
| Who decides what is remembered | The engine bands the write; the caller resolves the borderline case. No model inside the engine. | The agent itself, using tools to rewrite its own memory blocks. |
| Deployment | Self-hosted only. Postgres + pgvector, one Compose file. | Self-host the open-source server, or use Letta Cloud. |
| Licence | Business Source License 1.1, converting to Apache-2.0 at the Change Date. | Apache-2.0, with a commercial cloud. |
| Storage | Postgres 16 + pgvector. Typed nodes and edges. | Postgres or SQLite, with memory blocks and a vector-searchable archive. |
| Duplicate handling | Checked on write, before the row exists. | Whatever the agent does. There is no engine-level de-duplication. |
| When a fact changes | Retired and linked by a supersedes edge. | The agent rewrites the block. The previous text is gone unless you kept it. |
| Isolation | Postgres row-level security, per space, under a NOBYPASSRLS role. | Per-agent state; multi-tenant separation is yours to build. |
| Bring your own agent | Yes, that is the point. Any MCP client. | Not really. The agent lives inside Letta. |
| Model required | None. Embeddings run in-process; no LLM runs inside the engine. | Yes. The agent is an LLM and memory management is a model behaviour. |
Which one to choose
Choose Letta when
- You are building the agent from scratch and want a runtime that handles the loop, the tools and the context window for you.
- You want the agent to reason about its own memory, deciding what is worth keeping in context and what to page out. That is a genuinely different and often better design for long-horizon agents.
- You want the Agent Development Environment to inspect context windows and run history visually.
- You want Apache-2.0 with no field-of-use restriction.
- You want a managed cloud with a free tier.
Choose Engraphy when
- You already have an agent. Engraphy is MCP over HTTP, so VS Code, a desktop client or your own code connects without adopting a framework.
- You want guarantees that survive a bad model day: schema enforced in Postgres, no delete path on the write flow, isolation the database enforces.
- You are serving more than one user or tenant from one store and need the separation to be structural.
- You want memory that is queryable as data, hybrid search plus graph traversal, rather than text an agent curates.
- You want no outbound calls on the write path.
You can use both, and it is not a strange thing to do
Letta supports MCP servers as tools. Engraphy is an MCP server. So a Letta agent can use Engraphy as its long-term, multi-tenant, schema-enforced store while keeping Letta's memory blocks for the working context it manages itself.
That combination plays to both designs: Letta decides what belongs in the context window right now, and Engraphy holds the durable record with de-duplication, supersession and row-level isolation underneath. If you are already committed to Letta and the thing you are missing is a store you can audit, this is the shape to reach for before you migrate anything.
Memory blocks are editable text. Engraphy nodes are rows.
Letta's core memory is a set of named blocks (persona, human, and whatever else you define) that the agent rewrites with tools. It is a clean abstraction and it makes the agent's self-model legible.
It also means the previous content of a block is gone once the agent rewrites it, unless you
built something to keep it. Engraphy's model is the opposite: a fact that stops being true is
retired and linked by a supersedes edge, so the chain back through every version
stays walkable, and no write path deletes a memory.
Neither is universally right. If your agent's memory is a self-description it should be free to revise, blocks are better. If it is a record other people will one day ask questions about, rows are better.
What Engraphy does not do
Stated plainly, so that nothing here has to be walked back:
- A near-verbatim restatement can lose its text. If an incoming body
overlaps the stored one at a Jaccard of 0.8 or above it is not added as an addendum,
and the write returns
addendum_added: false. Nothing is deleted, and not everything written is kept as new text. - Contradictions merge. A negation sits close in meaning to the fact it
overturns, so it scores above the merge threshold and is absorbed, measured at 28
of 36 pairs in our own contradiction set. The merge result names what it merged into, so
the caller can repair it with
supersede. The engine will not guess, because agreement is a judgment call and no model runs inside the engine. - Time travel goes as far as supersession, not further. Facts are retired and linked rather than overwritten, so history is walkable. Full bi-temporal querying, asking what the store believed at an arbitrary past instant, is not built.
- Ranking is reciprocal rank fusion today. The cross-encoder slot is specified and stays disabled until there is evidence it earns its cost.
- It is v0.1.0, and it is self-hosted only. There is no managed Engraphy to sign up for. You run Postgres, or nothing runs.
Questions people ask
Is Letta a memory layer or an agent framework?
An agent framework and runtime. Letta descends from the MemGPT research and gives agents an OS-style memory hierarchy of in-context blocks plus searchable archival storage, which the agent manages itself with tools. Engraphy is a memory server you point an existing agent at over MCP, with no runtime of its own.
Can I use Engraphy with Letta?
Yes. Letta can call MCP servers as tools and Engraphy is an MCP server, so a Letta agent can keep its own memory blocks for working context while using Engraphy as the durable, de-duplicated, multi-tenant store underneath.
Which one keeps history when a fact changes?
Engraphy. A superseded fact is retired and linked rather than deleted, so you can walk back through every version. In Letta the agent rewrites a memory block, and the previous text is gone unless you built something to retain it.
Do I need an LLM to run Engraphy?
No. Engraphy's embedding model runs in-process and no language model runs inside the engine at all: the banding that decides merge, link or park is deterministic. Letta is an agent runtime, so a model is fundamental to it.
Sources
- Letta on GitHub: Apache-2.0 agent server, memory blocks, archival memory.
- Letta documentation: Memory hierarchy, MCP tool support, Letta Cloud.
Try it against your own memory
Engraphy is a server you host. Point any MCP client at it. Embeddings run in-process, so there is no API key and no data leaves the box.