Zucchetti LLM Course — Lecture 7

Agentic RAG
& Autonomous Systems

When the LLM becomes the decision-maker

Kamyar Zeinalipour

Today’s Agenda

Section 1 — Why RAG Needs Agency

Section 2 — Function Calling & Tool Use

Section 3 — The ReAct Paradigm

β˜• Break

Section 4 — Agentic RAG Architectures

Section 5 — Multi-Agent Systems

Section 1 of 5

Why RAG
Needs Agency

From pipeline to decision-maker

The Autonomy Problem

Some tasks can’t be hardcoded — you don’t know the steps in advance

The Request

“Book me a flight to Rome under €200 that doesn’t conflict with my meetings.”

What This Requires

πŸ“… Check
calendar
→
✈️ Search
flights
→
πŸ’° Compare
prices
→
πŸ€” Decide
if conflict
→
βœ… Book
or retry
You can’t hardcode this pipeline. If no flights are under €200, you need to adjust. If meetings change, you re-check. The LLM must decide the steps at runtime.

The Capability Stack

Each lecture adds a layer of intelligence to your retrieval system

L7   Decide WHAT to retrieve — the LLM controls the pipeline

L6   Retrieve connected → Knowledge Graphs

L5   Retrieve smarter → HyDE, Routing, Re-ranking

L4   Retrieve similar → Vector Search

The key shift: in L4–L6, the developer controls the pipeline. In L7, the LLM controls it.

What Makes a System “Agentic”?

Four capabilities that separate agents from pipelines

CapabilityWhat It DoesExample
PerceptionUnderstand the query intent“This needs a calendar check + flight search”
PlanningDecompose into ordered steps“First check calendar, then search flights”
ActionUse tools to execute stepsCall search_flights(), check_calendar()
ReflectionCheck own work, retry if needed“No flights under €200 — try flexible dates”
A system is agentic when it has all four. A RAG pipeline from L4 has only Perception + Action (search + generate). Today we add Planning and Reflection.

Section 2 of 5

Function Calling
& Tool Use

Teaching LLMs to act on the world

What Is Function Calling?

The LLM does NOT execute code. It writes a request. Your code executes it.

❌ Common Misconception

The LLM “calls an API” or “runs a function”

βœ… What Actually Happens

The LLM generates a JSON request. Your backend executes it and returns the result.

Analogy: The LLM is a doctor writing a prescription. The pharmacy (your code) fills it.

From L3: function calling uses the same JSON schema mechanism as structured output — but instead of formatting data, it triggers actions.

The Function Calling Flow

Five steps — the LLM never touches the internet

❓ User
Query
→
🧠 LLM
decides tool
→
πŸ“€ JSON
function call
→
βš™οΈ Your Code
executes
→
πŸ“₯ Result
back to LLM
→
πŸ’¬ Final
Answer

🧠 LLM World

Understands query, picks tool, generates JSON, formats answer

βš™οΈ Your Code

Receives JSON, calls real API, returns data

Step 1: Defining a Tool

You describe your tools in JSON Schema — the LLM reads this to decide what to call

{
  "name": "get_weather",
  "description": "Get current weather for a city",
  "parameters": {
    "type": "object",
    "properties": {
      "city":  {"type": "string", "description": "City name, e.g. 'Rome'"},
      "units": {"type": "string", "enum": ["celsius", "fahrenheit"],
                "description": "Temperature units"}
    },
    "required": ["city"]
  }
}
The description field is what the LLM reads to decide whether to use this tool. Vague descriptions = wrong tool choices.

Step 2: The LLM Decides

From natural language to structured JSON — automatically

User Query

“What’s the weather like in Rome?”

β–Ό

LLM Output (not text — a function call)

{
  "name": "get_weather",
  "arguments": {"city": "Rome", "units": "celsius"}
}
The LLM chose the tool (get_weather) AND extracted the arguments (Rome, celsius) from the user’s natural language. No parsing, no regex — the model did it.

