Video summary

Complete Agentic AI Course In 10 Hours- Langchain, Langgraph, RAG,Vectorless RAG, Guardrails,Evals

Main summary

Key takeaways

Educational

Main ideas & lessons (high-level)

  • The video is an agentic AI course covering major modern topics: LangChain v1, LangGraph, RAG, Vectorless RAG, Guardrails, Evals, LLM Gateways, Deep Agents, and LLM security.
  • Core recurring theme: build reliable AI systems by combining:
    • Agents (LLMs that can decide to call tools)
    • Graphs / stateful workflows (LangGraph)
    • Retrieval
      • Traditional RAG with vector DBs
      • Vectorless RAG with document reasoning trees
    • Safety controls (guardrails, PII detection, human-in-the-loop)
    • Evaluation (correctness/groundedness/relevance metrics using LLM-as-judge)
    • Operations layer (LLM gateways: routing, fallbacks, caching, observability, cost tracking)

Detailed methodology / instruction-style content

1) Course plan & module structure

  • Learn generative AI + agentic AI with LangChain
  • Do a LangGraph crash course focusing on building agentic applications
  • Implement retrieval strategies:
    • Traditional RAG
    • Agentic RAG
    • Vectorless RAG
    • Explain differences (vector RAG vs vectorless RAG)
  • Cover deep agents / deep research agents
  • Cover AI security
    • Guardrails
    • LLM evaluation techniques
  • Finish with LLM gateways + implementation

2) Build an agent with LangChain (LangChain v1 approach)

Conceptual steps

  • Define an LLM (“model”)
  • Create an agent using create_agent (LangChain)
  • Provide:
    • model
    • tools (initially empty, then later add tools)
    • system prompt
  • Explain “agent basics”:
    • When user asks something requiring fresh info, the LLM decides to call a tool
    • Tool output becomes context for final answer

Tool definition (example)

  • Write a Python function with:
    • Input arguments (e.g., city: str)
    • Return a string response (context)
    • A docstring describing purpose (enables LLM tool selection)

Tool execution loop

  • Invoke agent with message(s) in the expected input format:
    • Use messages containing roles like user
  • If the model returns a tool call, execute it, append tool results back into the conversation
  • The agent then generates final response using tool context

Common runtime detail

  • agent.invoke expects a dictionary with a messages key (not a raw string)

3) Model integration in LangChain (OpenAI / Gemini / Groq)

Setup

  • Load API keys from an .env file
  • Initialize chat models in one of two ways:
    • init_chat_model(provider:model_name)
    • Provider-specific wrappers:
      • ChatOpenAI
      • ChatGoogleGenerativeAI
      • ChatGroq

Invocation

  • Call model.invoke(...)
  • Stream results using model.stream(...) if needed

4) Streaming vs batch

Streaming

  • Use model.stream() to receive output chunks incrementally
  • Display token/chunk text as it arrives (improves UX for long generations)

Batch

  • Use model.batch([...inputs]) for multiple independent requests in parallel
  • Control parallelism using max_concurrency

5) Tool creation & tool execution loop in LangGraph/LangChain

Create tools using decorators

  • Import tool decorator
  • Decorate a function so LangChain can treat it as a callable tool
  • Include a descriptive docstring for arguments/behavior

Bind tools to LLM

  • Use something like model.bind_tools(tools) so the LLM can decide when to call them

Tool loop

  • Tool call occurs inside the model response
  • Tool results are appended back to messages
  • Then LLM produces the final response (or continues tool calling)

6) Messages & structured formats

Message types

  • SystemMessage: instructions for behavior
  • HumanMessage: user input
  • AIMessage: model output (may include tool calls/metadata)
  • ToolMessage: tool output

Structured output (schema-based responses)

  • Motivation: enforce output format for downstream processing
  • Methods covered:
    • Pydantic models (runtime validation + nested structure + field validation)
    • TypedDict (no strict runtime validation)
    • Data classes (schema via dataclass)

7) Middleware in LangChain agents (control + reliability layer)

What middleware does

  • “Hooks” around agent execution:
    • Before model call
    • Before/after tool call
    • After agent output
  • Provides safety and control such as:
    • Summarization to manage token growth
    • Retries/fallbacks/termination logic
    • Rate limits
    • Guardrails
    • PII detection
    • Human approval flows

