Get the Full Agentic RAG Collection

Free Agentic RAG Fundamentals 4 practical notebooks

Get the Free Notebooks

Most RAG tutorials follow a simple pattern:

Retrieve → Generate → Answer

It works pretty well for a basic demo.

But real applications are usually not that simple.

What happens when the retriever returns irrelevant documents?

What if the query is poorly written?

What if the information is not in your vector database at all?

What if the generated answer is not actually supported by the retrieved context?

At that point adding more documents to the prompt is not necessarily going to help.

The system needs to make decisions about what to do next.

That is where Agentic RAG becomes useful.

Traditional RAG is mostly a one-shot process

A typical RAG application does something like this:

Take the user's question. Search a vector database. Retrieve the top documents. Give them to an LLM. Generate an answer.

The problem is that the pipeline usually assumes retrieval worked.

If the retrieved documents are bad the LLM still gets them.

If the query does not match the terminology in your documents retrieval may fail.

And if the answer is not in your knowledge base the system does not really have a next step.

This is where Agentic RAG gets interesting.

Instead of asking:

How do I retrieve better?

we can ask:

What should the system do when retrieval is not good enough?

Let the system evaluate its retrieval

Imagine asking:

How does LangGraph handle persistence?

The retriever returns five documents but only one is actually relevant.

A traditional pipeline might pass all five to the LLM.

An agentic workflow can evaluate the retrieved documents first.

If the documents are not useful enough the system can decide to try again.

One simple approach is query rewriting.

Instead of searching with the same query again the system generates a better search query based on what it found and retrieves again.

This creates a simple feedback loop:

Retrieve → Evaluate → Rewrite → Retrieve again

The important part is not the loop itself.

It is that the system can recognize that its first attempt was not good enough.

What if the information is not in your knowledge base?

Query rewriting will not solve every problem.

Sometimes your vector database simply does not contain the information.

For example imagine your RAG application is built around documentation collected last month.

A user asks about something released yesterday.

Searching the same documents again will not help.

This is where Corrective RAG becomes useful.

The system can evaluate the retrieved documents and when they are not sufficient it can use another source such as web search.

Instead of:

Retrieve → Generate

the workflow can become:

Retrieve → Grade → Correct → Generate

The correction could mean rewriting the query, searching another source, or taking another action depending on the application.

Different questions may need different retrieval strategies

Another common assumption is that every question should go through the same retriever.

But imagine an application with internal company documentation, product documentation, a vector database, and live web search.

A question about an internal policy probably should not be answered using a web search.

A question about a recently released library version probably should not rely entirely on an old vector database.

This is where Adaptive RAG comes in.

Instead of always retrieving from the same place the system can first decide where the question should be answered from.

It can route the query to the right knowledge source and then evaluate the resulting context.

This makes the retrieval process more flexible instead of following the same path every time.

Retrieved documents can be good while the answer is still bad

There is another problem that is easy to overlook.

Good retrieval does not automatically mean a good answer.

The model can receive highly relevant documents and still generate an answer that is not properly supported by them.

So why not evaluate the answer too?

An agentic workflow can check things like:

Is the answer supported by the retrieved context? Does it actually answer the question? Did the model introduce unsupported information?

If the answer fails those checks the workflow can revise or regenerate it.

Now we are evaluating both sides:

Did we retrieve the right information?

and

Did we use that information correctly?

That distinction becomes more important as RAG systems move beyond simple demos.

Sometimes the best decision is asking a human

Not every problem should be solved automatically.

There are situations where you may want a human to review the result before the system continues.

For example:

The evidence is ambiguous. The answer requires approval. The system is not confident enough. The generated response needs revision.

This is where Human-in-the-Loop RAG fits.

Instead of forcing the agent to make the final decision you can introduce a checkpoint where a person can approve, reject, or modify the result.

The interesting part is that this does not mean abandoning automation.

The system can handle the routine work and involve a human only when necessary.

What happens when one agent isn't enough?

As workflows become more complex a single agent may not be the best architecture.

Some tasks naturally break into specialized responsibilities.

One agent can coordinate the workflow while other agents handle retrieval, research, evaluation, or other specialized tasks.

This is where Multi-Agent Supervisor RAG becomes useful.

A supervisor can decide which specialized agent should handle the next step instead of putting every responsibility into one large agent.

The goal is not to add agents just for the sake of adding agents.

It is to make the workflow easier to reason about when the problem itself is naturally multi-step or specialized.

Some work can happen in parallel

Not every retrieval or research step needs to happen sequentially.

Suppose you need information from several independent sources.

Instead of:

Source A → Source B → Source C → Answer

you can fan out the work:

Question → A + B + C → Combine → Answer

This is the idea behind Parallel Fan-Out RAG.

Independent retrieval or processing tasks can run in parallel and their results can then be combined.

This can make more complex RAG workflows both faster and easier to structure.

Sometimes the system should plan before it executes

Another useful pattern appears when the question itself requires multiple steps.

Instead of immediately calling tools and retrieving documents the system can first create a plan.

For example:

Question → Plan → Execute steps → Evaluate → Answer

This is the idea behind Plan-and-Execute RAG.

The planner determines what needs to be done while execution handles the individual steps.

This can be useful when answering a question requires multiple searches, transformations, or reasoning stages rather than a single retrieval operation.

So what makes RAG agentic?

For me the key difference is not simply adding an LLM or calling something an agent.

It is giving the system the ability to evaluate its situation and choose what happens next.

A traditional pipeline might assume:

Retrieve once then answer.

An agentic pipeline can reason:

