Naive Multi-Agent Travel Planner
In development
Designing supervisor orchestration, shared state, and tool-based itinerary planning
An in-progress, backend-focused learning project exploring a Gemini supervisor, specialized travel agents, shared state, runtime context, and external travel tools. This page describes the current design direction.
Planned stack
- Python
- LangChain
- LangGraph
- Google Gemini
- FastAPI
- Google Maps API
- Kiwi MCP
- Pydantic
The workflow
From trip request to travel plan.
Proposed workflow: from structured travel requirements to specialist research and a final itinerary.
- 01
Request
Trip requirements
Plan to accept the origin, destination, dates, traveler count, accommodation preferences, and trip preferences.
- 02
Coordinate
Gemini Supervisor
The supervisor would review the planning state and delegate one specialist task at a time.
- 03
Research
Specialist agents · External tools
Plan to explore Kiwi MCP for flights, Google Places for accommodation and places, and route information for itinerary planning.
- 04
Deliver
Shared state
The intended output is a flight summary, accommodation summary, and itinerary assembled from shared planning state.
01 / Intent
Build the coordination loop.
Explore how a supervisor could coordinate specialized agents across a travel-planning workflow, with a clear responsibility for each component.
The goal is to connect a structured trip request with flight research, accommodation research, itinerary generation, and a validated final response.
The focus is learning supervisor orchestration, delegation, shared application state, runtime context, and external tool integration. Implementation is still in progress.
02 / Proposed design
The coordination design.
I am considering LangChain, LangGraph, and Google Gemini for a supervisor that would coordinate a Flight Agent, an Accommodation Agent, and an Itinerary Agent.
The supervisor is intended to delegate one specialist task per model turn. Flight and accommodation research could run in either order, with itinerary generation waiting for both summaries.
A shared TravelState is planned for mutable outputs, agent messages, and attempt counters. Each request would start a fresh planning state.
A separate TravelContext would carry the original trip request and per-request dependencies, such as configuration, request ID, HTTP client, and Gemini client. Agents would receive the context without automatically sharing their full conversation histories.
I plan to explore ToolRuntime for access to state and context, with specialist results returned through Command(update=...). Sequential updates would let the supervisor review each result before deciding what to do next.
Planned middleware would supply trip requirements to prompts, control available delegation tools, enforce one delegation per supervisor turn, and record tool execution without full provider payloads or credentials.
I am considering Kiwi MCP for flight research, Google Places for accommodation and place discovery, and Google Routes for route estimates. I plan to explore FastAPI and a CLI as entry points to the same core workflow.
03 / Planned scope
A project in development.
The planned scope is a learning implementation for researching and summarizing travel options. Flight booking, hotel reservations, and payments are outside this scope.
The current design calls for per-request state and context, without a checkpointer, persistent conversation history, or cross-request long-term memory.
Accommodation discovery is intended to provide research candidates, without claiming confirmed room prices, capacity, or date-specific availability. Route estimates would not guarantee travel times or represent live traffic or public-transit availability.
Current boundary
Development is ongoing. The workflow and integrations described here are design goals and may change as the project evolves. The source code is not public yet. Code cleanup is in progress, and it will be uploaded to GitHub soon.
The intended coordination policy keeps delegation sequential and rebuilds an itinerary when newer flight or accommodation research changes the planning state.
Provider configuration, tool integration, and end-to-end validation remain part of the development work. A clearly labeled stub mode is part of the development plan.