Engraphy Compare Docs ← Back to site

Engraphy › Answers

Memory for AI and agents, answered

Checked 24 August 2026 · Engraphy v0.1.0

About this page

Short, direct answers to the questions people actually ask about giving AI agents memory. Where Engraphy is the answer, it says so; where it is not, it says that too.

How can I get an AI to remember the things I tell it?

Three ways, in increasing order of effort and control. Turn on the assistant's built-in memory. ChatGPT, Claude and Gemini all have one, and it needs no setup, but the store belongs to the vendor and only that product can read it. Give the agent a memory tool over the Model Context Protocol, so it writes facts to a database you own that any client can read. Or put a handful of durable facts in the system prompt or project instructions, which works until there are too many of them.

If the answer needs to be shared across tools, stay on your machine, or be queryable later, it is the second one. That is what a memory server is for.

How do I give an AI agent long-term memory?

Point it at a memory server and let it call that server as a tool. The agent writes what it learns and searches what it wrote; the facts live in a database rather than in the context window, so they survive restarts, and recall is a search rather than a re-read.

With Engraphy that is docker compose up -d for Postgres, pgvector, the migrations and the server, then a space, a pack and a bearer token pasted into your MCP client. The setup guide walks the whole thing.

How do I stop my agent from storing the same fact twice?

Check on write, not on read, and check on meaning, not on text. Substring matching will not catch “prefers dark mode” against “likes the dark theme”, so the store fills with near-duplicates that all come back at search time.

Engraphy embeds every write and bands it against existing memory before the row exists: a clear restatement merges into what it repeats, a related but genuinely new fact is stored as its own node and linked by an edge, and a borderline case is parked as a pending verdict for the caller rather than guessed at.

What happens when something the AI remembered stops being true?

The two options are overwrite it or retire it, and they are not equally recoverable. Most memory layers update or delete the earlier entry, which means the question “what did we believe in March, and when did that change” has no answer.

Engraphy retires the old version and links it with a supersedes edge, so the chain back through every version stays walkable and no write path deletes a memory. What it does not do is full bi-temporal querying: you can walk the chain, but you cannot ask for the state of the store at an arbitrary past instant in one query. Zep's Graphiti can.

What is the best self-hosted memory for AI agents?

It depends on what you are protecting against. For a permissive licence and the largest ecosystem, self-host Mem0. For document corpora turned into a knowledge graph, Cognee. For bi-temporal auditing, Graphiti. For an agent runtime that manages its own context, Letta.

Engraphy is the pick when the store's guarantees matter more than its ecosystem: de-duplication before the row exists, a schema Postgres enforces, tenants separated by row-level security, superseded facts retired rather than deleted, and an embedding model that runs in-process so nothing leaves the box.

How do I keep my AI's memory private and on my own machine?

Watch the write path, not just the storage. A memory layer can store rows on your disk and still send every fact to a model provider, because extraction and embedding are usually API calls. Self-hosted storage with hosted embeddings is not private.

Engraphy runs its embedding model in-process. The model weights are baked into the Docker image, so the first boot is offline and a memory write never becomes an outbound request. There is no API key to configure because there is no provider to call.

How do I keep agent memory separate for each user or project?

Make the database enforce it, not the query builder. Scoping by a user_id column works right up until one code path forgets the filter, and then it is a cross-tenant read.

Engraphy separates every space with Postgres row-level security, and the server connects as a role marked NOBYPASSRLS. An agent cannot read another space's memory even if the application asks for it, because the database will not return the row.

How do I add memory to an MCP client like Claude Desktop or VS Code?

Run an MCP memory server and point the client's configuration at it. The reference server that ships with the protocol keeps a knowledge graph in a flat JSON file over stdio, which is fine for one person on one machine and breaks on paraphrase, volume, concurrency and a second user.

Engraphy serves MCP over HTTP with a bearer token, so you mint a token per client and several clients share one store. Any MCP client connects: an editor extension, a desktop app, or your own agent.

Is a vector database enough for agent memory?

It handles recall and none of the other three problems. A vector store will find a fact you phrased differently, which is the hard part of retrieval, but on its own it will happily store the same fact five times, has no opinion about what happens when a fact changes, and enforces no separation between users beyond the filter you remember to pass.

Memory is a write-path problem as much as a read-path one. Engraphy uses pgvector for the recall leg, fuses it with Postgres full-text search, and puts de-duplication, supersession and row-level isolation around it.

What is the difference between agent memory and RAG?

RAG reads a corpus that already exists. Memory accumulates one the agent is writing. Retrieval-augmented generation points a model at documents you ingested ahead of time; the store is rebuilt by re-running the pipeline, and nothing in it arrived one fact at a time.

Agent memory is written incrementally during use, which creates problems RAG never has: the same fact arriving twice in different words, a fact that was true in March and is not now, and several users writing into one store. Those are write-path problems, and they are what a memory engine is for.

How is AI memory accuracy actually measured?

Mostly on LoCoMo, the standard long-conversation memory benchmark. A system ingests long multi-session conversations and then answers questions about them; published figures usually exclude the adversarial category for want of ground truth.

Engraphy scores 67.1%, second of seven and ahead of Mem0 and Zep, with a 95% confidence interval of 62 to 72 that reaches the top of the field and covers the leaders, so it is statistically level with them. On temporal-reasoning questions it scores 76.0% [67 to 83] against a best published figure of 58.1%. Read the numbers with their provenance on the benchmark section, and treat any comparison across different judges and question counts as placement rather than ranking.

Which Mem0 alternative should I choose?

Sort by the constraint that actually binds you. Need bi-temporal history? Graphiti. Need documents ingested into a graph? Cognee. Need an agent runtime rather than a store? Letta. Need nothing to leave your infrastructure and tenant isolation the database enforces? Engraphy.

Need the biggest ecosystem and the shortest path to a working prototype? Stay on Mem0.

Comparing specific systems

If you have narrowed it down to a shortlist, the comparison pages go capability by capability against Mem0, Zep and Graphiti, Letta, Cognee, the reference MCP memory server, and the memory built into ChatGPT and Claude. Every page names where the other system is the better choice.

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.

Install for VS Code Self-host quickstart Developer docs