RAG isn't dead, it just got rebranded as context engineering
RAG didn't die — it got rebranded as "context engineering." Kinda...
The AI terminology treadmill moves fast, but this particular rebrand tells us something real about where enterprise AI infrastructure is heading.
Richard MacManus at The New Stack has a solid piece tracking the evolution from RAG (Retrieval-Augmented Generation) to "context engineering" — built around a conversation with Douwe Kiela, CEO of Contextual AI and co-author of the original 2020 RAG paper.
Kiela's framing is refreshingly honest: "I think people have rebranded it now as context engineering, which includes MCP and RAG. The 'R' in RAG just stands for 'retrieval.' So if you're using MCP to do your retrieval, then it's basically RAG, right?"
That's the right way to think about this. RAG didn't die. It got absorbed into a broader architectural concept. And that absorption matters for product counsel and AI governance teams, because "context engineering" isn't just a vocabulary swap — it describes a fundamentally wider attack surface.
What context engineering actually means for governance
Anthropic's explanation from last September is the clearest framing: context engineering is "the natural progression of prompt engineering." Instead of crafting individual prompts, engineers now manage the entire context state — system instructions, tools, MCP connections, external data sources, message history, and more.
For product teams, that translates to a shift in what you're actually governing. When the scope was prompt engineering, you were worried about what users typed into a box. When the scope became RAG, you were worried about what documents got retrieved and fed to the model. Now, with context engineering, you're responsible for the entire information pipeline — every data source hooked into the system, every tool the agent can invoke, every piece of message history that persists across turns.
That's not a branding exercise. That's a material expansion of the compliance perimeter.
The enterprise wrapper problem
Contextual AI's new Agent Composer product highlights another trend worth watching. Kiela positions it against tools like Claude Code and Cursor by drawing a distinction between "harnesses" (wrappers around a single model, often running locally on a developer's machine) and centrally hosted, enterprise-grade orchestration layers.
The governance implication is straightforward: when developers build agents using Claude Code on their laptops, the enterprise has limited visibility into what data sources are connected, what tools are invoked, and what context persists across sessions. When that same workflow runs through a centralized platform with guardrails and orchestration, you get auditability.
This is the same pattern we've seen play out with shadow IT for years, now replicated in the agent layer. The question for legal and compliance teams isn't whether developers are building agents — they are. The question is whether those agents are running through infrastructure that gives you any ability to monitor, audit, and enforce policy.
The just-in-time tradeoff
One of the more technically interesting points in the piece is Kiela's explanation of the pre-processing versus just-in-time tradeoff in context engineering. Some use cases demand heavy upfront document ingestion for speed. Others can afford to be "agentic" — running multiple retrieval attempts at query time to find the right information.
For legal teams advising on AI product design, this tradeoff has direct implications for data minimization and purpose limitation. A system that pre-processes and indexes everything upfront looks very different from a privacy perspective than one that retrieves specific documents just-in-time based on the query. The architectural choice shapes the compliance posture, and most product counsel aren't in the room when that decision gets made.
The root cause analysis use case
Contextual AI's focus on "hard engineering" customers — semiconductor companies, for instance — surfaces a use case that's going to become common across industries: agentic root cause analysis. An agent takes log dumps, cross-references internal documentation and bug reports, identifies the root cause of a failure, and potentially opens a pull request to fix it.
That's a powerful workflow. It's also one where the agent is ingesting potentially sensitive operational data, traversing multiple internal knowledge bases, and taking autonomous action on a codebase. Every step in that chain raises questions about access controls, data classification, and accountability for the agent's conclusions.
What this means for product counsel
The rebrand from RAG to context engineering isn't just marketing. AI systems are no longer retrieving documents from a single knowledge base and stuffing them into a prompt. They're managing complex, dynamic information pipelines that span multiple data sources, tools, and interaction histories.
For product counsel and AI governance professionals, that means the frameworks we built around RAG — focused on retrieval accuracy, source attribution, and document-level access controls — need to expand. Context engineering demands governance of the entire pipeline: what data sources are connected, what tools agents can invoke, how context persists and evolves across sessions, and who has visibility into all of it.
The terminology will keep changing. The underlying challenge — governing increasingly autonomous systems that consume and act on enterprise data — will not.
Richard MacManus
