Agentic AI With Langgraph And MCP Crash Course-Part 1 Timeline Summary [0]

thumbnail

This summary outlines the structure of the crash course and details the initial steps covered in Part 1, focusing on building a basic chatbot and integrating tools using LangGraph and MCP concepts. [0]

Course Overview and Part 1 Topics [0]

  1. Course Structure: The crash course is divided into three main parts. [1]
    1. Each part is estimated to be around two to three hours long. [2]
  2. Part 1 Focus: Covering fundamental techniques for building agentic AI applications. [4]
    1. Topics include building a chatbot. [4]
    2. Integrating single and multiple tools into a chatbot. [4]
    3. Adding human-in-the-loop feedback mechanisms during graph execution. [4]
    4. Using different streaming techniques. [4]
    5. Building MCP (Multi-Agent Communication Protocol) from scratch. [4]
    6. Discussing core LangGraph concepts: states, graphs, nodes, and edges. [4]
    7. Covering usage via the graph API. [4]
    8. Part one duration is approximately 2 hours 50 minutes. [5]

Advanced Concepts in Part 2 and Projects in Part 3 [6]

  1. Part 2: Covers advanced LangGraph concepts and workflows. [7]
    1. Focuses on applications where agents communicate to solve complex workflows. [8]
    2. Handling multi-state management even in multi-agents. [9]
    3. Introducing the functional API instead of just graph APIs. [11]
    4. Debugging and monitoring in the LangGraph studio using LangChain. [11]
    5. Part two is estimated to be around 2 hours long. [13]
  2. Part 3: Focuses on end-to-end projects. [13]
    1. Covering LLMOps pipeline and deployment techniques. [14]
    2. Exploring evaluation techniques and metrics in LLMs. [14]
    3. Using tools like MLflow and AWS for metric tracking. [14]
    4. Displaying reports using Grafana. [14]
    5. Deployment using Hugging Face Spaces. [14]

Initial Setup and Environment Management [15]

  1. Material Access: Viewers should download materials from the description and practice. [17]
  2. Project Start: Begin building a basic chatbot using LangGraph. [20]
  3. Workspace Setup: An empty folder is designated as the project workspace. [21]
  4. Tool Selection: VS Code is used for coding purposes. [26]
  5. Environment Creation: Creating an environment is necessary for any project. [28]
  6. Package Manager Choice: Using UV package manager instead of Conda. [30]
    1. UV is extremely fast because it is written in Rust. [30]
    2. UV is 10 to 100 times faster than pip. [33]
    3. It replaces pip, pip-tools, poetry, pyenv, twine, and virtualenv. [34]
    4. UV provides comprehensive project management and a universal lock file. [35]
    5. It manages different Python versions within the same project. [36]
  7. UV Installation:
    1. For Mac OS or Linux, execute the provided command in the terminal. [37]
    2. For Windows, use PowerShell to execute the provided command. [38]
    3. If using pip, install via pip install uv. [38]

Initializing Project with UV [39]

  1. Initialization: After UV installation, initialize the project workspace using uv init. [41]
  2. Created Files: Files created include .gitignore, python_version, main.py, and pyproject.toml. [43]
  3. Python Version: The created Python version is 3.13. [43]
  4. pyproject.toml: Contains brief project information; dependencies section is currently empty. [45]

Installing Dependencies [48]

  1. Requirements File: Create a requirements.txt file. [48]
  2. Libraries to Install: Install LangGraph, LangChain, and Lang. [49]
    1. LangChain: Used for building generative AI applications and chatbots. [53]
    2. Lang: Used for tracking and evaluation directly in the LangGraph cloud. [54]
  3. Virtual Environment Creation: Create the virtual environment using uv venv. [57]
    1. The environment name defaults to venv. [59]
  4. Environment Confirmation: The virtual environment is created with Python version 3.13.2. [61]
  5. Activation: Activate the environment using the provided command. [63]
    1. The activated environment name is agentic_lang_graph. [66]
  6. Package Installation: Install libraries using uv -r requirements.txt. [68]
    1. This command replaces pip install -r requirement.txt. [68]

