Traditional enterprise search assumes that the user knows how to ask the right question.
Traditional RAG improves on this by retrieving documents related to a prompt and giving them to a language model.
But many real business questions are not one-search problems.
Consider:
Which specification applied to Project X when the supplier decision was approved, and did the final proposal comply with it?
The answer may require an agent to:
- find Project X;
- identify the supplier decision;
- determine the relevant date;
- find the specification active on that date;
- locate the final proposal;
- compare the proposal against the specification;
- explain any exceptions.
A single vector search is unlikely to perform that chain reliably.
This is the problem agentic RAG is trying to solve.
Retrieval becomes an active process
Google Research describes its enterprise agentic RAG work as a move beyond single-step retrieval. Rather than searching once and hoping that the correct evidence appears in the initial result set, an agent can break a complex question into sub-questions, search iteratively and decide whether it has sufficient evidence before answering.
Microsoft Research reports similar results from AgenticRAG. Its work equips a reasoning model with search, find, open and summarise tools so it can navigate an enterprise knowledge base rather than receiving a fixed bundle of documents.
The significance is easy to miss.
The model is no longer simply grounded with search results.
It is using search as a tool.
This can improve both quality and efficiency
At first glance, multiple searches may sound more expensive than one large retrieval.
Often the opposite can be true.
A naive RAG system may retrieve a large number of chunks “just in case”, loading thousands of irrelevant tokens into the context window.
An agentic retrieval system can start small.
Search.
Inspect.
Refine.
Retrieve the next piece of evidence only if required.
The aim is not to minimise the number of retrieval operations.
It is to maximise the relevance of the information eventually passed to the reasoning model.
That distinction matters because retrieval cost is usually far lower than repeatedly processing irrelevant context with a large model.
Enterprise knowledge has relationships
Business information is rarely a collection of independent documents.
A project references a customer.
A customer has products.
A product has guidelines.
A guideline may have multiple versions.
A decision has an owner and date.
A meeting changes the status of a project.
Once those relationships are represented explicitly, retrieval can become more powerful.
The agent can move from:
Find documents similar to this question.
to:
Find the project, identify its client, retrieve the guideline effective at the time, then find the approval decision.
This is closer to reasoning across the business.
Search, memory and knowledge will converge
Iridium treats organisational Knowledge and persistent Memory separately, but an enterprise agent often needs both.
Knowledge might contain the approved policy.
Memory might contain the fact that an exception was previously approved for this client.
The useful answer emerges when the agent can navigate both.
That suggests the future of enterprise retrieval will not be a single search bar.
It will be an intelligent evidence-gathering layer that knows what to search, where to search next, what happened before and when enough evidence has been collected.
The best enterprise agents will not simply know more.
They will know how to find what matters.
Sources
- Google Research, Unlocking dependable responses with Gemini Enterprise Agent Platform’s Agentic RAG (2026)
- Microsoft Research, AgenticRAG: Agentic Retrieval for Enterprise Knowledge Bases (2026)