Retrieval is enough when the question is what your documents say; it is not enough when the agent has to state what your company decided, such as a price, a policy or a promise. For those answers the agent needs a verified fact with one current version and a named person behind it, while RAG keeps doing the search it is good at.
What RAG does well
Retrieval-augmented generation indexes your documents, usually by splitting them into chunks and storing embeddings in a vector database, then finds the chunks closest to a question and hands them to the model. It is a good answer to a real problem: you have thousands of pages, the answer might be anywhere, and nobody can read them all.
RAG is cheap to start, covers a lot of unstructured text, and gets better as you tune chunking and ranking. For research, support archives, contracts and long technical documentation, it is often the right tool.
Where retrieval stops being enough
The limit of retrieval is the corpus. A RAG pipeline returns what was written, and what was written includes drafts, old decks and documents that contradict each other. Perfect retrieval over a folder with last year's price sheet returns last year's price sheet perfectly.
A few patterns show up again and again:
- Two versions, one question. The old pricing page and the new one are both in the index. Retrieval returns whichever ranks higher, and the model has no way to know which one your company stands behind.
- The exception gets split off. Chunking separates a policy from the paragraph that limits it, so the agent quotes the rule without its exception.
- A confident draft outranks a dull final. Embeddings rank by similarity, not by authority. A well-written proposal can beat the short, final decision.
- Nobody is behind the answer. Retrieval can cite the chunk it used. It cannot tell you who decided that chunk was true.
None of these are bugs. They are what statistical search over text does. They only become a problem when the agent stops researching and starts stating things to customers.
Search-shaped or authority-shaped
A simple test splits the problem. For each question your agent answers, ask whether it is search-shaped or authority-shaped.
Search-shaped questions have answers somewhere in a large body of text, and a good-enough answer is fine. "What did we say about integrations in the Q2 webinar?" "Find past tickets about export errors." Retrieval is the right tool.
Authority-shaped questions have one correct answer that your company decided, and a wrong answer costs something. "What does the Team plan cost?" "What is the refund window?" "Do you support single sign-on?" These need a verified fact.
Most agents need both kinds, which is why the useful question is not RAG or facts, but which claims you can afford to leave to probability.
How a fact layer answers differently
A fact layer does not rank anything. Your business facts are written as short statements, each verified by a named person, with one current fact per block. When the agent asks for the refund policy, it gets the refund policy, with its version and who verified it attached.
When something changes, the owner writes and verifies a new version. In NOAN, old versions are kept but not obeyed, and the change reaches every agent, app and page that reads the fact at once. There is no re-indexing step and no chance that the old version ranks higher next time.
That is the line NOAN draws: memory holds what was said, retrieval holds what was written, and a fact layer holds what was decided.
Splitting the work, step by step
- List the authority-shaped questions. Go through support logs and sales calls and pick the questions where a wrong answer costs you. Prices, policies, product capabilities and commitments usually top the list.
- Move those answers into a fact layer. Write each as one fact, and have the owner verify it.
- Take the stale copies out of the index. Old price sheets and superseded policies should not sit in the corpus where retrieval can find them. If you must keep them, mark them as archived.
- Connect the agent to both. Keep the RAG pipeline for search. Connect NOAN over MCP at
https://mcp.getnoan.com/mcpor REST athttps://api.getnoan.com/v1. - Add one rule. Tell the agent which source it may state outward:
Search documents to research. For any price, policy, product detail or commitment, read NOAN and state only what NOAN says. If a document disagrees with NOAN, NOAN wins.
- Test with a change. Update a fact, verify it, and ask the agent. It should give the new answer straight away, even though the old document is still in the index.
Keeping the two in sync
If your retrieval index includes pages built from facts, such as a pricing page, NOAN can fire a webhook when a fact changes, so the page or the index can refresh straight away instead of waiting for the next sync.
Agents can also write facts back. Facts an agent writes over the API can be held for a person to verify before anything reads them, so an agent that finds a new answer in your documents can propose it without it going live on its own.
When RAG alone is fine
If your agent only searches, summarizes or helps people find things, and never states your prices or policies to anyone outside the company, retrieval alone may be all you need. A fact layer earns its place when the agent acts or speaks for the business.
For a longer comparison, including the build cost of running your own pipeline, see NOAN vs building your own RAG. For how memory fits in, see agent memory vs verified facts.
Next step
Connect your agent to NOAN over MCP at https://mcp.getnoan.com/mcp, or over REST at https://api.getnoan.com/v1 with the OpenAPI spec. Or paste this into your agent:
Read https://www.getnoan.com/setup.md and follow it.