AI Memory and Curated Context
What's the difference between AI memory and RAG?
The confusion usually starts in implementation. A team decides their agents need context, builds a RAG pipeline over their documentation, and describes the result as giving the agents 'memory.' The terms blur because both affect what an agent knows during a session. But they are architecturally different, and the difference matters when something goes wrong.
What RAG is
RAG — retrieval-augmented generation — is a mechanism for fetching relevant content from a document corpus at the moment an agent needs it. When a user asks a question or an agent begins a task, the system searches the corpus, surfaces the most relevant documents or passages, and includes them in the agent's context window.
RAG has no persistence. The same document is retrieved fresh every time it's relevant. Nothing is stored from one interaction to the next. If the corpus doesn't change, the retrieval results don't change — regardless of what happened in prior sessions. RAG is stateless by design: its job is breadth of access, not continuity over time.
The constraint that comes with that design is also its definition. RAG can only surface what has been written down and indexed. It is a retrieval mechanism, not an authorship mechanism. The quality of what it returns depends entirely on what went into the corpus in the first place.
What Memory is
Memory, in the context of AI agents, refers to persistence — the ability to retain information across interactions. Session memory tracks what was said in a conversation; longer-term memory stores it across sessions. Memory has no retrieval in the RAG sense.
It records what happened — the conversation, the instruction, the correction — rather than providing access to a broader corpus. An agent with strong session memory knows exactly what you told it last Tuesday. It doesn't, on that basis, know anything about the rest of your document library.
Where RAG optimises for breadth — giving agents access to the widest possible relevant content — memory optimises for continuity. They are answering different questions: RAG answers 'what exists that's relevant?'; memory answers 'what has happened that matters?'
Why the Conflation Causes Problems
Treating RAG as the memory solution leads to a predictable failure mode. The team implements RAG, session memory, or both — and assumes the context problem is solved. Agents can retrieve relevant documents and recall prior conversations. What they still cannot do is tell you what the organisation has actually decided, what constraints it has committed to, or why the pricing rules changed three months ago.
That knowledge was never in the corpus. It was never spoken into a session. It exists — but it exists in the reasoning behind decisions that were made in meetings and stayed there. The constraint that the sales team should stop pursuing contracts below a certain revenue threshold. The decision to pause two product features pending a strategic review. The kind of things that everyone on the team understands but nobody wrote down formally — and that no document in the corpus reflects.
RAG tells an agent what to look up. Memory tells it what happened. Neither tells it what to know.
The Third Category
The gap neither RAG nor session memory is designed to fill is the authored record of what an organisation has deliberately decided and committed to — the knowledge that needs to exist before an agent acts, not be retrieved from a corpus or recalled from prior exchanges.
This is a different kind of problem. Indexing more documents doesn't solve it, because the knowledge isn't in the documents. Better session memory doesn't solve it, because the knowledge was never surfaced in a session. It requires deliberate authorship: the knowledge has to be captured intentionally, given structure, and made available to agents as operating context rather than retrieved content.
RAG and memory are complementary to this — not competing with it. An agent working from authored organisational context still benefits from RAG to access relevant documents and from session memory to maintain conversational continuity. The three layers serve different purposes and work alongside each other.
Engramic's approach
How Engramic Approaches it
There are multiple ways to address the authored context gap. This is one approach.
Engramic is designed specifically for the third category. It doesn't replace RAG or session memory — those problems are well-served by existing frameworks. Its function is to give agents the organisational context that neither can provide: the goals, constraints, and decisions an organisation has deliberately authored before its agents act. That context is structured so agents can navigate it at decision time, and preserved so it can be traced when a decision needs explaining — not reconstructed from whatever evidence survives.