Building the Basic Chatbot Structure [69]

  1. Project Folder: Create a folder named one containing basic_chatbot. [71]
  2. Notebook Creation: Create a file named basic_chatbot.ipynb. [75]
  3. Kernel Selection: Select a kernel when opening the Jupyter notebook. [77]
  4. IPI Kernel Installation: Install ipykernel using uv add ipykernel. [78]
    1. This library is required to run content in Jupyter notebooks. [80]
  5. Initial Test: A syntax error occurred initially when testing 1 + !. [86]
    1. Testing 1 + 1 confirmed functionality. [90]
  6. Goal: Build a basic chatbot using LangGraph's graph API. [91]
    1. The functional API exists but the graph API is deemed more efficient for learning. [95]

LangGraph Components Explained [99]

  1. Core Components: LangGraph has three important components: edges, nodes, and state. [100]
  2. Use Case Example: Converting a YouTube video into a blog post. [103]
    1. Workflow Steps:
    2. Take the transcript from the YouTube video. [109]
    3. Generate the title using the transcript. [113]
    4. Generate the content using the title and transcript. [114]
  3. Graph Structure in Use Case:
    1. Start Node: Input is the YouTube URL. [127]
    2. Transcript Generator Node: Takes URL, outputs transcript. [131]
    3. Uses third-party libraries like YT loader in LangChain. [135]
    4. Title Generator Node: Takes transcript, outputs title. [144]
    5. Content Generator Node: Takes title and transcript, outputs content. [147]
    6. End Node: Output is the final content. [147]
  4. Edges: Edges define the flow of information from node to node. [141]
  5. Node Implementation: Each node requires implementation defining its functionality. [142]
  6. State Importance: State defines variables accessible by any node in the graph. [154]
    1. Variables like Transcript, Title, and Content can be saved in state. [157]
    2. This allows the entire graph to maintain context; it is called a state graph. [171]
    3. State graph is distinct from external memory, which will be discussed later. [172]

Building the Basic Chatbot with State Graph [178]

  1. Basic Chatbot Flow: Start node -> Chatbot node -> End node. [178]
    1. The chatbot node integrates an LLM and prompt to handle input/output. [181]
  2. Imports: Import necessary libraries for state management and graph creation. [192]
    1. annotated from typing (adds context-specific metadata to a type). [193]
    2. type from typing_extensions. [195]
    3. StateGraph, start, and end from langgraph.graph. [196]
    4. add_messages from langgraph.graph.message (a reducer). [199]
  3. Reducer Function (add_messages): Used to append messages to the state list. [202]
    1. The state variable messages will be a list type. [205]
    2. It ensures messages are appended, not replaced, preserving conversation history. [211]
  4. State Class Definition: Define the state class inheriting from TypedDict. [218]
    1. The state class returns a dictionary type. [220]
    2. messages variable uses Annotated to specify the list type and the add_message reducer. [227]
  5. Graph Builder Creation: Create the graph builder using StateGraph(State). [238]

LLM Initialization and Chatbot Node Definition [246]

  1. Environment Setup for LLM: Install python-dotenv using uv add -r requirement.txt. [248]
  2. Loading Environment: Import os and use load_dotenv() to load keys from .env file. [254]
  3. API Key: Paste the Groq API key into the .env file. [255]
  4. LLM Initialization (Groq):
    1. Option 1: Initialize via ChatGroq directly (requires installing langgraph). [265]
    2. Option 2 (Generic): Use init_chat_model from langchain.chat_models. [278]
    3. Model name example: Groq:Llama3-8b-8192. [283]
  5. LLM Definition: The initialized object becomes the LLM. [287]
  6. Chatbot Node Definition: Define the node function chatbot_node. [291]
    1. It inherits the state object: state: state. [292]
    2. Functionality: Returns llm.invoke(state.messages). [295]
    3. The input message is state.messages. [301]
    4. The response is appended to the messages variable in the state. [302]

Building and Compiling the Graph API Structure [306]

  1. Graph Construction: Use the graph_builder (which is the StateGraph). [307]
  2. Adding Nodes:
    1. Add the node named LLM chatbot using the chatbot_node definition. [309]
  3. Adding Edges: Define the flow using add_edge. [316]
    1. Edge 1: start to LLM chatbot. [318]
    2. Edge 2: LLM chatbot to end. [319]
  4. Compilation: Compile the graph using graph_builder.compile() to enable execution. [322]
  5. Visualization: Visualize the graph structure using display and get_graph(). [329]
    1. The visualization shows start -> LLM chatbot -> end. [336]