Step 3: Execute & Return

Your code runs the real API — the LLM never touched the internet

JSON from LLM
get_weather("Rome")
→
Your Code
calls weather API
→
{"temp":28, "condition":"sunny"}
β–Ό result sent back to LLM

LLM Generates Final Answer

“It’s 28Β°C and sunny in Rome right now! Great weather for sightseeing.”

The LLM never touched the internet. It generated JSON, your code called the API, and the LLM formatted the result into natural language.

Tool Definition Best Practices

The “intern test”: if an intern can’t use your tool from the description, the LLM can’t either

❌ Badβœ… Good
Nameprocesssearch_flights
Description“Handles requests”“Search available flights between two cities on a given date. Returns a list of flights with prices.”
Parametersdata: stringorigin: string, destination: string, date: string (YYYY-MM-DD), max_price: number
ConstraintsNoneenum: ["economy","business"]
Clear names, explicit descriptions, constrained types. The LLM reads your schema like documentation — make it readable.

Parallel Function Calling

The LLM generates multiple tool calls at once — when they’re independent

Query

“Is it warmer in Rome or Paris right now?”

βœ… Parallel (correct)

[
  {"name":"get_weather", "args":{"city":"Rome"}},
  {"name":"get_weather", "args":{"city":"Paris"}}
]

Both run simultaneously

❌ Sequential (wasteful)

Call Rome → wait → call Paris → wait

2× latency for no reason

Use parallel when calls are independent. Use sequential when call B needs the result of call A.

Multi-Turn Tool Calling

The LLM chains tools automatically — each result shapes the next decision

Example: “Is Mario eligible for remote work?”

LLM calls
get_employee("Mario")
→
dept: Engineering
→
LLM calls
get_policy("Engineering","remote")
→
Answer
From L3: Prompt chaining was similar — Step 1 → Step 2 → Step 3. But there, YOU wrote 3 separate prompts and decided the steps. Here, the LLM decides within a single conversation. The developer goes from author to observer.

The Toolformer Insight NeurIPS 2023 Oral

LLMs can learn to decide when to call tools — not just how

Key Idea

Insert API call into text → if it improves next-token prediction, keep it. Self-supervised: no human labels needed.

Example: The Model Learns Its Weaknesses

“The number in the next term is 18 + 12 × 3 = [Calculator(18 + 12 * 3)] 54.”

The model inserts a calculator call because it knows it’s bad at arithmetic. It discovered this on its own.

Toolformer showed: you don’t need to train models on tool use. They can learn to use tools through self-supervision. This is the foundation of modern function calling.

Schick et al. (2023) — “Toolformer: Language Models Can Teach Themselves to Use Tools” — NeurIPS 2023 (Oral)

Common Pitfalls

Five failure modes you’ll hit in production

PitfallExampleFix
Hallucinated toolCalls search_database() — doesn’t existStrict validation: reject unknown tools
Wrong typesSends "28" (string) instead of 28 (number)Schema validation + type coercion
Ignoring resultCalls API, gets data, generates answer from memoryPrompt: “use ONLY the tool result”
Over-callingCalls calculator for “2 + 2”Prompt: “only use tools when needed”
Under-callingAnswers from memory when it should searchPrompt: “always verify with tools”

Function Calling — Summary

What It Is

LLM generates JSON requests. Your code executes them.

What It Isn’t

The LLM never runs code, calls APIs, or accesses the internet.

The Flow

Query → JSON → Execute → Result → Answer

Now you know HOW to give LLMs tools. Next question: how do they decide when to use them? That’s Section 3.

Section 3 of 5

The ReAct
Paradigm

Reasoning + Acting = Grounded Intelligence

From L3 Chaining to L7 ReAct

Same pattern, fundamentally different control

L3: Prompt Chaining

YOU write 3 prompts

YOU decide the steps

