Your RAG Pipeline Is Not a Search Feature. It Is a Context Supply Chain. Enterprise AI fails when context arrives stale, unauthorized, noisy, incomplete, or impossible to audit. Govern the supply chain, not just the model.
Executive answer
Most enterprise RAG diagrams look suspiciously tidy: documents enter a vector database, a query retrieves a few chunks, and a model produces an answer. There may even be three tasteful arrows, which is how architecture diagrams traditionally declare victory.
Production is less cooperative. The source document may be outdated. The user may not be entitled to see it. A newer policy may live in another system. The retrieved passage may be relevant but incomplete. An MCP tool may expose live state, but the agent may invoke it under the wrong identity. Memory may preserve something that should have expired. A correct answer can become wrong between retrieval and action.
That is why senior leaders should stop treating RAG as a search feature. It is a context supply chain: the end-to-end system that discovers, qualifies, authorizes, transforms, assembles, delivers, observes, and retires the information an AI system uses to reason and act.
The timing matters. The Model Context Protocol's July 28, 2026 specification moved to a stateless protocol core and added header-based routing, cacheable list results, authorization hardening, and a formal extensions framework. [1] Those are meaningful infrastructure advances. They also make the leadership question sharper: now that context and tools can move more easily, who proves that the right context reached the right agent, for the right purpose, under the right authority?
The answer is not a longer system prompt. It is an operating model with product ownership, contracts, lineage, policy enforcement, evaluation, and service-level objectives for context itself.
Begin with why, not with embeddings
Before selecting a vector database, graph store, embedding model, reranker, memory framework, or MCP server, answer five questions: Why are we building this capability? What measurable business value should it create? Which decision or workflow is failing today? What happens if we do nothing? Is AI actually required?
These questions sound obvious because they are. They are also routinely skipped because discussing chunk size feels more technical than admitting nobody owns the outcome.
A customer-service assistant may need to reduce verified resolution time without increasing reopen rates. An engineering knowledge agent may need to shorten time to a correct production diagnosis without leaking restricted incident data. A content system may need to improve answer coverage while preserving editorial authority, freshness, and source attribution. Each outcome implies a different context supply chain.
If ordinary search, deterministic rules, or a workflow redesign solves the problem, use them. AI is valuable when it can synthesize ambiguity, reason across sources, or choose among tools in ways fixed logic cannot economically support. It is not a mandatory decorative layer between a user and a database.
Context engineering is bigger than prompt engineering
Prompt engineering shapes instructions. Context engineering shapes the model's operating reality: system instructions, retrieved evidence, tool definitions, permissions, user state, conversation history, memory, intermediate results, and the rules for selecting among them.
Anthropic describes context as a finite resource and recommends finding the smallest set of high-signal tokens most likely to produce the desired outcome. It also notes "context rot": recall can degrade as more tokens are added, so a larger context window does not remove the need for curation. [2] OpenAI's February 2026 account of harness engineering makes a similar practical point: more context should mean organizing and exposing the right information, not overwhelming an agent with ad hoc instructions. [3]
This changes the architecture conversation. The unit of quality is no longer simply "Did retrieval return a semantically similar chunk?" It becomes: Was the source authoritative for this decision? Was it current at the moment of use? Was the requesting identity entitled to receive it? Did the context include enough evidence to answer completely? Was irrelevant material excluded? Can we reconstruct what the agent saw and why? Did the resulting action remain within policy?
That is a supply-chain problem. Information has origin, custody, transformations, expiry, consumers, defects, and recall procedures. Calling it "just RAG" is like calling an airport "a runway." Technically present, operationally unhelpful.
The eight stations of a context supply chain
1. Outcome contract Define the decision or task, the eligible users, the value measure, and unacceptable failures. An answer for casual discovery can tolerate uncertainty that a claims decision, production change, or compliance response cannot.
The outcome contract should specify whether the system may answer, recommend, prepare an action, or execute one. Context requirements follow authority. The more consequential the action, the stronger the source, identity, freshness, and evidence controls must be.
2. Source authority Inventory sources by system of record, owner, jurisdiction, audience, sensitivity, and effective dates. A policy PDF, CRM record, application log, wiki page, and analyst note are not interchangeable simply because all five contain the word "coverage."
Establish precedence rules. When two sources conflict, the agent should not improvise democracy. It should know which source governs, whether the conflict requires escalation, and how to explain the limitation.
3. Ingestion and normalization Preserve meaning while transforming content. Extract structure, identifiers, headings, tables, relationships, dates, and access metadata. Record the parser and transformation version. A chunk without lineage is an anonymous witness: possibly useful, rarely sufficient.
Chunking should follow the information shape. Fixed windows can work for uniform prose. Policies may require section-aware chunks. Product catalogs may need entity records. Multi-hop questions may benefit from graph relationships. Microsoft describes graph-augmented RAG as combining vector search with knowledge-graph traversal for queries involving entities, citations, causal chains, and multi-hop reasoning. [4] That is a pattern, not a commandment; a poor graph is merely structured confusion.
4. Identity and policy filtering Apply authorization before sensitive content enters model context, not after the answer is generated. Carry the initiating user or workload identity through retrieval and tool calls. Enforce purpose, tenant, geography, data class, and action scope.
CoSAI's January 2026 MCP security paper identifies twelve threat categories and almost forty threats across MCP deployments, including supply-chain, identity, access-control, and resource-exhaustion risks. It recommends end-to-end traceability and least privilege. [5] The NSA's May 2026 MCP security guidance likewise treats MCP as a significant automation boundary, not a friendly plugin socket. [6]
5. Retrieval and ranking Use the simplest retrieval method that meets the outcome. Keyword search handles exact terms. Vector search handles semantic similarity. Hybrid retrieval combines both. Graph traversal helps with explicit relationships. Filters enforce identity, dates, product, region, and document state. Reranking can improve precision when the initial candidate set is broad.
Do not optimize retrieval in isolation. A high retrieval score can still produce an incomplete answer or an unsafe action. Evaluate against the user's task and the business error cost.
6. Assembly and compression Select, order, deduplicate, summarize, and label context within a deliberate budget. Separate instructions from evidence and untrusted content. Preserve citations and validity windows. Explain omissions when they matter.
For long-running work, use compaction, structured notes, durable state, or explicit artifacts rather than dragging the entire conversation behind the agent like a suitcase with a broken wheel. MCP's 2026 stateless core reinforces this design direction: application state can remain explicit rather than hiding inside transport sessions. [1]
7. Delivery and tool mediation MCP standardizes how applications connect models with external data and tools. The July 2026 release adds metadata useful for routing and metering, cache hints for discovery results, and stronger authorization behavior. [1] It does not decide whether a particular tool is safe for a particular user, whether its output is trustworthy, or whether the agent should be allowed to act.
Put gateways, policy checks, rate limits, schema validation, and approval gates around tool execution. Treat tool descriptions and responses as attack surfaces. OpenAI's March 2026 prompt-injection guidance argues that defense cannot rely only on detecting malicious input; systems should constrain the impact even when manipulation succeeds. [7]
8. Observation, evaluation, and retirement Trace the context package: source IDs, versions, access decision, retrieved candidates, selected evidence, tool calls, model version, output, and outcome. Retire stale embeddings, revoked content, expired memories, and deprecated tools. Support targeted re-indexing and deletion.
Microsoft recommends evaluating RAG with multiple measures such as groundedness, completeness, utilization, relevance, and correctness, while adding tool-selection accuracy, retrieval efficiency, and end-to-end latency for agentic RAG. It also emphasizes repeated evaluation as documents and user questions change. [8]
Why more context can make the answer worse
Leaders often assume model errors can be solved by sending more documents. That can fail in four ways.
Attention dilution: relevant evidence competes with redundant or tangential material. The model has more to read and less reason to focus on the governing passage. Authority collision: an approved policy and an old draft appear together without precedence metadata. The model synthesizes both into an answer no human ever authorized. Security expansion: every additional source or tool increases exposure to sensitive data, malicious instructions, compromised connectors, and excessive authority. Cost and latency: longer contexts, more retrieval steps, and verbose tools consume tokens and time. The organization pays to make the model work harder at deciding what to ignore.
The architecture principle is not "less context" in the abstract. It is minimum sufficient, policy-valid context: enough evidence to complete the task, no more authority or information than necessary, and enough provenance to defend the result.
A hypothetical failure: the correct answer from the wrong policy
Consider a hypothetical insurance service agent asked whether a customer is eligible for a particular benefit. Retrieval returns a highly similar policy document. The model quotes it accurately and explains the answer clearly. The response is grounded. It is also wrong.
The document was superseded three months earlier. The newer version used different terminology, so semantic ranking favored the older text. Both were in the index. No effective-date filter ran. The citation opened correctly. Every dashboard was green because the system had answered from the context it received.
This is not primarily a hallucination. It is a context supply-chain defect.
The repair is not "improve the prompt." It is to model effective dates and policy status, enforce source precedence, filter before ranking, create evaluation cases around superseded content, monitor freshness lag, and make the answer expose the governing version. If the decision carries material consequence, the workflow may also require human confirmation.
The example matters because it shows why groundedness alone is insufficient. A model can be perfectly faithful to bad evidence. Enterprise reliability requires groundedness to authoritative, current, permitted evidence.
What enterprise platform work teaches about context
Across more than 15 years working with full-stack and enterprise systems - including .NET and C#, React, Node.js, Next.js, content platforms, integrations, analytics, performance, SEO/AEO, RAG and MCP work, and engineering leadership - I have learned that information quality is rarely a single-component problem.
A content page has an owner, publication state, taxonomy, canonical URL, audience, analytics trail, and lifecycle. An integration has identity, contracts, retries, observability, and failure handling. A production AI context layer inherits both sets of concerns. It must treat knowledge as governed content and retrieval as an operating integration.
That is also why SEO and AEO experience is relevant to enterprise AI architecture. Search systems have always forced us to ask whether content is discoverable, authoritative, structured, current, and understandable. Context engineering adds a stricter question: should this specific agent receive this specific information now, and what may it do because of it?
A practical 90-day plan
Days 1-15: Map one consequential workflow
Choose one decision or task with measurable value. Identify the user, authority level, source systems, business owner, error cost, and consequence of doing nothing. Record the five leadership answers and define unacceptable outcomes.
Days 16-30: Build the source and policy registry
For each source, capture owner, system of record, effective dates, sensitivity, entitlement logic, jurisdiction, refresh expectation, and precedence. Identify where deletions and revocations must propagate. Do not index first and invent governance later; that is how archaeological projects begin.
Days 31-50: Establish the context contract
Define the package delivered to the model: instructions, identity, task state, evidence, citations, tool catalog, memory, and allowed actions. Specify token budgets, freshness thresholds, required metadata, conflict behavior, and escalation rules. Version the contract.
Days 51-70: Create an adversarial evaluation set
Test missing evidence, conflicting sources, expired policies, unauthorized documents, poisoned instructions, ambiguous identities, tool failures, excessive results, and questions requiring abstention. Include real production question patterns after removing sensitive content. NIST's Generative AI Profile recommends reassessing risks after RAG implementation and documenting sources, adaptations, and ongoing monitoring. [10]
Days 71-90: Operate the supply chain
Release gradually. Trace each stage. Measure the scorecard by use case, role, and risk tier. Assign owners for source quality, retrieval, policy, tool integrations, evaluation, and incident response. Review failures as supply-chain defects, not merely model quirks. Scale only when the end-to-end task outcome and guardrails pass.
Counterarguments worth taking seriously
"This is too much platform for an early use case." It can be. Begin with the smallest controls proportional to consequence. A low-risk internal assistant does not need the same machinery as an agent changing customer records. But source ownership, access control, lineage, and a basic evaluation set are not enterprise extravagances.
"Better models will make context engineering less important." Better models can reason more effectively and tolerate messier input. They do not know which internal policy is legally effective, who may see a record, or which action the business authorizes. Capability reduces some orchestration; it does not replace organizational truth.
"Our data platform already governs this." Good. Reuse it. But verify that entitlements, lineage, freshness, deletion, and purpose restrictions survive transformation into embeddings, caches, memory, tool responses, and prompts. Governance that stops at the warehouse door is mostly interior decoration.
"MCP solves the integration layer." It standardizes an important interface. It does not own source authority, enterprise identity design, content quality, tool risk, evaluation, or business accountability. A standard socket is useful. It is not an operating model.
Conclusion: context is the product the model consumes
The model is only one participant in an enterprise AI system. Its output depends on an upstream chain of source decisions, identity, permissions, retrieval, transformation, memory, tools, and policy. If that chain is invisible, the organization cannot reliably explain a correct answer, repair a wrong one, or contain a manipulated action.
Begin with why. Name the decision and value. Decide whether AI is required. Then build the smallest context supply chain that can deliver authoritative, current, permitted, sufficient evidence and prove what happened.
RAG is not dead. It has simply grown up, acquired dependencies, and started attending governance meetings. Treat context as a product, and the model becomes a more useful component. Treat it as a bag of chunks, and sooner or later the bag will make a decision on your behalf.