Executing the Basic Chatbot Graph [339]

  1. Invocation: Run the graph using graph.invoke(). [339]
  2. Input Format Issue: Initial invocation without specifying the state key failed. [340]
    1. The input must be a dictionary matching the state keys, e.g., {"messages": "Hi"}. [346]
  3. Execution with Correct Input: Invoking with {"messages": "Hi"}. [347]
    1. An Invalid API key error occurred due to kernel restart necessity. [349]
  4. Successful Execution: The graph runs, treating input as HumanMessage. [359]
    1. The response is an AIMessage: "Hi, it's nice to meet you." [362]
  5. Checking State: Inspecting the messages variable in the state shows appended history. [365]
    1. Both Human and AI messages are appended due to the add_messages reducer. [370]
  6. Retrieving Last Content: Get the last message content using response.messages[-1].content. [374]
  7. Streaming Introduction: Using graph.stream() instead of graph.invoke(). [377]

Streaming Techniques: Invoke vs. Stream [378]

  1. Stream Execution: Using graph.stream with input {"messages": "Hi, how are you"}. [380]
  2. Event Output: The stream yields events containing node execution details (e.g., AI messages, LLM chart). [386]
  3. Extracting AI Message: Iterating through event.values to print the AI message content. [389]
    1. This confirms streaming provides intermediate results. [394]

Integrating External Tools: Tool Calling [398]

  1. Use Case: Asking the chatbot for recent AI news requires external information. [401]
  2. LLM Limitation: LLMs lack live information, necessitating a tool call. [405]
  3. New Workflow: Input -> Chatbot -> Tool Node -> End. [409]
    1. The chatbot node must recognize the need for a tool call. [407]
    2. Tools can include third-party APIs like Tavily search. [408]
  4. LLM Binding: The LLM acts as the brain, deciding which tool to call. [420]
    1. Tools must be binded with the LLM. [422]
    2. Custom functions require a doc string to inform the LLM about inputs/arguments. [428]

Implementing Tool-Integrated Chatbot Graph [438]

  1. New Tool Installation: Install langchain-tavily via uv add -r requirements.txt. [475]
  2. Tavily Setup: Log in to tavily.com to get a free API key and paste it in .env. [481]
  3. Tavily Tool Creation: Import and initialize TavilySearchResults tool with max_results=2. [495]
  4. Custom Tool Creation (Multiply): Define a function multiply(a: int, b: int) with a doc string. [511]
    1. Doc string explains: "multiply a and b." [515]
  5. Binding Tools: Bind the list of tools (Tavily search, multiply) to the LLM: llm.bind_tools(tools). [521]
  6. Graph Structure: Start -> Tool Calling LLM -> Tools Node -> End. [527]
  7. Tool Node Import: Import ToolNode from langgraph.prebuilt. [531]
  8. Node Definitions:
    1. Tool Calling LLM Node: Defined as tool_calling_llm. [539]
    2. Functionality: llm_with_tools.invoke(state.messages). [560]
    3. Tools Node: Defined as tools. [549]
    4. Implementation uses ToolNode initialized with the list of all tools. [551]

Conditional Edges for Tool Execution [562]

  1. Conditional Edges: Used when a node has multiple potential next steps. [568]
  2. Edge Setup: Use builder.add_conditional_edges(source_node, condition_function). [569]
  3. Tool Condition: Import and use tools_condition for routing decisions. [570]
    1. Condition Logic:
    2. If the latest assistant message is a tool call, route to the Tool Node. [573]
    3. If it is not a tool call, route to the End Node. [577]
  4. Final Edge: Add a final edge from the Tools Node to the End Node. [587]
  5. Compilation and Visualization: Compile the graph and visualize it. [589]
    1. Visualization shows: Start -> Tool Calling LLM -> (Conditional Edges) -> Tools -> End. [610]

Testing Tool Integration and Debugging [611]

  1. Invocation Test 1 (Tavily): Invoke with query: "What is LangGraph?" [613]
    1. Result: The graph correctly made a tool call to Tavily search. [618]
    2. The tool returned search results content. [631]
  2. Invocation Test 2 (Multiply): Invoke with query: "What is 5 * 2?" [635]
    1. Initial Issue: The operation failed because the return statement in multiply was missing (return a * b). [638]
    2. Fix: Corrected the multiply function definition. [643]
    3. Result: The LLM correctly called the multiply tool, returning 10. [648]
  3. Combined Query Test: Input: "What is 2 * 3 and then multiply by 10?" [651]
    1. Result: The graph executed both tool calls sequentially. [657]
  4. Complex Query Test: Input: "Give me the recent AI news and then multiply 5 by 10." [665]
    1. Observation: Tavily search was performed, but the execution went to End before the multiplication tool call. [670]