YOU control the flow

Steps are known before execution

DEVELOPER = PILOT

L7: ReAct

LLM writes its own reasoning

LLM decides the next action

LLM controls the flow

Steps discovered at runtime

DEVELOPER = AIR TRAFFIC CONTROL

L3 chaining: you are the author of every step. L7 ReAct: you define the tools, but the LLM improvises the plan.

From L5 Decomposition to L7 ReAct

Both break queries into steps — but when?

L5: Query Decomposition

Plan ALL sub-queries upfront

All steps known before retrieval

One LLM call to decompose, then execute all

Like a battle plan written before the war

L7: ReAct

Discover steps one at a time

Step 2 depends on step 1’s result

Each step = Thought + Action + Observation

Like improvisation on the battlefield

L5 decomposition works when you can predict the sub-queries. ReAct works when the next step depends on what you find.

The Problem with Chain-of-Thought

CoT reasons but can’t verify — it thinks, it doesn’t know

CoT from L3

“Who directed Inception?”

CoT: “I think Inception was directed by Christopher Nolan. He’s known for films like Interstellar and The Dark Knight…”

⚠️ It thinks it’s Nolan. What if it’s wrong? No way to verify.

What If the Model Could Just… Look It Up?

“Let me search for the director of Inception” → search("director Inception") → verified fact

CoT = reasoning without grounding. ReAct = reasoning with grounding. Each step is verified by a real tool call.

The ReAct Loop ICLR 2023

Thought → Action → Observation — repeat until done

πŸ’­ Thought

What should I do next?

→

⚑ Action

Call a tool

→

πŸ‘οΈ Observation

Read the result

↩️

The LLM generates Thought and Action. The Observation comes from the tool. The loop continues until a finish() action.

Yao et al. (2023) — “ReAct: Synergizing Reasoning and Acting in Language Models” — ICLR 2023

ReAct — Worked Example (Part 1)

“What awards has the director of Inception won?”

Thought 1: I need to find the director of Inception. I don’t want to guess — let me look it up.
Action 1: search("director of Inception film")
Observation 1: “Inception (2010) was directed by Christopher Nolan. The film stars Leonardo DiCaprio…”
Thought 2: The director is Christopher Nolan. Now I need to find his awards. Let me search specifically for that.
Action 2: search("Christopher Nolan awards won")

continued on next slide →

ReAct — Worked Example (Part 2)

Observation 2: “Christopher Nolan won the Academy Award for Best Director for Oppenheimer (2024). He has also received BAFTA and Golden Globe awards…”
Thought 3: I now have the information I need: the director is Christopher Nolan, and his awards include the Academy Award for Best Director (Oppenheimer, 2024).
Action 3: finish("Christopher Nolan directed Inception. He has won the Academy Award for Best Director for Oppenheimer (2024), along with BAFTA and Golden Globe awards.")
Every fact is grounded. “Christopher Nolan” came from a search, not from memory. “Academy Award” came from a search, not a guess. Hallucination is dramatically reduced because every claim traces back to a tool result.

ReAct vs Chain-of-Thought

Same question, different approaches

CoT (L3)

“Inception was directed by Christopher Nolan” βœ…

“He won the Oscar for Interstellar” ❌ Wrong!

“He also won for Dunkirk” ❌ Wrong!

Sounds plausible. Confident. Incorrect.

ReAct (L7)

Search: “director Inception” → Nolan βœ…

Search: “Nolan awards” → Oppenheimer 2024 βœ…

Every fact verified by real tool call βœ…

Slower. More calls. Correct.

CoT hallucinates intermediate facts. ReAct grounds every step. The trade-off: ReAct costs more LLM calls but is far more reliable.

ReAct — HR Domain Example

“Is Mario eligible for the senior developer promotion?”