Do I need retrieval?

Did I retrieve useful information?

Should I search again?

Should I use another source?

Is my answer supported?

Should I ask a human?

Should another agent handle this?

Should I plan the work before executing it?

That is a much more useful way to think about Agentic RAG.

10 practical LangGraph architectures I recently built

I recently expanded this work into a collection of 10 practical LangGraph notebooks covering both the fundamentals and more advanced Agentic RAG architectures.

Fundamentals

LangGraph Starter — core state and reducer patterns for building a LangGraph workflow

LangGraph Conditional Routing — branching a workflow with conditional edges

Agentic RAG — tool selection and query rewriting

ReAct Multi-Hop Agentic RAG — multi-step tool-calling with a prebuilt agent loop

Advanced Architectures

Corrective RAG — retrieval grading and web fallback

Adaptive RAG — routing between knowledge sources plus retrieval and answer evaluation

Human-in-the-Loop RAG — approval and revision checkpoints

Multi-Agent Supervisor RAG — a supervisor delegates retrieval, research, and evaluation to specialized agents

Parallel Fan-Out RAG — independent retrieval tasks run in parallel and their results are combined

Plan-and-Execute RAG — a planner breaks the question into steps before execution begins

The goal is not to say that every RAG application needs all ten architectures.

Each pattern addresses a different problem.

Start with the problem not the pattern

If your application struggles with poor retrieval, query rewriting might be enough.

If your knowledge base is incomplete, a fallback source could be more useful.

If you have multiple knowledge sources, routing may make more sense.

If certain decisions require oversight, you can add a human checkpoint.

If the workflow has specialized tasks, a supervisor or parallel architecture may be a better fit.

And if the problem requires multiple dependent steps, planning can help.

The important question is not:

How can I make my RAG system more agentic?

It is:

What is my RAG system currently doing blindly?

That is usually where the most useful improvement starts.

Try the implementations

Full collection — Advanced LangGraph Patterns

10 practical Agentic RAG architectures: 4 fundamentals + 6 advanced patterns.

Get the Full Agentic RAG Collection

Four Agentic RAG patterns plus six advanced architectures implemented as self-contained Jupyter notebooks you can run, study, and adapt.

Free Agentic RAG Fundamentals

4 free notebooks to get started with Agentic RAG.

Get the Free Agentic RAG Notebooks

The free pack is designed as the starting point with basic Python as the only prerequisite.

The full collection goes further into practical LangGraph architectures that you can build on top of those fundamentals.

If you are working on RAG applications I would be interested to hear

A traditional RAG pipeline usually doesn't think twice. It follows a fixed path: Retrieve → Generate → Answer

But real world AI applications aren't that simple. Sometimes the system needs to search again with a different approach. Sometimes it needs to evaluate what it retrieved, verify whether an answer is actually supported, correct its own mistakes or ask a human for help before proceeding.

That's where Agentic RAG comes in. Instead of treating retrieval as a fixed step, Agentic RAG gives the system the ability to reason about the retrieval process and decide what to do next.

Why Does Agentic RAG Matter?

As RAG applications grow more complex and work with larger document collections, simply retrieving the top-k documents isn't enough to produce accurate answers. An agentic approach lets a RAG system:

1. Decide what information to retrieve

2. Reason over the retrieved context

3. Evaluate whether the context is relevant

4. Verify whether an answer is supported

5. Retry or refine retrieval when necessary

6. Escalate to a human when confidence is low

The goal isn't complexity for its own sake it's building RAG systems that are adaptive, robust and reliable instead of blindly following a fixed pipeline.

What I Built

This has grown into a 10-notebook series on LangGraph from the two core ideas every agent depends on up to a full set of production style RAG architectures.

Free (4 notebooks) the fundamentals:

• LangGraph Starter — state, reducers and an LLM node

• Conditional Routing — the router mechanic every agent decision is built on

• Agentic RAG — a hand built tool calling agent that decides per question whether to retrieve, which knowledge base to search and whether it needs a second lookup (multi-hop)

• ReAct Multi-Hop Agentic RAG — the same problem solved a second way, rebuilt on LangChain's prebuilt create_agent loop instead of a hand wired graph

Advanced (6 notebooks) — one architecture per failure mode:

• Corrective RAG — grades every retrieved chunk and falls back to a live web search to patch gaps before answering

• Adaptive RAG — routes each question to a vectorstore or the web up front, then self-checks the final answer for hallucination and relevance, looping back if it fails

• Human-in-the-Loop RAG — same retrieve/grade/generate machinery, but a real person approves, revises or rejects at two checkpoints instead of an LLM deciding alone

• Multi-Agent Supervisor RAG — a supervisor routes each question to one of three specialist subgraphs then critiques the answer and can escalate to a web specialist

• Parallel Fan-Out RAG — decomposes a multi-part question into sub-questions, answers them concurrently via LangGraph's Send API then aggregates the results

• Plan-and-Execute RAG — plans every step up front, executes them one at a time, and a replanner decides whether more work is needed before synthesizing the final answer

Every notebook is fully commented and markdown-explained top to bottom, runs on Groq's free tier API for the LLM and uses local BAAI/bge-m3 embeddings (sentence transformers) no embedding API key needed.

Free Version (4 notebooks): https://chandula7.gumroad.com/l/AgenticRAGFundamentals Advanced Version (6 notebooks): https://chandula7.gumroad.com/l/Advanced_RAG_LangGraph_Patterns

If you're building RAG applications this is a step toward moving beyond Retrieve → Generate and toward systems that can Retrieve → Reason → Verify → Correct → Answer