Does each user get their own memory?

Yes. Each end-user has their own memory and each workspace its own documents. Nothing is shared between them, and isolation is by construction rather than by configuration.

Where do the models that read my documents run?

On EU-resident endpoints. The model that extracts facts from a conversation and the model that embeds your documents both run inside the EU, end to end.

How is this different from a bigger context window?

A context window holds only what you resend on that request. Recall keeps facts between requests, reconciles them when they change, and follows the links between them rather than piling up contradictions.

Do I have to manage the memory myself?

No. Send a user id with your request and put your documents in a collection. Facts are learned in the background and recalled on their own.

Recall

Your models remember users and know your documents.

Recall learns durable facts from every conversation and grounds answers in your own documents, then keeps both in one knowledge graph. Ask a question and it recalls the relevant facts and passages, following the connections between them. Extraction and retrieval run on EU-resident models, scoped to each end-user and workspace, and erasable on request.

Start free Read the docs

learn · connect · recall

Your model forgets every user and has never read your docs.

A model holds nothing between requests and answers only from its training, not from your handbook or last week's decision. So you resend the same context every call and still miss what matters. Build it yourself and you are running a store, an extraction step and a retrieval step, keeping all of it correct as facts change, often through a US API that ships your data abroad. Two half-solutions, memory and retrieval, that never share what they know.

How it works

Learn, connect, recall.

Send a user with your request, add your documents once, and Recall does the rest. Nothing to flag, no context to resend, no retrieval call to wire up.

01LearnLearn and ingestAfter each exchange, an EU-resident model extracts durable facts in the background: preferences, roles, decisions. Documents you add are parsed, split and read into the same graph. It runs after the response, so it adds no latency.
02ConnectConnect and reconcileFacts and documents become entities and relationships in one temporal graph. New facts are merged against what is known: changed ones update, contradicted ones are retired. The graph stays correct instead of just growing.
03RecallRecall with sourcesOn a request that carries a user, Recall blends the relevant facts and passages, following the links between them, and adds them as context before the model runs. Every answer can name the facts and documents it used.

Two fields. Facts are learned and recalled on their own.

Why it is different

More than a bigger context window, more than a bolt-on index.

Stuffing the whole history into every prompt is slow, expensive and still forgets what matters. A do-it-yourself retrieval stack is a vector database plus an embedding API plus glue. Recall is one knowledge layer where memory and documents share a graph.

One graph, not two silos
Conversation facts and document facts live together, so a question can follow the link from a user to their organization to the document that answers it.
Automatic, not manual
Send a user id and put your documents in a collection. Facts are learned and recalled and passages retrieved on their own, with no separate service to call first.
Reconciled, not appended
When a user changes their mind or a document is updated, the graph updates rather than piling up contradictions.
Grounded and cited
Answers can name the facts and documents they used, the audit trail stays metadata-only, and any user's memory is erasable on request.

A knowledge layer

You can stand behind it.

Isolated by construction

Each end-user has their own memory, and each workspace its own documents. Recall reads the acting end-user's memory plus that workspace and its collections, never another user's, another workspace's, or another tenant's.

EU-resident, end to end

The models that read the conversation and embed your documents run on EU-resident endpoints, and the graph lives in an EU-resident store. Your users' memory and your knowledge base never leave the EU.

Recorded and erasable

Recalled facts are pseudonymized by the firewall before egress, every answer can cite its sources, the audit trail is metadata-only, and one call wipes everything stored for an end-user.

FAQ

Questions people ask about Recall.

Does each user get their own memory?: Yes. Each end-user has their own memory and each workspace its own documents. Nothing is shared between them, and isolation is by construction rather than by configuration.
Can a user's memory be deleted?: Yes. One call wipes everything stored for an end-user. Recalled facts are pseudonymized by the firewall before they leave the EU, so an erasure request is a single operation.
Where do the models that read my documents run?: On EU-resident endpoints. The model that extracts facts from a conversation and the model that embeds your documents both run inside the EU, end to end.
How is this different from a bigger context window?: A context window holds only what you resend on that request. Recall keeps facts between requests, reconciles them when they change, and follows the links between them rather than piling up contradictions.
Do I have to manage the memory myself?: No. Send a user id with your request and put your documents in a collection. Facts are learned in the background and recalled on their own.

Start here

Give your models a knowledge layer.

Create a key, send a user with your requests, add your documents, and stop resending the same context on every call.