T1: I need Mario’s current role and tenure.
A1: get_employee("Mario Rossi") → Role: Developer, Hired: 2019
T2: 5+ years tenure. Now I need the promotion policy.
A2: search_policy("senior developer promotion criteria") → Requires: 3+ years, ≥4.0 review avg
T3: Mario has 5+ years. Now I need his review scores.
A3: get_reviews("Mario Rossi") → Avg: 4.3/5.0
A4: finish("Yes — Mario meets both criteria: 5+ years tenure and 4.3 avg review.")

When ReAct Fails

Four failure modes and their fixes

FailureWhat HappensFix
Infinite loopsKeeps searching, never stopsmax_iterations = 10
Wrong toolSearches docs when it should query SQLBetter tool descriptions
Early stoppingStops after 1 hop when 3 are neededPrompt: “keep going until complete”
Context overflowToo many observations fill the windowSummarize past observations

Context Overflow Math

5 observations × 2K tokens each = 10K tokens of context consumed. With a 32K window, that’s 31% gone just on observations. Solution: summarize older observations to ~200 tokens each.

Self-RAG: The Model Decides ICLR 2024 Oral

Reflection tokens let the model critique its own generation

TokenQuestion It AsksValues
[Retrieve]“Should I retrieve here?”yes / no / continue
[IsRel]“Is the retrieved passage relevant?”relevant / irrelevant
[IsSup]“Is my answer supported by evidence?”fully / partially / no
[IsUse]“Is the overall response useful?”1–5 scale
The model is its own quality checker. It decides when to retrieve, judges relevance, and verifies that its answer is actually supported by evidence.

Asai et al. (2024) — “Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection” — ICLR 2024 (Oral, top 1%)

Self-RAG — Worked Example

The model retrieves only when it needs to

Query: “What is the capital of France?” → [Retrieve] = no
Model knows this → answers directly: “Paris”
vs.
Query: “What are Zucchetti’s Q3 2024 revenue figures?” → [Retrieve] = yes
Retrieves docs → [IsRel] = relevant → generates answer
[IsSup] = fully → answer is supported by evidence → output
Unlike ReAct which always uses tools, Self-RAG retrieves on-demand. Simple questions skip retrieval entirely → faster and cheaper.

Function Calling vs ReAct

When to use which — they’re complementary, not competing

Function CallingReAct
Best forDeterministic, known workflowsExploratory, open-ended tasks
StepsPredefined or fewDiscovered at runtime
LatencyLow (1–2 calls)Higher (3–10 calls)
CostLowHigher
ControlHigh — you define toolsLower — LLM improvises
Productionβœ… Most systems use thisResearch tasks, complex queries
In practice: use function calling for the 90% of queries that are routine. Add a ReAct-style reasoning loop for the 10% that are complex or ambiguous.

β˜• Break — 10 minutes

When we come back: Agentic RAG Architectures

So far: tools (Section 2) + reasoning (Section 3).
Next: put them together into a self-correcting RAG system.

Section 4 of 5

Agentic RAG
Architectures

RAG systems that think

Naive RAG vs Agentic RAG

Naive RAG (L4)

Query
→
Retrieve
→
Generate

Fixed. One shot. No quality check.

Agentic RAG (L7)

Analyze
→
Route
→
Retrieve
→
Grade
→
Generate

Dynamic. Self-correcting. Re-retrieves if needed.

Same pipeline, new control. The LLM controls the switches: should I retrieve? Was it good enough? Should I try again?

The Agentic RAG Pipeline

Full architecture — color-coded by origin

🧠 Query
Analyzer L7
→
πŸ”€ Router
L5
→
πŸ“š Vector L4
πŸ•ΈοΈ Graph L6
🌐 Web L5
→
πŸ“‹ Retrieval
Grader L7
→
✍️ Generate
+ Grade L7

If Retrieval Grader says ❌ → rewrite query → loop back. If Answer Grader says ❌ → retry.

β–  New in L7 (analyzers, graders)   β–  From L5 (routing, HyDE)   β–  From L6 (graph)

