Skip to content
All posts
RAGarchitecture

RAG retrieves. Review decides what your agent should trust.

Published 7 min read

Retrieval-augmented generation answers an important question: which pieces of available content are relevant to this prompt? It does not automatically answer a different question: which of those pieces should the agent trust? That second question is where ownership, review, approval, access, and revision history enter the architecture.

Teams often discover the distinction after the first agent demo. The vector search works. The model cites a document. Then someone notices that the cited document is two policies old, that another page says the opposite thing, or that the customer-facing agent retrieved an internal exception. Retrieval did its job: it found similar text. The knowledge system had not yet done the job of deciding what was current, approved, and allowed.

RAG is a retrieval pattern, not a truth workflow

A typical RAG pipeline breaks source material into chunks, creates embeddings, finds chunks that are close to the question, and gives them to a model as context. That is useful. It gives the model a chance to answer from material it did not see during training.

But similarity does not establish authority. Two contradictory policy pages can both be highly relevant. A stale pricing sheet can be the closest match. A draft can look exactly like a final answer after it has been chunked. If the pipeline does not carry and enforce status, ownership, classification, and revision metadata, the model receives ambiguity with better search results.

Retrieval answers “what might help answer this?” Curation answers “what has the organization approved as the answer?” A production agent often needs both.

Five controls retrieval does not create for you

1. A named owner

Someone must be accountable for the definition. “Active user” might belong to Product Analytics; refund eligibility might belong to Support Operations. Ownership determines who can resolve a contradiction and who should review the next change.

2. An approval state

A file's presence does not mean it is ready for production. A useful knowledge lifecycle distinguishes draft, in review, approved, and rejected revisions, then makes only the current approved revision retrievable.

3. A revision trail

What a company knows changes. The important question is not whether content was edited, but which revision was current when an agent retrieved it. Stable paths such as policies/refunds.md plus numbered revisions make that investigation possible.

4. An access boundary

Customer-safe guidance and internal exception handling may describe the same topic. Their embeddings will probably be close. Classification and token scope must be enforced before either passage reaches the model; a prompt instruction is not an authorization layer.

5. A correction workflow

When an answer is wrong, a team needs a reliable way to propose a correction, review the diff, approve the replacement, and make that revision available to every connected agent. Re-indexing a folder is not the same operating model.

When a normal RAG pipeline is enough

Not every corpus needs a formal approval gate. Broad research, low-consequence discovery, and large collections of reference material may benefit more from coverage and freshness than from concept-by-concept review. A public documentation assistant can often rely on the publication controls of the documentation site itself.

Add a curated layer when the agent is answering company-specific questions where a plausible but wrong answer creates a real cost. Common examples include:

  • Refund, eligibility, and escalation policies shown to customers.
  • Pricing, packaging, and discount authority used by sales teams.
  • Metric definitions and source-of-truth systems used in decisions.
  • Security, HR, finance, and IT procedures used by internal assistants.
  • Product availability and operating rules that change between releases.

Use curation as a high-trust lane

The practical design is usually not “replace every index.” Keep broad retrieval for exploratory material and create a high-trust lane for the small set of answers an agent must not improvise. Start with the questions that already caused an escalation or failed an evaluation.

In Curated Data, each of those answers becomes a focused concept with an owner, classification, and stable path. A change is a draft until someone approves it. MCP and REST only serve the current approved revision that the caller is allowed to read. The existing agent can retrieve those concepts directly or combine them with its wider RAG pipeline.

A simple architecture decision

Ask these questions about each knowledge domain:

  • Can two source documents disagree, and who decides between them?
  • Would a wrong answer create customer, financial, operational, or security harm?
  • Do different agents need different slices of the same subject?
  • Will someone need to prove which version was current?
  • Can a domain owner review changes without an engineering deployment?

If the answers point to consequence, conflict, access boundaries, and accountability, retrieval is necessary but incomplete. Add a curation workflow around the answers that deserve a deliberate source of truth. Your vector database can keep doing what it is good at; it no longer has to pretend that similarity and approval are the same thing.

Next step

Put a governed boundary around agent knowledge

Prove the workflow with one agent, or talk with us about a multi-team security review.

Review the controls

Keep reading

Put the approved answer behind your AI

Create a workspace, write and approve your first page, and connect an assistant over MCP or REST. Free to start, no credit card.

Not ready yet? Get future playbooks.

Occasional product updates only. No newsletter, no spam.

Curated Data

Opening Curated Data

Loading application code and preparing your workspace…