RAG vs Agentic RAG: Fixed Retrieval or Adaptive Search?

RAG, retrieval-augmented generation, supplies external evidence to an AI model before it answers. In a fixed pipeline, your software controls the search sequence; in agentic RAG, the model can decide when and how to search within boundaries you set. Agentic RAG is a form of RAG, with more flexible retrieval rather than a different source of truth.

Choose by the questions you need answered and the searches they require. A tool such as fenbs keeps the reviewed decisions, tasks, and progress around that work, while your retrieval system supplies the source evidence. Neither a longer search nor a saved project note makes an unsupported answer correct.

What changes when the model directs retrieval?

LangChain's retrieval documentation↗ (opens in a new tab) distinguishes retrieval before generation from an assistant deciding when and how to retrieve. Real applications can combine the patterns: a fixed first search, a check, and a bounded follow-up. Labels are less useful than a clear account of who controls each step.

For retrieval fundamentals, start with what RAG is; the broader comparison with systems that take actions belongs in RAG vs agentic AI. Here the choice is specifically how an evidence-seeking application conducts its searches.

When does another search actually help?

A fixed path is a good starting point when the question reliably maps to known evidence. For example, a product-support assistant can search the relevant manual, retrieve the matching sections, and answer with citations. Adding model-directed searching is useful only if it solves failures that the simpler path cannot handle satisfactorily.

Imagine a studio asking why an approved design differs from the delivered website. The first search finds a design revision, which mentions a later accessibility decision. A useful follow-up retrieves that decision and the implementation task before drawing a conclusion. The second search fills a specific evidence gap that the first result revealed.

• Consider adaptive retrieval when one result reveals the name, date, or identifier needed for the next search.
• Consider it when questions need several sources whose relevance becomes clear only during the investigation.
• Keep a fixed path when questions follow a repeatable pattern and required evidence is consistently found.
• Improve the sources first when the necessary facts are missing, contradictory, or inaccessible.

Searching again for a better-sounding answer is a weak rule. Require the application to identify what is missing, such as the current version or a conflicting exception. For how these steps fit a larger process, see agentic workflows.

Does agent-directed retrieval guarantee better answers?

No. It creates opportunities to recover from a poor first search, alongside opportunities to choose the wrong tool, follow an irrelevant lead, or stop too early. Judge the evidence supporting the final answer. An articulate explanation of the search does not establish that the important source was found.

The Self-RAG research↗ (opens in a new tab) investigates adaptive retrieval and evaluation of retrieved material and generated answers. That specific trained approach is evidence for studying retrieval decisions, not a guarantee that any application with an extra search loop gains its reported results. Your model, sources, and questions still need their own evaluation.

Design verification around observable evidence. Preserve the retrieved passages, source locations, versions when available, and which claims they support. Ask a reviewer whether the answer follows those passages and whether an important exception is absent. A model reviewing its own draft can be one check, but should not be the sole judge of success.

Allow an explicit incomplete result. If the sources establish a design change but do not explain its approval, the answer should say so and name the unresolved question. Keep that question on a task in fenbs instead of letting a plausible explanation become the team's recorded decision.

How do you keep response time and cost predictable?

Set limits on retrieval calls, model calls, elapsed time, and returned material. A fixed workflow usually makes those limits easier to reason about because its stages are known. An adaptive workflow needs a stopping rule for when the evidence is sufficient, as well as a fallback when the allowed budget runs out.

For a test application, you might allow an initial search and a small bounded number of follow-ups. That is an example setting, not a recommended universal limit. At the boundary, return the supported portion of the answer and the remaining uncertainty rather than silently continuing or filling the gap from guesswork.

Measure complete requests, including slow searches and unsuccessful attempts. Record which tools ran and how much source text reached the answer step. Separate straightforward questions from investigations, since averaging them together can hide a poor experience for one group. More searches are justified when they produce a meaningful improvement on the questions that need them.

Where must access and safety checks happen?

Every retrieval tool must check the caller's access before returning content. The model can select a search, but it must not select its own permissions. Apply the same boundary to a follow-up query, a document fetched by identifier, and a link found inside another result. Previously accessible evidence must not become a permanent bypass after access changes.

Microsoft's RAG overview↗ (opens in a new tab) identifies authorized retrieval as a requirement alongside relevance and response time. In your design, test with two readers whose access differs. Check the actual returned passages as well as the visible answer; hiding a passage in the final wording does not undo its disclosure to the model.

Treat retrieved documents as evidence rather than authority to change the application's rules. A page could contain instructions to ignore the task or send information elsewhere. OWASP's prompt-injection guidance↗ (opens in a new tab) describes this risk from external content and recommends limited privileges and controls around consequential actions.

For an evidence-search assistant, start with read-only tools. If the wider application can publish, email, or change records, keep those permissions and approvals explicit in code. Finding an instruction in a document should never expand what a person authorized. This matters for both architectures, with more possible tool paths to inspect in the adaptive version.

How should you choose and test an approach?

Build a small fixed baseline before adding adaptive behavior. Use questions from the real task and write the expected supporting sources before running tests. Group failures by cause: missing source, poor search, wrong interpretation, unsupported claim, or access failure. Only some of those failures call for another retrieval decision.

1. Test direct lookups, questions requiring multiple sources, and questions with an important exception.
2. Include ambiguous questions that should trigger clarification and unanswerable questions that should remain unresolved.
3. Compare source coverage, supported claims, complete response time, and resource use on the same questions.
4. Repeat representative questions to see whether different search paths change the outcome.
5. Test source corrections, revoked access, failed tools, and the stopping limit before expanding the system.

Use adaptive retrieval when its observed gains justify maintaining the additional choices. A fixed first search plus a bounded evidence check may be sufficient. The wider context engineering collection covers related approaches; keep this decision focused on the retrieval failures you can demonstrate.

What work record should survive the search?

Your document index holds evidence to search. The work record holds what people decided, which questions remain open, what was tested, and where the next session should begin. Keeping them distinct prevents an experimental answer from silently becoming an approved fact and avoids repeating a search without knowing why it was done.

Record a conclusion at the confidence level it earned: supported answer, hypothesis to test, or open question. Connect the next task to the evidence rather than saving an entire search transcript as a rule. See how fenbs works for the shared record that sits around either retrieval design.

How to review retrieval work with fenbs?

fenbs is useful when people and assistants need to continue the same work across sessions. It does not provide a document index, vector search, or a hosted retrieval pipeline. If you only need search inside one application, use its retrieval features; add a shared work record when decisions and follow-up work need their own maintained home.

1. Create a free account, then create a project for the retrieval application.
2. Keep the question scope and approved boundaries in Decisions and rules, and record unresolved findings in context notes.
3. Add reviewed source locations to Links and listings with status and dates.
4. Track failed searches and unsupported answers as tasks, with the intended fix in the plan and results in the test fields.
5. Connect an assistant and ask it to read project context, then save Where we left off so the next session starts at the remaining check.