Component 1: Query Analyzer

L5 routing always retrieves. The Query Analyzer adds a new option: don’t retrieve at all.

Four Routes

RouteWhenExampleOrigin
β‘  Answer directlyLLM already knows“What is Python?”NEW
β‘‘ Search docsCompany-specific“What is our leave policy?”L5
β‘’ Query graphRelationship query“Who reports to Mario?”L6
β‘£ Search webReal-time info“What is EUR/USD today?”L5
Route β‘  is the innovation: if the question is simple enough, skip retrieval entirely. That’s the “adaptive” in Adaptive RAG.

Component 2: Smart Retriever

L5 gave you the tools. This agent orchestrates them.

What the Smart Retriever Does

StepWhatL5 Tool Used
1. Pick indexVector? Graph? SQL?Semantic routing
2. Formulate queryOptimize the search queryHyDE / query rewriting
3. Decide kHow many results to fetchAdaptive top-k
4. ParallelizeCall multiple sources at onceParallel FC (Section 2)
5. Re-rankScore results by relevanceCross-encoder (L5)
You built these components individually in L5. The Smart Retriever is an agent that runs them automatically based on the query.

Component 3: Retrieval Grader

After retrieval: is this context actually relevant?

βœ… Relevant

Use these docs for generation

⚠️ Partial

Retrieve more from different source

❌ Irrelevant

Reformulate query → retrieve again

LLM-as-Judge prompt:

“Given the query and retrieved documents, rate relevance as: RELEVANT, PARTIAL, or IRRELEVANT. Explain why.”

From L4: remember the 6 failure modes? “Wrong chunks,” “information not in docs.” The Retrieval Grader catches these in real time, before the LLM generates a wrong answer.

Component 4: Answer Grader

After generation: is my answer actually good?

Check 1: Relevance

“Does my answer address the question?”

Catches: off-topic answers, tangential information

Check 2: Groundedness

“Is my answer supported by the retrieved context?”

Catches: hallucination, information not in context

If either check fails → retry with different retrieval or query reformulation

This is the Reflection capability from slide 6. The system checks its own work before presenting the answer.

Adaptive RAG NAACL 2024

Route by query complexity — save cost on simple questions

Level A

Simple

No retrieval needed

Cost: $0.001

Level B

Moderate

Single retrieval

Cost: $0.005

Level C

Complex

Iterative retrieval (ReAct)

Cost: $0.02

A small classifier routes before the expensive pipeline starts.

Level A saves ~85% cost vs always retrieving. In typical enterprise deployments, most queries (60–70%) fall into Level A or B.

Jeong et al. (2024) — “Adaptive-RAG: Learning to Adapt Retrieval-Augmented LLMs through Question Complexity” — NAACL 2024

Corrective RAG — The Problem

What happens when retrieval returns garbage?

Scenario

“What is Zucchetti’s current remote work policy?”

Retrieve
→
Gets 2022 policy
(outdated)
→
Generate
→
❌ Wrong answer
confident but outdated
Standard RAG has no quality filter between retrieval and generation. If the retrieved docs are wrong, the answer is wrong. The LLM doesn’t know the difference.

Corrective RAG — The Solution arXiv 2024

Three-way grading: Correct, Ambiguous, or Incorrect

βœ… Correct

Retrieved docs are relevant and current

→ Use docs directly

⚠️ Ambiguous

Partially relevant or potentially outdated

→ Supplement with web search

❌ Incorrect

Docs are irrelevant or wrong

→ Discard, fall back to web only

CRAG adds a knowledge refinement step between retrieval and generation. The key innovation: the Ambiguous path — supplement rather than discard.

Yan et al. (2024) — “Corrective Retrieval Augmented Generation” — arXiv 2024

CRAG — Worked Example

“What is Zucchetti’s remote work policy?”

