# Context Engineering vs RAG ## What actually goes in the window, and who decides > RAG gets material in. Context engineering decides what earns the room. The distinction sounds academic until quality starts falling as your context window fills. Source: https://mrova.rocks/blog/context-engineering-vs-rag Published: 2026-07-16 Author: Sunny Luthra · mRova (https://mrova.rocks) Tags: AI, Agents, Architecture --- A team ships a RAG pipeline. Hybrid search, reranking, the works. Early results are good. Then sessions get longer, quality drifts downward, and the conclusion forms: the model degrades over long contexts. Sometimes it does. More often nobody ever decided what should be in the context in the first place — things simply accumulated there, and retrieval kept adding more. ## The two jobs Retrieval answers: *what material is relevant to this request?* Context engineering answers: *given everything competing for room — instructions, tool definitions, conversation history, retrieved chunks, memory, prior tool output — what actually goes in, and what gets dropped?* The second question contains the first. [Context engineering is the practice of deciding what the full context the model sees actually contains, of which retrieval is one input](https://sourcegraph.com/blog/context-engineering). A team can run a state-of-the-art retrieval stack and still fail because it has no memory layer, an overloaded tool set, or bad token-budget hygiene. In [the harness model](/blog/harness-engineering) these are deliberately separate primitives — **context delivery** (getting the right material in front of the model at the right moment) and **context management** (protecting the model's attention through retrieval and re-ranking, summaries, compaction, prompt caches). Teams that treat them as one thing build the first and skip the second, which is exactly the failure above. ## Why a bigger window does not solve it The intuitive fix for context problems is more room. It helps less than expected, because the constraint was never purely capacity. Every token in the prompt is active state, and it runs on a budget. That budget is attention, not just tokens. Material that is present but irrelevant does not sit inertly — it competes. Filling a very large window with everything available reliably performs worse than sending a well-chosen fraction of it. So a larger window changes what *fits*. It does not change what *deserves to be there*, and that decision still has to be made by something. ## Four things that are not one thing The other reason "just add memory" fails is that memory is four distinct systems with distinct failure modes. **Working memory** is the desk — the current request, visible conversation, this turn's tool results. It runs on the token budget and vanishes when the session ends. **Episodic memory** is the diary — timestamped events. *Last Friday's check found no approval comment on issue #9.* It is what lets an agent resume rather than restart. Its limit is worth saying out loud: the past session reports what happened last time; it cannot report what is true now. **Semantic memory** is the fact sheet — timeless claims with no timestamp. *The app root is `meteor/league`.* Its failure is the quiet one: facts go stale and contradict, and without conflict handling an old truth sits beside a new one as an equal. **Procedural memory** is the runbook — knowing *how* rather than *that*. Checklists, skills, tool schemas. Storing all four buys nothing on its own. Durable stores are a filing cabinet; none of it matters until the right slice reaches the window at the right moment. That retrieval-rank-assemble step is the actual engineering, and it is where most memory implementations stop. ## Forgetting is a feature The half that teams almost never build is deletion. A system that remembers everything eventually remembers too much. Temporal decay, contradiction handling, compression and manual curation exist so obsolete information stops outranking current truth. Without them a memory store degrades monotonically: every week it holds more, and every week a larger share of what it holds is wrong. Teams build the write path first and the forget path never, then describe the result as the model getting confused. ## What to do about it If quality falls as your sessions grow, the questions in order: 1. **What is in the window right now?** Log it. Actually read one. Most teams have never looked at a full assembled context and are surprised by what is in there. 2. **What is competing?** Tool definitions and system instructions are often a large fixed cost nobody has measured. 3. **What drops when it is full, and who decided?** If the answer is "the oldest thing, by default", that is a policy you inherited rather than chose. 4. **What forgets?** If nothing does, the store will get worse from here. None of those require a model upgrade, and all four are cheaper to answer now than after the next feature lands on top. --- ## Frequently asked questions ### What is the difference between RAG and context engineering? RAG retrieves relevant material and puts it in the prompt. Context engineering decides what the full context contains — retrieved chunks, instructions, tool definitions, history and memory — and what gets dropped when they compete for room. Retrieval is one input to that decision. ### Why does quality drop as a session gets longer? Because every token in the window is active state competing for attention. Without compaction, ranking or forgetting, useful material gets crowded out by accumulated history that nobody decided to keep. ### Do I still need RAG if I have a long context window? Yes. A larger window changes what fits, not what deserves to be there. Filling a million tokens with everything available reliably performs worse than sending the right ten thousand.