Summarization middleware examples

  • Trigger summarization based on:
    • Message count
    • Token count
    • Fraction of context window (scaled by model capacity)
  • Keep recent messages while compressing older history

Human-in-the-loop middleware

  • Pause execution before sensitive tool calls
  • Human chooses: approve / edit / reject
  • Use thread IDs + checkpointing so approval is tied to a session

8) LangGraph crash course: build a basic chatbot graph

Core components

  • State: data shared through nodes
  • Nodes: computation units (functions)
  • Edges: flow control between nodes

Example workflow (YouTube → transcript → title → content)

  • Start node: takes input (e.g., YouTube URL)
  • Node 1: transcript extraction
  • Node 2: title generation
  • Node 3: content generation
  • End node: final assembled output

Chatbot graph

  • Single-node graph:
    • Start → LLM chatbot node → End
  • Use reducers like add_messages so conversation history appends instead of overwriting

Graph invocation and streaming

  • graph.invoke(...) returns final state/messages
  • graph.stream(...) yields incremental updates/events:
    • mode="updates" shows only the latest node output
    • mode="values" shows accumulated conversation state

9) LangGraph tools & conditional routing (tool-calling graphs)

Pattern

  • Node 1: “tool-calling LLM” (LLM with bound tools)
  • Conditional edge:
    • If last AI message is a tool call → go to ToolNode
    • Else → go to End
  • ToolNode executes the chosen tool

React agent improvement

  • Instead of sending tool outputs directly to End:
    • Send tool results back to the tool-calling LLM node
    • Repeat until all sub-requests are resolved
  • “Act → Observe → Reason” loop enables multi-step tool use in one query

10) LangGraph memory (checkpointing by thread ID)

Problem addressed

  • Without persistent state, the chatbot “forgets” earlier messages (e.g., name)

Solution

  • Add an in-memory checkpointer:
    • store state per thread_id
  • Reuse same config with same thread ID on subsequent calls
  • Result: conversation context persists across graph invocations

RAG methodology (traditional vector RAG)

11) RAG definition and pipeline

Key idea

  • Improve LLM responses by grounding them in an external knowledge base
  • Avoid hallucinations and avoid expensive fine-tuning

Two main pipelines

  1. Data injection pipeline

    • Load documents (PDF/HTML/TXT/etc.)
    • Parse into a document structure (page/content + metadata)
    • Chunk documents into manageable parts
    • Embed chunks into vectors
    • Store vectors in a vector store (vector DB)
  2. Query retrieval pipeline

    • Embed user query
    • Similarity search in vector DB
    • Retrieve relevant chunks as context
    • Augmented prompt → LLM generation

Document structure

  • page_content: actual text
  • metadata: source file, page number, dates, etc.
  • Metadata enables filtering and better retrieval

Chunking

  • Must respect embedding/LLM context limits
  • Use overlapping chunks (chunk overlap) to reduce boundary loss

Embedding

  • Convert chunk text to vectors (open-source or paid embeddings)

Vector store retrieval

  • Retrieve top-k most similar items
  • Use similarity scores and optional thresholds

12) Retrieval + generation integration

Simple RAG function

  • Retrieve context using retriever
  • Build prompt with context + user question
  • Invoke LLM
  • Return answer

Enhanced RAG

  • Return additional artifacts:
    • sources (filename + page number + similarity score)
    • confidence score
    • optional full context
  • Uses prompt templates and richer outputs

Vectorless RAG (PageIndex-style reasoning tree)

13) How vectorless RAG works (core algorithm)

Contrast with vector RAG

  • Traditional vector RAG:
    • chunk → embed → vector search → retrieve top chunks → LLM answers
  • Vectorless RAG:
    • no embedding + no vector DB
    • build an LLM tree / JSON tree index from the document

