RAG Systems
Retrieval that accounts for the user, not just the documents
Add durable user and project context to a RAG pipeline, so answers reflect who is asking and what has already been established — not only what the corpus contains.
The problem
A document-only RAG pipeline answers the same question identically for everyone. It has no record of the asker's configuration, prior questions, or corrections already issued. It also cannot tell that a retrieved document has been superseded, so confidently returns content that is no longer true.
With MemorySync
MemorySync adds a second retrieval axis alongside document search: durable memory about the user and project. Answers combine what the corpus says with what has been established about the asker, and ranking accounts for recency and supersession so stale content stops surfacing.
How it works
- 1
Retrieve documents
Your existing corpus search runs unchanged.
- 2
Retrieve memory
A parallel call returns durable facts about this user and project.
- 3
Compose
Both sets enter the prompt in clearly separated blocks.
- 4
Write back
What the exchange established becomes durable for later questions.
What document retrieval cannot know
RAG answers questions from a corpus, which is the right design for questions the corpus answers. It has no mechanism for the part of the answer that depends on who is asking.
Two users ask *"how do I configure retries?"*. One is on a plan where the setting exists, the other is not. A document-only pipeline gives both the same answer, and one of them is wrong.
Two axes, kept separate
The fix is not to put user facts into the document index. Documents and memories have different lifecycles, different update patterns, and different scoping requirements, and merging them makes both harder to reason about.
Run them as parallel retrievals and compose the results. MemorySync handles the memory axis — extraction, ranking, supersession, scoping — while your document pipeline stays exactly as it is.
Corrections have to persist
The failure users notice most in RAG is re-issuing a correction. They clarify that they are on the self-hosted deployment, get a good answer, and the next question reverts to the cloud assumption.
A correction is a durable fact. Written to memory, it shapes every later retrieval rather than lasting one turn.
If a user has to state the same clarification twice, the pipeline is missing a memory layer, not a better reranker.
Stale documents are a ranking problem
Corpora contain superseded content — an old runbook, a deprecated guide. Embedding distance cannot tell that one document replaced another, because they are nearly identical in meaning.
MemorySync ranks on recency and supersession alongside similarity, so a fact known to be replaced stops competing with the current one.
Keep memory out of the instruction block
Retrieved memories contain user-supplied text, and retrieved documents may come from connected sources. Neither is trusted input.
Place both in clearly delimited context blocks, separate from system instructions, and label them as background rather than commands. This is a security decision, not a formatting one.
Connectors keep the corpus current
Much of what a RAG system should know already sits in Google Drive, Notion, SharePoint, or S3. MemorySync connectors index permitted content from those sources with per-source approval, so the knowledge base stays current without a bespoke pipeline.
What you get
- Answers reflect the asker's configuration
- Corrections persist instead of being re-issued
- Superseded content stops being retrieved
- Follow-up questions keep their thread
- Document and memory retrieval stay separable
- Per-user and per-project scope
Use cases
Build rag systems with durable memory
Start on the free tier and test retrieval, scoping, and deletion against your own workload.
Start free. No credit card required.