Context engineering vs RAG for coding agents

As soon as you start thinking seriously about what an AI agent knows, two terms collide: RAG and context engineering. People use them almost interchangeably, which causes a lot of confusion — because they're not the same kind of thing at all. One is a technique. The other is the discipline that decides when to use it.

Getting the distinction right matters, because it changes how you build an agent's memory. Here's the honest comparison.

What RAG does (retrieve on demand)

RAG — retrieval-augmented generation — is a technique. You keep a store of documents, and when a question comes in, you retrieve the snippets that look relevant and paste them into the prompt before the model answers. The model "reasons over" material it wasn't trained on, fetched fresh for that query.

It's genuinely useful, especially for large or fast-changing bodies of material — documentation, a knowledge base, anything too big to hold in the window. The defining trait: retrieval happens per query, optimised for the question in front of it, and then it's gone.

What context engineering does (curate and keep)

Context engineering is the wider discipline: deliberately deciding what the model should know and shaping it well. Retrieval is one tool it can use — but so is writing things down, structuring them, pruning them, and committing them.

The framing that helps: RAG is a way to fetch context — context engineering is the practice of deciding what context should exist and how it's kept. As the practitioner guides on context engineering put it, the work is assembling, pruning and ordering everything the model sees — retrieval is part of that, not the whole of it.

Stuart Leo

RAG answers "what's relevant to this question right now." Context engineering answers "what should this agent always know, and how do I keep it."

Where they overlap and differ

They overlap in that both put the right information in front of the model. They differ in durability and intent:

	RAG	Context engineering (contextbase)
What it is	A retrieval technique	The discipline of curating what the model knows
Timing	Per query, on demand	Persistent, read before every task
Source	A document store, searched	Curated, version-controlled knowledge
Optimised for	This one question	What the project always needs
Lifespan	Fetched, used, gone	Accrues and compounds
Best for	Large or changing material	Durable decisions, patterns, gotchas

Why code context wants curation, not just retrieval

Here's why this matters for coding agents specifically. The knowledge an agent needs most isn't scattered facts to look up — it's the durable stuff: why auth is built this way, the convention the codebase follows, the gotcha that bit you last week. That knowledge is needed on almost every task, it's high-signal, and it doesn't change query to query.

Retrieving that fresh every time is the wrong tool. It's like re-deriving your own house rules on every decision. This knowledge should be curated and kept — written down once, read every time — not searched for repeatedly. Retrieval shines for the long tail of reference material. It's a poor fit for the core knowledge that's always relevant.

How a contextbase relates to RAG

A contextbase is curated, durable context — the opposite end from RAG's fetch-and-forget. But they compose neatly:

• The contextbase holds the always-needed knowledge the agent reads before every task — decisions, patterns, gotchas, briefs. The compounding memory.
• Retrieval pulls in the large, fast-changing, or long-tail material on demand — API docs, a big reference corpus, things too bulky to keep loaded.

Use the contextbase as the agent's standing memory and retrieval as its lookup. They're layers, not rivals.

RAG fetches context for one answer — a contextbase keeps the context that should never have to be re-fetched.

Start here: read context engineering, explained, what a contextbase is, or read the method.