RAG vs context engineering.

The short answer

RAG is a technique — fetch some text, stuff it into a prompt, hope the model uses it. Context engineering is a discipline — decide what your AI system needs to know about your business, model that meaning, govern it, and serve it (via RAG, structured retrieval, tools, or all three).

RAG without context engineering is a faster way to be wrong. Context engineering without retrieval is a book on a shelf. You need both.

Side by side

• Scope. RAG: one technical pattern. Context engineering: a whole discipline.
• Inputs. RAG: text chunks. Context engineering: metrics, entities, relationships, policies, history.
• Quality bar. RAG: top-k similar text. Context engineering: correct meaning, by company definition.
• Failure mode. RAG: relevant-looking nonsense. Context engineering: catches it before it ships.
• Who owns it. RAG: an ML engineer. Context engineering: a cross-functional team with a context engineer at the center.

When RAG is enough

Short-lived prototypes. Document Q&A over a small, stable corpus. Internal search. Anything where "find a passage that probably answers the question" is the actual job.

When you need context engineering

Anywhere meaning matters: analytics agents, customer-facing assistants, anything touching money, contracts, or compliance. The moment a wrong-but-fluent answer is more dangerous than no answer, RAG alone is not enough.

How to combine them

Treat RAG as one client of your context layer. Retrieve text, but ground it in entities and metrics. Pair vector search with structured lookups. Evaluate against your business definitions, not against vibes. The book covers this stack in Chapters 6 through 9.