Context Engineering vs RAG: How They Relate
What RAG Actually Is
RAG addresses a specific problem: a model does not know your private or current data, so before answering you retrieve the relevant documents and add them to the prompt. The classic pipeline embeds your documents into a vector store, embeds the user's question, finds the passages most similar to the question, and places those passages in the window so the model answers from them rather than from its training. It is a powerful and widely used technique, and for question answering over a document corpus it is often the right core approach. The mechanics are covered in the vector search and embeddings pillar.
What RAG does, in the vocabulary of context engineering, is selection: it chooses which knowledge to bring into the window for the current request. That is one of the four context strategies, and it is an important one, since selection is where much of context quality is decided. But it is one strategy, applied to one source of context, documents, and it says nothing about the other sources or the other strategies.
What Context Engineering Adds
Context engineering manages the whole window, so it covers everything RAG leaves out. RAG retrieves documents, but it does not decide how to handle a conversation history that grows past the budget, that is compression of history. RAG does not persist what a user told you across sessions, that is a memory layer doing write and select on accumulated facts. RAG does not allocate the token budget across documents, history, instructions, and tool results when they compete for space, that is the budgeting that context engineering imposes. RAG does not split a complex task across focused windows, that is isolation. A system can have excellent RAG and still fail because its conversation overflows the window or it forgets the user between visits.
The relationship is cleanest stated as containment: RAG is the document-selection component of a context pipeline, and context engineering is the pipeline. When people say context engineering is bigger than RAG, this is what they mean, not that RAG is obsolete, but that retrieving documents is one of several jobs the window-management system has to do. The principles of context engineering place selection alongside write, compress, and isolate to make this concrete.
RAG is the selection step for documents inside context engineering, not an alternative to it. Excellent RAG with no history management, memory, or budget discipline is still only part of a context pipeline, and it will fail on the parts it does not cover.
RAG, Memory, and the Difference Between Them
A frequent point of confusion is the line between RAG and memory, since both retrieve information into the window. The difference is the source of the information. RAG retrieves from a corpus of documents that exists independently of the conversation, a knowledge base, a product manual, a set of policies. Memory retrieves facts the system itself accumulated, what the user said, what an agent learned, the outcome of a past interaction. RAG answers what do the documents say, memory answers what do we know about this user and this history.
Both are selection in the context-engineering sense, applied to different sources, and a complete system usually needs both. A support assistant uses RAG to pull the relevant policy and memory to recall that this specific customer has an enterprise plan and a prior complaint. The two complement rather than compete, and a memory layer like Adaptive Recall handles the accumulated-facts side with confidence scoring so that the select step prefers well-supported memories over stale ones. The broader question of how memory fits the discipline is covered in whether memory is part of context engineering, and the alternatives to classic document RAG are covered in beyond RAG.
When RAG Alone Is Enough
Plain RAG, with light context management around it, is genuinely sufficient for a class of applications: stateless question answering over a document corpus, where each query is independent, there is no user identity to remember, and answers are short enough that history never threatens the budget. A documentation search bot that answers one self-contained question at a time does not need much beyond good retrieval. Recognizing this case matters, because adding memory, agents, and elaborate budgeting to a problem that does not need them is wasted complexity.
The moment the application becomes multi-turn, personalized, agentic, or long-running, RAG alone stops being enough and the rest of context engineering becomes necessary. Conversations need history management, returning users need memory, agents need write and isolate, and any of these can overflow the budget without explicit allocation. The practical signal is simple: if your system has any state that should persist or grow, you have moved past pure RAG into context engineering, and you should design the window as a whole rather than just the retrieval step.
Use plain RAG for stateless question answering over documents. The moment your system is multi-turn, personalized, agentic, or long-running, you need the rest of context engineering: history management, memory, budgeting, and isolation, with RAG as one component inside it.
How RAG Improved as Context Engineering Matured
The framing of RAG as one component inside context engineering also explains how RAG itself got better. Early RAG was a single embed-retrieve-stuff step, and its weaknesses, retrieving loosely relevant chunks, including too many of them, ignoring freshness, were exactly the context-engineering failures of poor selection and low relevance density. As teams adopted the broader discipline, RAG absorbed its lessons: reranking was added to turn raw similarity into true relevance, hybrid search combined semantic and keyword matching for better recall, and chunk trimming and filtering raised the density of what reached the window. Modern RAG is essentially a well-engineered selection step, which is to say RAG improved by becoming better context engineering.
This is why arguments about RAG being dead or RAG versus long context windows are mostly confused. Retrieval is not a passing technique that a bigger window replaces, it is the selection strategy, and selection is permanent because relevance density beats raw volume regardless of window size. What changes is how retrieval is done and what else surrounds it, not whether you need to choose what goes in the window. Seeing RAG as the selection component of context engineering dissolves these debates: you will always need to select, the question is only how well you do it and what other strategies you pair it with.
A Practical Way to Combine Them
In a real system, RAG and the rest of context engineering compose cleanly when you treat them as separate budgeted sources feeding one window. The retrieval step produces its best few document passages within its token allocation. The memory layer produces its most relevant accumulated facts within its allocation. History management produces a compact recap of the conversation within its allocation. The assembly step then combines these alongside the system instructions into the final window, in a fixed order, within the overall budget. Each source does its own selection, and the budget arbitrates between them when they compete.
This composition is what a mature context pipeline looks like, and it makes RAG a peer of memory and history rather than the whole system. It also makes each part independently improvable: you can upgrade the reranker in the RAG path without touching memory, or improve memory's confidence scoring without touching retrieval. The page on building a context pipeline walks through assembling these sources, and the role of the memory peer specifically is covered in whether memory is part of context engineering.
The terminology is worth getting right because it shapes how teams scope their work. A team that says we are building a RAG system tends to scope the project as retrieval and stop there, leaving history, memory, and budgeting as afterthoughts that surface as bugs later. A team that says we are doing context engineering, with RAG as our document-selection step, scopes the whole window from the start and treats retrieval as one of several sources it must manage. The second framing produces more complete systems, not because the work is different, but because naming the discipline correctly makes its full scope visible. RAG is not wrong as a term, it is just narrower than the problem most teams are actually solving, and adopting the broader frame is what keeps the parts RAG does not cover from being forgotten until they fail.