Vectorless steps

  1. Parse document headings / TOC
    • If TOC exists: use table of contents to create hierarchical structure
    • If TOC missing:
      • scan headers / infer structure using LLM over pages
  2. Build hierarchy
    • Nodes represent sections/pages/subsections
  3. Summarize each node
    • Each node stores a summary of its section (used later as context)
  4. At query time
    • LLM receives JSON tree index as context
    • LLM “navigates” the tree (tree search)
    • Selects relevant nodes
    • Extracts node summaries/sections
  5. Generate answer
    • LLM answers using selected section summaries
    • Provides explainable navigation path + citations (section + page)

Deep agents (planning + subagents + file-based memory)

14) What makes a deep agent different

Compared to “shallow” agent loops:

  • Shallow agent:
    • LLM decides tool call or direct output
    • Limited/no explicit planning, limited reasoning depth
  • React agent:
    • “Act/Observe/Reason” loop but still no deep planning/state structure beyond tools
  • Deep agent:
    • Planning module (creates a to-do list)
    • Subagents (specialized workers executing plan items)
    • System prompt (behavior & role)
    • File system as persistent shared context (between subagents)

Deep research example

  • Plan tasks (research, deeper research, draft writing, copyright check)
  • Subagents execute in parallel or sequence
  • Shared file system stores intermediate results

Guardrails (AI security controls)

15) Guardrails definition & why

  • Safety mechanism that controls:
    • what enters and leaves an agent pipeline
  • Ensure:
    • safe inputs
    • approved actions
    • validated outputs
  • Example threats mentioned:
    • hacking instructions
    • PII leakage (emails, credit cards, IPs, etc.)
    • prompt injection / jailbreaks
    • risky tool actions

16) Two guardrail approaches

  • Deterministic: rule/keyword/regex checks (cheap, no LLM calls)
  • Model-based: use an LLM to classify safe/unsafe (semantic, but costly)

17) Built-in guardrail middleware

  • PII middleware:
    • detect PII types (email, credit card, IP, MAC, URL, API keys)
    • strategies: redact/mask/hash/block(raise exception)
    • applies to input/output/tool calls
  • Human-in-the-loop middleware for sensitive actions:
    • pauses before executing tool calls
    • supports approve/edit/reject

18) Custom guardrails via middleware hooks

  • Before-agent hook:
    • validate/filter incoming user input (blocks dangerous content early)
  • After-agent hook:
    • validate/mutate model output before returning to user
  • Layered guardrails:
    • stack multiple middlewares (PII + content filter + human approval + safety model checks)

Evaluation (chatbot & RAG)

19) How evaluation is organized (LangSmith)

  • Create datasets (inputs + expected outputs/ground truth)
  • Evaluate using:
    • LLM-as-judge
    • custom metrics
    • compare outputs across models

20) Chatbot evaluation metrics (examples)

  • Correctness: compare response to ground truth
  • Concision: response length relative to expected output length
  • Run experiments per model and compare results

21) RAG evaluation metrics (LLM-as-judge)

Four key metrics (as described):

  1. Retrieval relevance: do retrieved docs match the query?
  2. Groundedness: is the answer grounded in retrieved docs?
  3. Answer relevance: does the answer address the question?
  4. Correctness: does the answer match ground truth?

Implementation style

  • Use schema-backed structured output for evaluator results (boolean + explanation)
  • Run experiment over dataset and view scores in LangSmith

LLM Gateways (production operations layer)

22) What an LLM gateway is

  • Smart middleware between app and LLM providers
  • Centralizes:
    • routing
    • fallbacks
    • caching
    • load balancing
    • guardrails
    • observability + cost tracking
    • evaluation integration

23) Core gateway capabilities

  • Unified API: one function call for many providers
  • Automatic fallbacks: if primary model/provider fails, try backups
  • Smart routing: choose model based on request type
  • Load balancing: spread traffic across API keys/providers to avoid rate limits
  • Caching: avoid repeated calls for identical prompts
  • Observability: log prompts/latency/cost and integrate dashboards
  • Cost tracking: compute per-call cost automatically

24) Example: smart router + fallbacks

Flow

  • Classify task (code vs summary vs general)
  • Select model from a routing map
  • Use fallbacks if primary fails
  • Return response + show latency and cost

Speakers / sources featured

  • Krishna — host/instructor (main speaker throughout).
  • Auto-generated transcript source — YouTube video content (no other explicit named speakers detected).

Original video