On 1 October 2026, Progress Software announced a Smart Agent for its retrieval product that plans a query, splits it into sub-questions and searches several places in turn: its own knowledge store, business applications connected through MCP, and the web. Google moved in the same direction in June, putting an agentic workflow for searching across several document collections into public preview on its Gemini Enterprise Agent Platform. Retrieval that searches more than once is now a product feature, and it is a fair question for any Saudi team already running a document assistant: do we need it?
Short answer: Only for the questions that need it. A single, well-built search is still the right default for most internal document questions, and it is cheaper to test and easier to explain. Add multi-step retrieval when your real questions span more than one source or need one finding to locate the next, and only once you can measure whether the extra searches help.
What the new products actually do
Classic RAG runs one search, takes the top passages and asks the model to answer from them. The newer designs add a planning step in front and a checking step behind.
In Google’s description, a planner chooses the sources, a rewriter turns the request into several searches, and a separate agent reads the results and a rough draft to decide whether anything is missing. If something is, the system searches again with a narrower query before writing the final answer. Progress describes a similar plan-then-search loop that can reach live business systems at query time.
The vendor numbers deserve a careful read. Google reports accuracy gains of up to 34% over standard RAG on factuality datasets it does not name in the post. On the FramesQA set, with the right documents mixed among three distractor collections, it reports 90.1% correct answers, with latency on average within 3% of the single-collection setup. These are the vendor’s own measurements, on its own stack, scored by an LLM judge. They show the approach can work. They do not show it will work on your Arabic contracts.
Why one search falls short
Some questions cannot be answered from a single lookup. The researchers behind FRAMES, a public test set built for this problem, found that leading models scored 0.40 accuracy without retrieval and 0.66 with a multi-step retrieval pipeline. The hard questions were the ones that needed facts from several documents put together.
The same pattern shows up inside organizations:
- Answers split across systems. The policy sits in the document library, the approved exception sits in a committee memo, and the current figure sits in the ERP.
- One finding leads to the next. The contract names a supplier, and the supplier’s record holds the renewal date.
- Question in one language, source in another. A manager asks in Arabic while the technical annex is in English. A second, translated query often finds what the first one missed.
If most of your questions look like “what does clause 7 say”, none of this applies, and a planner adds cost without adding accuracy.
Knowing when to stop matters more than searching again
The checking step is the part to care about most. A study by Google researchers on “sufficient context” found that strong models often gave a wrong answer instead of declining when the retrieved passages did not hold enough to answer. Using a sufficiency signal to decide when to answer raised the share of correct answers among those given by 2 to 10% in their tests.
For a ministry, a legal team or a bank, this is the first property to ask a vendor about. An assistant that says “the documents I can see do not answer this, and here is what I found” is safer than one that searches five times and then fills the gap. In our builds, the abstain path is designed and tested like any other answer, with its own wording in Arabic and English.
A worked example: one procurement question
Take a question a procurement officer might type: "هل يسمح عقد الصيانة الحالي بالتمديد، وما آخر موعد لإشعار المورد؟" (Does the current maintenance contract allow an extension, and what is the last date to notify the supplier?)
A single-pass system searches once, finds the extension clause and may guess the date. A multi-step system would work like this:
- Plan. Recognize two sub-questions: the extension terms and the notice deadline.
- Search the contract repository. Retrieve the extension clause and the notice period, say 60 days before expiry.
- Check sufficiency. Notice that the expiry date is not in the retrieved passages.
- Search again, narrowly. Query the contract register or the signed award letter for the start date and term.
- Answer or abstain. Work out the notice date only if both pieces were found, cite both passages, and say plainly if one is missing.
Every extra step is also a new place to fail. Each search should run with the user’s own permissions, each step should be logged, and the plan should have a fixed limit on how many searches it may run. If the agent reaches live systems through connectors, those connections need the same access review as any other integration. Our note on deletion requests and retrieval indexes explains why every copy of retrieved data needs an owner.
How we would decide, workflow by workflow
Before adding agentic retrieval to a system, we would check four things:
- Look at real questions. Sample a few hundred questions from logs or interviews and label which ones need more than one source. If it is a small share, improve single-pass retrieval first.
- Fix the basics first. Arabic text normalization, sensible chunking, hybrid keyword and vector search, and a re-ranker come before any planner. Arabic has been underrepresented in popular public benchmarks such as MTEB, so test embedding models on your own documents.
- Measure both versions on the same set. Run single-pass and multi-step retrieval on the same labelled questions in Arabic and English, and compare correct answers, correct refusals, wrong answers, cost and time per answer.
- Set limits before launch. Cap searches per question, list the sources the agent may use, and decide who can see the plan and the passages behind each answer.
This is the same one-workflow approach described in how we work, and it is how we scope Arabic retrieval on a real project.
What this is not
This is our reading, as builders, of public vendor material and published research. The vendor figures are their own, and none were reported for Arabic documents or Saudi workloads. It is not legal advice: if the agent connects to systems that hold personal data, check your PDPL obligations and the NCA controls that apply to you against the current texts, with your data protection officer or counsel.
If you are unsure whether your document questions need one search or several, start with one workflow and we will measure it with you.
Why now: the rotation landed on Retrieval (ISO week 43, Sunday), and Progress’s 1 Oct agentic-RAG launch plus Google’s preview make “do we need an agent in our RAG?” a live buyer question that no existing note covers. Per the evidence policy, please check each figure against the sources before you press Publish. Checks: title 68 chars, summary 131 chars, about 1,100 words. One thing to know: the sandbox couldn’t reach siyadatech.com directly, so I loaded the internal links (how-we-work, capabilities, the PDPL/RAG note) through the fetch tool instead. I didn’t load /en/contact/, so click it once.