Short answer: RAG is a major technique inside context engineering: retrieve useful text, then put it in the prompt.
The terms are often mixed up. Context engineering covers selection, budget, assembly, tools, and system prompts. RAG specifically bridges stored knowledge into the window. It is central, not the whole discipline.
Multi-agent systems showed how context engineering’s principles extend beyond a single reasoning process. Retrieval-augmented generation, or RAG, is a term that predates “context engineering” as a phrase and is often used almost interchangeably with it, which causes real confusion. The two aren’t synonyms, and clarifying exactly how RAG fits inside the broader discipline this Part has been building resolves a question that comes up constantly once someone has learned both terms.
What Is RAG, Specifically, as Opposed to the Broader Discipline Around It?
RAG is a specific technique: retrieve relevant documents from an external knowledge source based on a query, then generate a response using those retrieved documents as grounding material. It has a clear, well-defined shape, an ingestion stage that prepares and embeds source documents, and an inference stage that retrieves, augments the prompt, and generates. This shape works exceptionally well for one particular problem: giving a model access to a body of knowledge it wasn’t trained on, without having to retrain it every time that knowledge changes.
Context engineering, as covered throughout this Part, is broader than this one technique. It includes retrieval, but also memory, tool use, agent orchestration, query augmentation, and prompting, working together as a coordinated system rather than one specific retrieve-then-generate pipeline applied to a document store.
Is RAG Simply One of the Six Pillars Already Covered, or Something Different?
RAG maps most directly onto the retrieval pillar, but it isn’t purely identical to it, because RAG as a named technique typically implies a specific architecture, a document knowledge base, an embedding-based similarity search, and a generation step conditioned on what comes back. Retrieval as a context-engineering pillar is more general: it covers pulling any kind of external information into context, whether that’s a document from a knowledge base, a fact from a memory store, or a result from a live API call. RAG is a well-known, specific instance of the retrieval pillar, not a synonym for the whole pillar or for the entire discipline surrounding it.
This distinction matters because a system doing memory retrieval, the kind covered extensively in earlier Parts of this knowledge base, is doing something structurally very similar to RAG, pulling relevant external content into context before generating, even though the source is a personal memory store rather than a static document collection.
How Does Applying RAG’s Pattern to Personal Memory Differ From Applying It to Static Documents?
Classic RAG typically retrieves from a relatively stable knowledge base, documents that get updated periodically but don’t change moment to moment based on who’s asking. Memory retrieval, as covered throughout this knowledge base, pulls from a store that’s dynamic, personal, and scoped to an individual, constantly updated as new facts get extracted and reconciled. Both share the identical underlying mechanic, embed a query, find similar content, inject it into context, but the source they’re drawing from behaves very differently: one is a shared, relatively static reference, the other a private, continuously evolving personal record.
This means memory-backed systems inherit both the strengths and the specific failure modes already covered for RAG, retrieval quality determining output quality, poor chunking or scoping degrading relevance, but layered on top of memory’s own additional concerns, like reconciliation and scoping, that a static document knowledge base never has to deal with.
Does a System Have to Choose Between RAG Over Documents and Retrieval From Memory, or Can Both Coexist?
Both coexist constantly in real systems, and treating them as separate, unrelated sources being combined into one context window is exactly how a well-built system should work. A shared knowledge base of general reference documents and a personal memory store scoped to an individual answer genuinely different questions, general facts everyone should know versus specific facts relevant to this one person or situation, and a well-assembled context window frequently draws on both at once, clearly labeled so the model understands which source each piece of information came from.
How Does Weaviate Engram Fit Alongside Traditional Document-Based RAG?
Weaviate Engram supplies the memory side of this combination, while Weaviate’s broader collection and search capabilities can simultaneously supply the classic RAG side, retrieving from a shared, general knowledge base. Consider a customs and import-compliance assistant helping freight forwarders navigate regulations, where general regulatory documents and a specific importer’s own history both need to inform the same response:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"This importer has had two prior shipments flagged for incomplete country-of-origin documentation on textile goods specifically.",
user_id="importer-8843",
)
A general regulatory question about textile tariff classifications would be answered through classic RAG over a static, shared knowledge base of customs regulations, the same documents every importer’s questions would draw from. This importer’s own specific compliance history, by contrast, comes from Engram’s personal memory search:
importer_history = client.memories.search(
query="Has this importer had documentation issues with textile shipments before?",
user_id="importer-8843",
retrieval_config=HybridRetrieval(limit=5),
)
Combining both sources, the general regulatory guidance from a classic RAG pipeline over shared documents, and the importer-specific history from Engram’s memory search, lets the assistant tell this importer not just what the regulation generally requires, but that their own documentation practices specifically need extra attention given their own track record. Neither source alone would produce that complete a response. This is exactly the relationship worth understanding: RAG and memory retrieval share the same underlying mechanic but serve different sources, and context engineering is the discipline of combining both, along with everything else covered in this Part, into one coherent response.
RAG and memory retrieval both pull content into a context window before generation happens. A related but distinct question is whether that content should be assembled the same way every time, or whether it should shift based on what’s actually happening in the moment. Our next chapter, What is the difference between static and dynamic context?, takes up exactly that distinction.