A retriever can find source material, but memory needs a write path. The write path decides what should survive, attaches source and scope, records lifecycle state, and creates a deletion handle. Without it, teams build RAG systems that search documents but still forget decisions, preferences, and corrections.
Last updated: June 20, 2026.
What is a write path?
A memory write path is the part of the system that turns an observation into durable memory. It answers: should this be remembered, under what scope, from which source, as what type, and for how long?
The OpenAI conversation state guide places state management in the application. That is the write-path principle. The model can suggest what might matter, but the application must control durable writes.
Why is retrieval alone not memory?
Retrieval is a read path. It starts with existing content and finds relevant candidates. A memory system also needs to write new facts, update old facts, mark replacements, and remove specific artifacts. RAG can be part of memory, but it does not define the lifecycle.
| Capability | Retriever | Memory write path |
|---|---|---|
| Find matching documents | Yes | Usually uses it later |
| Save a project decision | No | Yes |
| Attach tenant or user scope | Maybe as a filter | Yes at write time |
| Mark old fact superseded | No | Yes |
| Store delete handle | No | Yes |
| Explain why fact exists | Usually weak | Yes through source lineage |
The LangChain memory concepts distinction between short-term and long-term memory is useful here. Long-term memory needs explicit writes. It should not depend on accidental inclusion in a transcript.
What should the write path record?
Use a strict minimum. Every durable memory should carry:
- The source artifact or transcript turn.
- Tenant, workspace, library, and user scope where applicable.
- Memory type: semantic, episodic, procedural, preference, instruction, or source artifact.
- Evidence spans or citation references.
- Lifecycle state: current, superseded, deleted, draft, or ignored.
- Creation and update time.
- Delete handle for source and derived artifacts.
- Optional confidence or review status.
Do not write “the user was typing” or “the model ran a command” unless that event has future value. Write the durable decision or correction instead.
How should a write path decide what to remember?
Use a policy gate. The gate should prefer facts that are stable, source-linked, scoped, and useful later. It should reject raw chatter, secrets, ephemeral tool output, duplicate facts, and unsupported guesses.
Example write policy:
| Candidate | Write? | Reason |
|---|---|---|
| ”Use pnpm in this repo” | Yes | Procedural project rule |
| ”The user opened a file” | No | Transient task state |
| ”Customer asked for SSO in Q3” | Yes, if sourced | Episodic/customer decision |
| ”Maybe pricing changed” | No | Unsupported guess |
| ”Old endpoint is replaced by new endpoint” | Yes | Supersession relationship |
This policy also reduces memory bloat. A write path that stores everything creates a retrieval problem later.
How should the write path handle corrections?
Corrections are first-class memory events. If the user says “that is no longer true,” do not only change the next answer. The write path should store a new current fact, mark the old fact superseded, and preserve lineage so a later trace can explain the replacement.
That is supersession-aware memory. The system should be able to answer current-state questions from the new fact while still preserving historical evidence when the user asks what changed.
How does MCP expose a write path?
MCP gives an agent a tool surface. The MCP architecture overview defines tools as executable functions exposed by a server. A memory MCP server should expose write tools such as save_content or append_memory, not only search tools.
Answer Engine’s public docs describe the MCP tool surface with search_content, get_content, ask, save_content, and append_memory. That is the difference between a search connector and a memory server: the server can read and write scoped source-aware memory.
How do you inspect a write path?
Inspect one memory from birth to retrieval:
- Which source created it?
- Which policy allowed the write?
- What scope was attached?
- Which derived artifacts were created?
- Which retrieval query returned it?
- Which answer cited it?
- Which delete handle can remove or disable it?
If any step is invisible, debugging memory failures becomes guesswork. That is why Inspectable Agent Memory treats write events and retrieval traces as part of the same audit surface.
What should you read next?
Read Memory is not RAG is not fine-tuning, Types of agent memory, and How to delete a specific memory. The failure-mode catalog maps write-path bugs to symptoms.