Engraphy › Compare › built-in assistant memory
Engraphy vs built-in assistant memory
Checked 24 August 2026 · Engraphy v0.1.0
The short answer
If you want an assistant to remember what you tell it in conversation, the built-in memory is the answer and you do not need Engraphy. ChatGPT, Claude and Gemini all keep memory about you inside their own products, with no setup at all.
Engraphy is for when that memory needs to be yours. It is a server you run on your own Postgres that any MCP client can read and write, so the same store is available to your editor, your desktop client and your own code, it stays on your machine, you can query it as data, and it survives you switching model vendors. The built-in memories are per-product, opaque, and cannot be read by anything but the product that owns them.
At a glance
| Capability | Engraphy | built-in assistant memory |
|---|---|---|
| Setup | You run a Postgres and an MCP server. Real work. | None. It is on by default in the product. |
| Who owns the store | You do. It is rows in your database. | The vendor. You can view and delete entries in their UI. |
| Where it lives | Your machine or your cloud. Embeddings in-process, no egress. | The vendor's infrastructure. |
| Which tools can read it | Any MCP client: editor, desktop app, your own code, all against one shared store. | Only the product that owns it. |
| Portability | It is a Postgres database. Export it, back it up, move it. | Limited. Memory does not follow you to another vendor. |
| Queryable as data | Yes. Hybrid search, graph traversal, and SQL underneath. | No. It is applied to your conversation, not exposed as a store. |
| Multiple users or tenants | Spaces and principals, separated by Postgres row-level security. | One account, one person. |
| When a fact changes | The old version is retired and linked, so you can trace the change. | The entry is updated or removed. |
| Duplicate handling | Checked on write, before the row exists. | Vendor-internal, and not something you configure. |
| Cost | Whatever your Postgres costs. No per-memory fee. | Included in the subscription. |
Which one to choose
Choose built-in assistant memory when
- You want an assistant to remember your preferences and it is not worth running infrastructure for. This is most people, most of the time.
- You only use one product, so a store shared across tools buys you nothing.
- You do not want to operate a database, and there is no managed Engraphy to fall back on.
- The memory is casual, such as how you like your answers formatted or what you are working on this week, and losing it would be an annoyance rather than a problem.
Choose Engraphy when
- The same memory needs to be available to more than one tool. One Engraphy store serves your editor, your desktop client and your own agents over MCP.
- The data must not leave your infrastructure. Engraphy is self-hosted and embeds in-process, so a write never becomes an outbound call.
- You are building a product, not configuring an assistant, and your users' memories have to stay separated by something stronger than application code.
- You need to inspect and query the store: what does it know, where did that come from, what did it replace.
- You do not want the memory to disappear when you change model vendors.
“How do I get an AI to remember what I tell it?”
There are three honest answers, and which one you want depends on what breaks if the memory is lost.
- Use the built-in memory. ChatGPT, Claude and Gemini all retain things about you across conversations inside their own products. Zero setup. The store belongs to the vendor, only that product can read it, and it does not come with you if you leave.
- Give your agent a memory tool. Any MCP client can be pointed at a memory server, which the model then calls to write and recall facts. The store is yours, it is shared across every tool that connects, and it is queryable as data. This is what Engraphy is.
- Put it in the prompt. Project instructions, a system prompt, a
CLAUDE.md. Fine for a handful of durable facts; it does not scale, and it does not accumulate.
The question underneath “how do I get you to remember the things I tell you” is usually “why did it forget”. Built-in memory forgets because it is summarising into a budget it will not show you. A memory server forgets far less because recall is a search over rows rather than a context window, and in Engraphy's case because a superseded fact is retired and linked rather than deleted.
The part that is not about privacy
Self-hosting usually gets argued on data control, and that argument is real: Engraphy runs its embedding model in-process, so a memory write never becomes an outbound API call.
But the reason most people end up wanting a memory server is duller: one store, many tools. What you told your editor should be known by your desktop client and by the agent you wrote last week. Vendor memory cannot do that, because the store belongs to the product. An MCP memory server can, because every client speaks the same protocol to the same database.
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
How can I get an AI to remember the things I tell it?
Three ways. Turn on the assistant's built-in memory, which needs no setup but keeps the store inside that one product. Give the agent a memory tool over MCP, so it writes facts to a database you own and any client can read. Or put durable facts in the system prompt or project instructions, which works for a handful of things and does not scale.
How do I make ChatGPT or Claude remember things between sessions?
Both have built-in memory you can enable in the product's settings, and both let you view and delete what they have stored. If you want the memory shared across several tools, kept on your own machine, or queryable as data, you need a memory server your client connects to instead. For Claude and any other MCP client, that means pointing it at an MCP memory server such as Engraphy.
Is self-hosted AI memory better than ChatGPT's memory?
Better at different things. Built-in memory wins on effort: there is none. A self-hosted store wins when the same memory must be readable by more than one tool, must stay on your infrastructure, must be queryable, or must be separated per user because you are building a product rather than configuring an assistant.
Can I move my ChatGPT memories into my own store?
Not directly, and not in a structured way. Vendor memories are per-product and are not exposed as a store you can read programmatically. In practice you re-establish the facts that matter by telling your agent, which then writes them to your own store.
Does Engraphy work with Claude, VS Code and other clients at the same time?
Yes. Engraphy speaks MCP over HTTP with a bearer token, and you mint a token per client, so several clients can read and write the same space. That shared store is the main practical reason to run one rather than relying on per-product memory.
Sources
- Model Context Protocol: The open protocol that lets any client connect to a memory server.
- Engraphy developer docs: Setup, packs, the tool reference and deployment.
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.