Retrieve: finds “Remote Work Policy v2.1 (2022)” from internal docs
Grade: Document is about remote work βœ… but dated 2022 ⚠️ → Ambiguous
Web Search: “Zucchetti remote work policy 2024 update” → finds press release about hybrid model
Combine: internal doc (2022 baseline) + web result (2024 updates) → comprehensive answer
Generate: “Zucchetti’s policy originally allowed 2 days/week remote (2022). As of 2024, this was expanded to a hybrid model with 3 days/week for eligible roles.”

Building It: Architecture Choices

How do you implement an agentic RAG system?

State Machine (LangGraph)

Explicit nodes and edges

Predictable execution path

Easy to debug and test

You define every transition

βœ… Start here

Free-Form Agent (ReAct)

LLM decides the next step

Flexible, handles unexpected cases

Harder to debug

Requires guardrails

⚠️ Graduate to this

Recommendation: start with a state machine for predictability. Add free-form agents for the complex edge cases your state machine can’t handle.

The Full Picture

You’re not starting from scratch — you’re adding intelligence to what you already built

πŸ†• New in L7

Query Analyzer

Retrieval Grader

Answer Grader

Adaptive routing

Self-correcting loop

πŸ”§ From L5

HyDE

Re-ranking

Semantic routing

Query decomposition

πŸ•ΈοΈ From L6

Knowledge graphs

Graph traversal

Entity extraction

Graph + vector hybrid

L7 doesn’t replace L4–L6. It wraps them in an intelligent controller. The agent decides which tools to use — the tools themselves are everything you’ve already built.

Section 5 of 5

Multi-Agent
Systems

When one agent isn’t enough

Why Multi-Agent?

Three reasons to split work across agents

Context Limits

One agent can’t hold 50 documents + conversation history + tool results

Specialization

A “researcher” agent + “writer” agent > one generalist

Parallelism

Multiple agents work simultaneously on different sub-tasks

Analogy: one chef can cook dinner. But a restaurant needs a kitchen brigade: sous chef, pastry chef, line cooks — each specialized.

Pattern 1: Sequential (Pipeline)

Agents pass work linearly — each has focused context

πŸ” Researcher
finds data
→
πŸ“Š Analyst
runs calculations
→
✍️ Writer
drafts report
→
πŸ” Reviewer
checks facts

When to use: well-defined workflows with clear stages. Each agent has its own system prompt, tools, and output schema.

Pattern 2: Hierarchical (Supervisor)

A manager agent routes sub-tasks to specialists

🎯 Supervisor

Sees the big picture, delegates tasks

πŸ“Š Data Agent

SQL queries

πŸ“ Writer Agent

Drafts text

πŸ” Reviewer Agent

Checks facts

When to use: complex tasks needing dynamic decomposition. The supervisor decides which worker to call based on the current state.

Supervisor — Worked Example

“Write a report on our Q3 sales performance”

Supervisor: I need sales data first. Delegating to Data Agent.
Data Agent: SELECT region, SUM(revenue) FROM sales WHERE quarter='Q3' → returns table
Supervisor: Data received. Now I need analysis. Delegating to Analyst.
Analyst Agent: Computes YoY growth, identifies top/bottom regions → returns insights
Supervisor: Analysis ready. Delegating report writing.
Writer Agent: Drafts report with data tables + insights → returns draft
Reviewer Agent: Cross-checks numbers against source data → Approved

Guardrails & Safety

“Agents without guardrails are interns with root access”

GuardrailWhat It PreventsImplementation
πŸ” Tool authorizationAgent calls unauthorized APIWhitelist of allowed tools per agent
πŸ›‘οΈ PII filteringAgent exposes personal dataRegex + NER scan on outputs
πŸ‘€ Human-in-the-loopHigh-stakes actions without approvalPause before delete, purchase, send
πŸ’° Cost budgetRunaway agent burns $1000Max tokens / max $ per query
⏱️ TimeoutInfinite loop agentMax 30 seconds per query

