From RAG to agentic RAG: when the assistant stops “search then answer” and starts reasoning
A year ago we described RAG as “search your data, then answer”. That was true and enough for a support bot. But it fails on a question like: “What is the right learning path for a new sales hire who failed the product te…
A year ago we described RAG as “search your data, then answer”. That was true and enough for a support bot. But it fails on a question like: “What is the right learning path for a new sales hire who failed the product test, according to this year’s training policy?”. That question needs planning, several retrievals, and verification. That is agentic RAG.
The difference in one sentence
Classic RAG: one retrieval, one answer. Agentic RAG: a plan, multiple retrievals, verification, then a cited answer.
The loop we build
- Decomposition: the agent breaks the question into sub-questions (“what is the training policy?”, “what was the test result?”, “which paths exist?”).
- Multi-source retrieval: each sub-question goes to the right source — knowledge base, database, or API.
- Verification: do the sources conflict? Is the result sufficient? If not, retrieve again with a different phrasing.
- Composition: one answer with references, plus a list of what could not be confirmed.
A real application: Learnly and LMS By SLT
In Learnly (an enterprise LMS with SCORM support) the assistant does not just answer “where is the lesson”; it reads quiz results, compares them with path requirements, and proposes the next step. In the bilingual LMS By SLT, retrieval runs in Arabic and English together and is then merged — because half the content is written in one language and the question arrives in the other.
A completely different application: the Pioneers editorial platform
On Pioneers (an editorial reference for leaders in the Saudi market) we used the same loop for another purpose: fact-checking before publishing. The agent retrieves everything on record about a person from approved sources and flags any sentence in the draft it cannot support. It never wrote a single article; it prevented dozens of mistakes.
The mistakes you will make (we did)
- Endless loops: cap the number of retrievals and set a time budget.
- Over-confidence: make “not found” a legitimate, measured outcome, not a failure.
- Authorisation after retrieval: it must apply before; the agent must not “see” what the user is not allowed to see.
- Cost: four retrievals and three model calls for one question — measure, and use smaller models for the intermediate steps.
When you do not need it
If your users ask “what are the opening hours?”, plain RAG is better, cheaper and faster. Agentic RAG is for the questions a human would need three open windows to answer.