Introduction to React Agent Architecture [667]

  1. Problem: The simple tool-calling graph stops after the first tool call if it routes to End. [678]
  2. Solution: The output from the Tool Node must loop back to the Tool Calling LLM. [678]
  3. React Agent: This interaction pattern (LLM deciding next step based on tool output) is called the React Agent architecture. [679]
  4. React Key Terms:
    1. Act: LLM makes a tool call. [705]
    2. Observe: LLM observes the tool output. [706]
    3. Reason: LLM decides the next action (call another tool or go to End). [707]
  5. React Graph Change: The edge from the Tools Node must go back to the Tool Calling LLM node. [717]
  6. Complex Query Result with React: The agent successfully performed Tavily search, then used the result to decide the next step (multiplication), yielding the final combined answer. [723]

Implementing Memory for Persistence [728]

  1. Memory Purpose: Solves the problem of Persistent Checkpointing (forgetting previous interactions). [729]
  2. Memory Failure Example: The basic graph forgot the user's name ("Kish") after the first interaction. [731]
  3. Memory Implementation: Use MemorySaver from langgraph.checkpoint.memory. [748]
    1. MemorySaver is an in-memory checkpoint saver using a default dictionary. [757]
    2. It saves information executed at every node for later recall. [760]
  4. Adding Memory to Compilation: Pass the memory object in the checkpoint parameter during compilation: builder.compile(..., checkpoint=memory_saver). [765]
  5. Invocation with Config: When invoking, a configuration dictionary containing a unique thread ID is required. [769]
    1. Config structure: {"configurable": {"thread": "unique_id"}}. [778]
  6. Testing Memory:
    1. First invocation: User states name ("Hi, my name is Kish"). [788]
    2. Second invocation (same thread ID): User asks, "What is my name?" [806]
    3. Result: The graph remembers the name is "Kish" because of the memory saver. [811]

Streaming Techniques Revisited: Update vs. Value Mode [814]

  1. Streaming Methods: graph.stream() and agraph.stream() (for async). [815]
  2. Modes: Both methods accept modes: update and value. [833]
  3. Conceptual Difference:
    1. Update Mode: Only displays the message currently being updated by the executing node. [857]
    2. Value Mode: Appends all messages from the start of the stream execution, including previous ones. [860]
  4. Practical Demonstration:
    1. Using mode="updates" showed only the latest AI message output. [869]
    2. Using mode="values" showed both the preceding Human message and the subsequent AI message. [873]
  5. Conversation History Check: When adding a second prompt ("I also like football") using mode="values", the output included the entire previous conversation history plus the new AI response. [883]

Human-in-the-Loop (Human Feedback) [914]

  1. Concept: Interrupting workflow execution to allow human feedback/approval. [915]
  2. Use Case: A tool call to Human Assistance interrupts the flow. [929]
    1. If the human approves/provides feedback, execution resumes. [935]
  3. New Tool: Define a human_assistance tool that takes a query and returns a human response. [949]
    1. This tool uses the doc string: "request assistance from a human." [952]
  4. Graph Modification: The Tools Node now contains both Tavily and Human Assistance tools. [962]
  5. Execution Test: Input query asks for expert guidance, matching the human assistance doc string. [964]
    1. Result: The LLM correctly called the human_assistance tool instead of Tavily. [986]
  6. Resuming Flow: After the human provides a response (human_response), use the resume command. [995]
    1. Command structure: graph.stream(..., resume={"data": human_response}). [996]
  7. Resumed Execution: The execution continues, incorporating the human feedback into the final AI response. [998]

Introduction to MCP Servers and Clients [1005]

  1. Next Topic: Building MCP servers and integrating them with the application client. [1006]
  2. MCP Diagram Components:
    1. MCP Servers: Host multiple tools (e.g., math, weather API). [1010]
    2. Provides context, tools, and prompts to the client. [1016]
    3. MCP Client: Maintains a connection inside the host application. [1016]
    4. App: The chatbot application using LangChain/LangGraph. [1017]
  3. Communication Flow: LLM decides to call an MCP server tool (e.g., weather). [1030]
    1. The MCP Client facilitates the call via MCP Protocol. [1037]
  4. Implementation Focus: Creating MCP servers and clients from scratch. [1047]
    1. Using the LangChain Adapters library. [1048]
  5. Transport Protocols: Communication between client and server uses transport protocols. [1050]
    1. Protocols discussed: STDIO and Streamable HTTP. [1053]