Production Considerations

Four pillars for production-grade agents

PillarWhyTools
ObservabilityTrace every tool call, reasoning stepLangSmith, Phoenix, Arize
Cost ControlBudget per query, cache resultsToken counting, result caching
LatencyMinimize agent hops, parallelizeParallel FC, async execution
Error HandlingGraceful degradationFallback to simpler pipeline
Preview of L8: we’ll dive deep into observability and evaluation — how to measure if your agent is actually working.

The Agent Framework Landscape

FrameworkApproachBest For
Custom PythonFunction calling + your codeLearning, max flexibility
LangGraphState machines — explicit nodes/edgesProduction systems, max control
CrewAIRole-based agents with goalsQuick prototyping, team metaphor
MS Agent FrameworkEnterprise-grade, .NET + PythonAzure / Microsoft ecosystem
Default recommendation: start with custom Python + function calling. Graduate to LangGraph when you need complex state management. Use CrewAI for fast prototyping.

When NOT to Use Agents

Don’t use a chainsaw to cut butter

Query TypeRight ToolNOT Agents
Simple factualRAG (L4)Overkill — one retrieval is enough
Vocabulary mismatchHyDE (L5)Agents won’t help with embeddings
Multi-sourceRouting (L5)Static routing is cheaper
Relationship queriesGraph RAG (L6)Graph traversal is deterministic
Multi-step + dynamic + toolsAgentic RAG (L7) βœ…This is the sweet spot
Use the simplest tool that solves your problem. Agents add cost, latency, and complexity. Reserve them for queries that genuinely need dynamic reasoning.

The Cost of Agency

Approximate figures — vary by model, provider, and implementation

ApproachLLM CallsCost/QueryLatencyWhen
Naive RAG (L4)1$0.0020.3sSimple queries
Advanced RAG (L5)2–3$0.0050.8sComplex retrieval
Agentic RAG (L7)3–10$0.022–5sDynamic multi-step
Multi-Agent (L7)5–20$0.055–15sComplex workflows
Agentic RAG is 10× more expensive than naive RAG. Worth it for “book me a flight that doesn’t conflict with my meetings.” Overkill for “what is the sick leave policy?”

Key Takeaways

1. Function calling = LLM generates JSON, your code executes. The LLM never touches the internet.

2. ReAct = reasoning + acting. Each fact is grounded by a real tool call — hallucination dramatically reduced.

3. Agentic RAG = a self-correcting pipeline. Grading (retrieval + answer) is what makes it “agentic.”

4. You’re not starting from scratch. L7 wraps L4–L6 components in an intelligent controller.

5. Multi-agent = specialization when one context window isn’t enough.

6. Start simple. Add agency only when the query genuinely needs dynamic reasoning.

The Full Retrieval Stack

Four levels of retrieval sophistication — you now have all of them

L7   Autonomous RAG — LLM decides what, when, and how to retrieve

L6   Graph RAG — follow relationships between entities

L5   Smart RAG — re-rank, rewrite, route, decompose

L4   Basic RAG — embed, search, generate

The skill is knowing which level to use. Not every query needs L7. Most need L4 or L5.

Choosing Your Level

A decision flowchart for your next RAG project

QuestionAnswerUse
Simple factual query?YesL4 — Basic RAG
Vocabulary mismatch or multi-source?YesL5 — HyDE, routing
Needs to follow relationships?YesL6 — Graph RAG
Multi-step, dynamic, needs tools?YesL7 — Agentic RAG
Too complex for one agent?YesL7 — Multi-Agent

What’s Next

Next → Lecture 8: RAG Evaluation & Observability

You’ve built increasingly powerful systems. But how do you know they’re actually working?

Metrics, tracing, and evaluation frameworks.

Questions?

Thank you! See you next session.

Kamyar Zeinalipour — Zucchetti LLM Course