Video summary
Build an End-to-End Multi-Agent AI System with LangGraph, MCP, Supervisor, Guardrails Safety & HITL
Main summary
Key takeaways
Overview
This video walks through building an end-to-end LangGraph multi-agent AI travel planner that evolves across three “parts”:
- Multi-agent travel planner (no MCP)
- Add Model Context Protocol (MCP)
- Add Guardrails + Supervisor Agents + HITL
Part 1: Multi-agent travel planner (no MCP)
LangGraph workflow + shared state
- Builds a LangGraph-based workflow with a shared state containing:
user queryflight resultshotel resultsitinerary resultsfinal response- plus tracking like LLM call counts
- Implements persistence by storing checkpoints / conversation state in PostgreSQL using a LangGraph Checkpointer (viewed via pgAdmin).
Specialized agents (wired in a sequential-ish graph)
Four specialized agents are implemented:
-
Flight agent
- Fetches realtime flight data using the AviationStack API.
-
Hotel agent
- Uses the Tavily Search API (with an optional mention of Google Places).
-
Itinerary planning agent
- Uses an LLM (Llama 3 via Groq) to generate a day-by-day itinerary.
-
Final response agent
- Uses an LLM to format a complete travel plan including:
- summary
- flights
- hotels
- itinerary
- budget
- recommendations
- Uses an LLM to format a complete travel plan including:
Tooling & backend setup
- Shows implementation tooling and backend setup:
- FastAPI backend
- HTML/CSS/JS frontend
- API routes include something like:
/travel/health
Testing, observability, and deployment preparation
- Verification includes:
- Checkpoints appear in PostgreSQL
- Execution traced in LangSmith
- Deployment prep includes:
- Dockerfile
- Render Postgres setup
- Render web service with environment variables
- final deployment steps
Part 2: Add Model Context Protocol (MCP)
Goal: replace custom tool functions with MCP
The key goal is to replace custom tool functions with MCP servers so integrations are more maintainable and robust.
MCP is framed as a “universal USB port” for tools. Instead of hardcoding API calls in app/tool code, the agent uses an MCP client that connects to MCP servers exposing tools.
If upstream APIs change versions, MCP servers can “heal” the updates without changing the agent logic.
MCP concepts and wiring
- MCP client inside the agent app connects to one or more MCP servers.
- MCP servers can be:
- remote
- local
- custom
- Uses JSON-RPC messaging (mentioned) and transport types:
- stdio for local MCP
- streamable HTTP for remote MCP
Tavily via remote MCP (hotel agent upgrade)
- Connects to a Tavily MCP server (remote).
- The agent:
- lists tools exposed by the MCP server
- invokes the needed tool (e.g., “tavily search”)
- Updates the hotel agent to use MCP tool invocation rather than a custom Tavily function.
AviationStack via local MCP (flight agent upgrade)
- Uses an existing community MCP server for AviationStack running locally.
- Connects via stdio transport.
- Updates the flight agent to:
- pull tools like “list airports” and “list airlines”
- feed tool outputs into the LLM to generate more detailed flight guidance, such as:
- likely departure/arrival airports
- airline
- duration
- estimated fare/budget
- booking tips
Async/event loop fix
- Mentions resolving nested asyncio/event loop issues using nest_asyncio because MCP uses async and FastAPI already runs an event loop.
Part 3: Add Guardrails + Supervisor Agents + HITL
This part is positioned as an advanced robustness and safety upgrade.
1) Input guardrails (safety + relevance)
- On every user request:
- A model-based guardrails step runs first
- An LLM-based classifier checks whether the request is:
- relevant to travel planning
- safe (blocks harmful/illegal instructions like weapon-building or hacking)
- If blocked:
- returns a message stating it can’t help with that kind of request
- Enforces structured JSON-only outputs using:
- prompt constraints
- a helper that extracts JSON
2) Supervisor agent (dynamic tool/agent selection for cost optimization)
- Instead of always running all agents:
- the supervisor decides which specialized agents to run based on user intent.
- Example behavior:
- If the prompt is about hotels only, it won’t run flights/weather/budget unnecessarily.
- If the prompt is “full trip,” it may select flight + hotel + weather + budget + itinerary.
- Supervisor outputs:
selected agents(ordered)trip constraint(extracted entities like origin, destination, duration, budget, preferences)supervisor reasoning(explains why agents were chosen)
3) Human-in-the-Loop (HITL) for itinerary approval
- The itinerary agent generates a draft.
- Before finalizing:
- execution interrupts for human review/approval using a LangGraph interrupt/resume pattern.
- UI adds controls:
- approve draft → continue to final response
- reject / request changes → store feedback and regenerate/update the draft
- Adds UI support for interruption/resume and feedback.
4) New specialized agent: Budget agent
- Creates budget analysis from:
- flight results
- hotel results
- weather
- extracted constraints
- Outputs:
- estimated trip cost categories
- budget realism
- risks
- money-saving suggestions
- Budget output is included into itinerary planning and the final report.
Graph restructuring in Part 3
Graph nodes expand to include:
input guardrails/supervisor- a
guards blockearly-exit path - specialized agents: flight, hotel, weather, budget, itinerary
human approvalnode- final response node
A routing utility (based on supervisor-selected agents) runs only the needed subset in the correct order.
Tech components & product features highlighted
Orchestration & state
- LangGraph orchestration with:
- shared state + reducers (e.g., append message history)
- persistent checkpoints in Postgres
MCP integration
- remote MCP (Tavily)
- local MCP (AviationStack)
- also mentions custom MCP servers
LLM provider
- Groq + Llama 3 (noted as free-tier use with limitations)
Safety & governance
- model-based guardrails with JSON-only decision outputs
- blocks harmful/illegal instructions
Quality control
- HITL approval loop for draft itineraries
Observability
- LangSmith tracing per trade/execution
Deployment
- Docker + Render web service + Render Postgres
- environment variables for API keys and DB URLs
Main speakers / sources
Speaker
- BPI (the YouTube creator; stated at the start: “my name is BPI”)
Primary external sources/tools mentioned/used
- LangGraph / LangChain ecosystem
- MCP (Model Context Protocol)
- MCP servers for Tavily and AviationStack (remote/local)
- Groq (Llama 3 models)
- Tavily search
- AviationStack flight API
- OpenWeather (for a custom MCP weather server concept)
- PostgreSQL / Render / pgAdmin
- LangSmith tracing
- FastAPI (frontend/backend)
Rate this summary
Your feedback will help improve summaries.
Improve this summary
Reprocess with a stronger model when the summary feels incomplete or inaccurate.
Translate summary in another language
Ask questions to this video
Chat for follow-up questions, clarifications, and source-backed answers.