Setting Up the Project Workspace for MCP [1058]

  1. Project Location: Working in the MCP_demo_LangChain folder using Cursor IDE. [1060]
  2. UV Initialization: Initialize the workspace using uv init. [1064]
    1. Python version set to 3.13. [1069]
  3. Virtual Environment: Create environment using uv venv and activate it. [1073]
  4. Requirements File: Create requirement.txt for necessary libraries. [1086]
  5. Required Libraries:
    1. LangChain-Groq (implied, based on previous setup). [1090]
    2. LangChain Adapters (langchain-mcp-adapters). [1090]
    3. Fast MCP (fast-mcp). [1091]
    4. Fast MCP provides a Pythonic way to build MCP servers/clients easily. [1093]
  6. Installation: Install packages using uv -r requirement.txt. [1103]

Creating the Math Server (STDIO Transport) [1108]

  1. File Creation: Create math_server.py to define the first MCP server. [1109]
  2. Initialization: Import FastMCP and initialize: mcp = FastMCP(server_name="math"). [1110]
  3. Tool Definition (Add):
    1. Define function add(a: int, b: int). [1114]
    2. Doc string: "Add two numbers." [1116]
    3. Returns a + b. [1117]
  4. Tool Definition (Multiply):
    1. Define function multiply(a: int, b: int). [1118]
    2. Doc string: "multiply two numbers." [1120]
    3. Returns a * b. [1121]
  5. Running the Server: Use mcp.run() within the if __name__ == "__main__": block. [1125]
    1. Transport Protocol: Set transport=stdio. [1127]
  6. STDIO Transport Explanation: [1129]
    1. STDIO tells the server to use standard input/output for communication. [1134]
    2. This is useful for local testing where the client reads output directly from the command line. [1137]

Creating the Weather Server (Streamable HTTP Transport) [1142]

  1. File Creation: Create weather.py for the second server. [1142]
  2. Initialization: Initialize FastMCP with server name "weather". [1143]
  3. Tool Definition (Get Weather):
    1. Define function get_weather(location: str). [1149]
    2. Doc string: "Get the weather location." [1151]
    3. Placeholder Return: Returns constant string: "It's always raining in California." [1155]
  4. Running the Server: Use mcp.run() with transport=streamable_http. [1163]
  5. Streamable HTTP Transport Explanation: [1166]
    1. This transport runs the server as an API service. [1176]
    2. It runs by default on localhost:8000/mcp. [1175]
    3. Contrast: Running math_server.py with STDIO does nothing visible in the terminal until input is provided via stdin. [1179]

Writing the Multi-Server Client (Client.py) [1184]

  1. File Creation: Create client.py to interact with both servers. [1185]
  2. Client Imports: Import necessary libraries: langchain_mcp_adapters.client, langchain.prebuilt.create_react_agent, ChatGroq, load_dotenv, and asyncio. [1191]
  3. Environment Setup: Load Groq API key from .env file. [1235]
  4. Client Creation: Create a multi-server MCP client. [1213]
  5. Tool Retrieval: Get tools from both servers: tools = await client.get_tools(). [1238]
  6. Model Initialization: Initialize ChatGroq model (e.g., using model name Qwen:32b). [1240]
  7. Agent Creation: Create a React Agent using the model and retrieved tools. [1241]
  8. Math Test Execution:
    1. Invoke agent with message: "What is 3 + 5 * 2?" [1250]
    2. Execution: The agent uses the math server (STDIO transport). [1261]
    3. Result: Math response is 96 (calculated as (3+5)*2 = 16, error in original calculation shown as 96). [1267]
  9. Weather Test Execution:
    1. Invoke agent with message: "What is the weather in California?" [1275]
    2. Result: The agent calls the weather tool, returning the hardcoded response: "It's always raining in California." [1279]
    3. Transport: This server runs via Streamable HTTP. [1293]

Summary of MCP Client Implementation [1299]

  1. Client Action: The client communicated with two MCP servers. [1299]
  2. Math Server: Communicated using STDIO transport protocol. [1300]
  3. Weather Server: Communicated using HTTP protocol transport (streamable_http). [1300]
  4. Integration: All was set up using the LangChain Adapter library. [1301]