Self-hostable AI memory · Open source

Every modelforgets. Engramremembers.

A memory layer that sits between your app and any LLM. It retrieves the facts that matter, injects them into the prompt, forwards the call, then quietly learns new facts after every reply.

$docker compose up Read the source

MIT licensedpgvectorMCP-nativeLocal embeddings

engram · POST /v1/chat

user_92f · incoming

"What backend framework should I use for this project?"

Embed

Rank

Inject

[ memory context · 3 injected ]

0.91Prefers FastAPI over Flask for backends

0.84Building SENTINEL, a market simulator

0.71Wants concise answers, no filler

→ forwarded to gpt-4o-mini with context▍

§ I — The problem

Every LLM API is stateless by design. Your users are not.

Ship anything on top of a raw LLM API and it forgets the user the moment the request ends. Every team then rebuilds the same three bad options:

01 / expensive

Stuff the whole history into every prompt until it hits the context limit.

02 / slow

Hand-roll a memory pipeline per app: inconsistent, fragile, and never finished.

03 / locked in

Rent a closed service with no self-hosting, no inspection, and no control.

Engram is the fourth option: one open primitive that makes any stateless model feel stateful.

§ II — The loop

Retrieve, forward, learn.

The proxy runs the whole memory loop on a single request. Retrieval and extraction failures never break the response: the model always answers.

Embed the message

The latest user message is embedded locally with BAAI/bge-small-en-v1.5: 384 dimensions on CPU, with no embedding API cost.

Search & rank

pgvector cosine search is reranked by recency and access count. The threshold still rejects weak matches.

Inject into the prompt

Top matches are folded into the system prompt as a clean memory-context block before the user message.

Forward & return

The enriched request goes to your provider. The response streams straight back through the compatible endpoint.

Extract new facts

After the reply, an asynchronous job pulls durable user facts from the exchange without blocking the response.

Reconcile & store

New facts are compared with existing memories, then added, updated, discarded, and stored as embeddings.

§ III — Three ways in

One memory backend. Three interfaces.

Drop-in proxy

Proxy endpoint

Swap one base URL. Engram enriches the prompt going out and learns from the reply coming back.

# same body as OpenAIPOST /v1/chat/completionsAuthorization: Bearer ek_...

Full control

REST API

Create, search, edit, and delete memories directly. Every retrieval is logged for inspection.

POST /memories/searchGET  /logsPATCH /memories/{id}

Agent-native

MCP server

Give compatible assistants six focused memory tools through the Model Context Protocol.

search_memoriescapture_conversationget_retrieval_log

§ IV — Quickstart

From zero to a stateful model in minutes.

Configure your provider key, start the four services, and send the same chat payload your app already uses.

Open dashboard

bash — engram

# 1 · configure
cp .env.example .env

# 2 · start postgres + api + mcp + dashboard
docker compose up -d

# 3 · create a user (api key shown once)
curl -X POST localhost:8000/users \
  -d '{"external_id":"me"}'

# 4 · send a chat through the proxy
curl localhost:8000/v1/chat \
  -H "X-Engram-Key: ek_..." \
  -d '{"model":"gpt-4o-mini", ... }'

§ V — Why Engram

The open primitive closed tools won't give you.

Capability	Engram	Mem0	Zep
Self-hostable	✓ Yes	~ Partial	✓ Yes
MCP server interface	✓ Yes	× No	× No
Retrieval inspection & logs	✓ Yes	× No	~ Partial
Local embeddings	✓ Yes	× No	× No
Fully open source	✓ Yes	~ Partial	✓ Yes

§ VI — Nothing hidden

See why the model knew that.

Every retrieval is logged: the query, surfaced memories, similarity scores, and the conversation that triggered them. No black box, just an inspectable ledger.

queryscoresmemory idsconversation

"what backend should I use"14:23:01 · conv_abc1

Retrieved 3 memories