Capstone: Travel Multi-Agent System
Introduction
The Google 5-Day AI Agents Intensive marked a pivotal moment in my AI journey. Before this program, my experience with Large Language Models (LLMs) was mostly limited to prompts and small experiments. I had never designed:
- a full multi-agent architecture,
- agent-to-agent orchestration,
- custom tools,
- session and memory systems,
- evaluation pipelines, or
- a deployment-ready agent workflow.
When the course began, I felt a mix of excitement and uncertainty. Could I really build a fully functioning travel automation system in just five days?
By the end, I had not only built a working Travel Multi-Agent System that fetches flights, finds hotels, and produces complete itineraries automatically—but also transformed how I think about AI.
This journey documents what I learned each day, how I applied it directly to my project, and how my mindset evolved from an LLM user into an agent system designer.
My Starting Point
Before the course:
- Comfortable with Python
- Able to use LLMs for basic tasks
-
But I didn’t know how to:
- let agents call tools
- coordinate multiple agents
- manage shared state and memory
- evaluate agent behavior
- think about deployment and observability
I entered the program as an LLM user—but left as someone capable of engineering complex, production-oriented agent systems.
Day 1 – Introduction to Agents
What I Learned
- Difference between a chatbot and an autonomous agent
- Single-agent vs. multi-agent architectures
- Sequential vs. parallel orchestration
- Importance of structured agent communication
This was my first realization that agent development is system design, not prompt engineering alone.
How I Applied It
-
Designed three core agents:
- Flight Agent – responsible for flight search
- Hotel Agent – responsible for hotel search
- Planner Agent – orchestrates agents and synthesizes the final itinerary
Implemented parallel execution between Flight and Hotel agents
Breakthrough: The first successful parallel run where multiple agents coordinated without conflict—producing a coherent itinerary.
Failure Moment
My first attempt at parallel orchestration failed in a subtle way. Both the Flight Agent and Hotel Agent returned valid outputs, but the Planner Agent merged them inconsistently due to race conditions.
The system looked like it worked, but the itinerary order changed unpredictably across runs.
I resolved this by enforcing strict structured outputs and adding a deterministic aggregation step in the Planner Agent. This failure taught me that concurrency without control can silently degrade system reliability—a lesson I will carry into every future agent system I build.
Day 2 – Tools & Model Context Protocol (MCP)
What I Learned
- How agents interact with the outside world using tools
- Designing custom tools with structured outputs
- MCP concepts for interoperability and standardized context exchange
- Managing long-running tool executions
How I Applied It
-
Built two custom tools:
FlightToolHotelTool
Enabled agents to invoke tools independently and in parallel
Standardized tool outputs for safe aggregation by the Planner Agent
{
"flights": ["Flight A to Berlin", "Flight B to Berlin"],
"hotels": ["Hotel X", "Hotel Y"],
"summary": "Results aggregated successfully."
}
Outcome: Improved modularity, faster execution, and clear separation of responsibilities.
Day 3 – Context Engineering: Sessions & Memory
What I Learned
- Session-based memory for multi-turn interactions
- Short-term vs. long-term memory trade-offs
- Context compaction strategies to reduce token usage
How I Applied It
-
Implemented an In-Memory Session Service to store:
- User preferences
- Previous searches
- Planner decision state
Micro Technical Detail
To manage session memory efficiently, I introduced a lightweight session identifier that allowed the Planner Agent to detect unchanged user intent.
When the intent remained stable, the system reused cached agent decisions instead of re-triggering expensive tool calls—reducing unnecessary executions while preserving correctness.
Impact:
- ~25% reduction in repeated tool executions
- Consistent and coherent conversations across turns
Reflection: Memory made the system feel less reactive and more intelligent.
Day 4 – Agent Quality: Observability & Evaluation
What I Learned
- Importance of observability in agent systems
- Using logs, traces, and metrics to debug agent behavior
- LLM-as-a-judge evaluation techniques
- Scoring outputs instead of relying on intuition
How I Applied It
- Added step-by-step logging for each agent action
- Tracked metrics such as number of flights and hotels found
- Implemented evaluation scores per agent
| Agent | Task | Score |
|---|---|---|
| Flight | Flight search | 20/20 |
| Hotel | Hotel search | 20/20 |
| Planner | Itinerary creation | 30/30 |
Outcome: A measurable, inspectable system with clear quality signals.
Day 5 – Prototype to Production
What I Learned
- Thinking in terms of production readiness
- Designing scalable agent architectures
- Agent-to-Agent (A2A) communication patterns
- Cloud-native deployment principles
How I Applied It
- Modularized agents for independent scalability
- Exposed functionality via FastAPI REST endpoints
- Containerized the system using Docker
- Prepared configuration for Google Cloud Run deployment
Reflection: Designing for production from day one fundamentally changed how I build AI systems.
Architecture Overview
User → Planner Agent → (Flight Agent + Hotel Agent) → Final Itinerary
Key Capabilities
- Parallel agent orchestration
- Custom tool-based execution
- Session memory with context compaction
- Observability and evaluation pipelines
- Deployment-ready, cloud-native architecture
Final Project Summary & Metrics
The Travel Multi-Agent System demonstrates:
- Sequential + parallel multi-agent orchestration
- Custom tool integration for real-world actions
- Session-based memory reducing redundancy (~25%)
- Quantitative evaluation for agent reliability
- Docker + FastAPI + Cloud Run–ready architecture
System Impact:
- 100% conversation coherence
- ~50% faster response time through parallel execution
- Modular design suitable for enterprise scaling
Explore the Project:
You can explore the full project and code here:
https://kaggle.com/competitions/agents-intensive-capstone-project/writeups/travel-multi-agent-enterprise-agent-for-flights
Project Demo Video:
Watch a demonstration of my Travel Multi-Agent System project here: YouTube Video — built during the Google 5-Day AI Agents Intensive Course (Kaggle project).
Personal Reflection & Key Breakthroughs
- First successful parallel orchestration ✅
- Debugging async failures strengthened my system design skills
- Memory eliminating repeated searches
- Evaluation metrics increased trust in outputs
- Production-ready architecture felt professional
By the end, I wasn’t just building agents—I was thinking like a systems engineer.
Future Plans
- Integrate real travel APIs (Amadeus, Skyscanner, Booking.com)
- Add a pricing optimization agent
- Deploy publicly using Cloud Run + Agent Engine
- Introduce long-term user personalization
- Expand to multi-city travel planning
- Build a web/mobile interface
Conclusion
The Google 5-Day AI Agents Intensive redefined my approach to AI.
I moved from writing prompts to designing scalable, observable, production-ready agent systems.
Why this matters beyond me :
As AI systems evolve from single-prompt tools to autonomous workflows, the ability to design reliable, observable, multi-agent architectures will become a core engineering skill.
This journey reflects not just personal growth, but the kind of system-level thinking required to build AI that can scale responsibly in real-world environments.
Top comments (0)