A retrieval pipeline will happily return five documents that contradict each other. It has no opinion about which one your finance team actually signed off on. That gap — between finding text and knowing what is true — is where most enterprise AI projects quietly fail.
We spent the better part of a year watching this pattern repeat across data teams. The setup is always the same: someone stands up a RAG pipeline, indexes the wiki and a few thousand Slack messages, wires it to a model, and demos something impressive. Three weeks later the CFO asks why the assistant said churn was 4.2% when the board deck says 6.1%.
Retrieval is a search problem. Definitions are a governance problem.
RAG optimises for semantic similarity. Given a query about churn, it will surface the passages most similar to that query. What it cannot do is tell you which passage represents the company's current, agreed-upon definition — because similarity has nothing to do with authority.
In a mid-size company, "churn" plausibly appears in:
- A dbt model that filters out trial accounts
- A Tableau dashboard that includes them
- A Slack thread from eight months ago where the team decided to exclude them, which nobody wrote down
- A Confluence page written before the pricing model changed
- Three different SQL queries in someone's saved workbook
All five are semantically relevant. Only one is correct today. RAG has no mechanism for expressing that.
What the failure looks like in production
The symptom is rarely a dramatic hallucination. It is a confident, plausible, subtly wrong number — the kind that survives a quick sanity check and shows up in a deck two weeks later.
| Agent | Source it retrieved | Answer |
|---|---|---|
| Support bot | Confluence page (stale) | 4.2% |
| Analytics assistant | dbt model | 5.8% |
| Exec briefing agent | Tableau extract | 6.1% |
None of these agents malfunctioned. Each retrieved a real document and summarised it accurately. The system failed at a level above retrieval.
Structured knowledge, not indexed text
The alternative is to stop treating business logic as unstructured text to be searched, and start treating it as structured knowledge to be governed. Concretely, that means:
- One canonical entry per concept. Churn has exactly one active definition. Previous versions are history, not alternatives.
- Provenance on every fact. Where it came from, who approved it, when it was last verified.
- Conflict detection as a first-class feature. When two sources disagree, that is surfaced for a human to resolve — not silently averaged away by an embedding.
- Scoped delivery. The agent receives the definitions its scope permits, and nothing else.
This is not anti-RAG. Retrieval remains the right tool for open-ended document search — "find me the incident report from March". It is the wrong tool for "what is our revenue formula", which has exactly one right answer and should never be a similarity contest.
What changes in the prompt
With a governed knowledge layer, the context an agent receives stops being a pile of maybe-relevant chunks and becomes a short, verified brief:
The model is no longer reasoning over contradictory inputs, so it stops producing contradictory outputs. The token reduction is a pleasant side effect; the accuracy improvement is the point.
Where this leaves RAG
Retrieval and structured knowledge are complementary layers, not competitors. Use retrieval where the question is genuinely open-ended and the corpus is genuinely unstructured. Use a governed knowledge layer for anything with a defined right answer — metrics, formulas, policies, entity definitions, business rules.
Most enterprise questions turn out to be the second kind. That is the uncomfortable finding, and it explains why so many pilots stall at the demo stage.
Mahari Kalau
Writes about context engineering, agent architecture, and the unglamorous parts of enterprise AI.