How to use Unknown to build a travel planning system
The author reports a working flight, hotel, and itinerary prototype, approximately 25% fewer repeated tool executions, and configuration prepared for Cloud Run deployment.
dev.toPrompt to try
Editorial adaptation, not the source author’s exact prompt. Replace bracketed inputs and review tool permissions first.
Build a travel-search prototype for [destination and dates] using separate flight, hotel, and planner agents. Run searches in parallel, require structured tool outputs, aggregate deterministically, retain [user preferences] in session memory, and log and evaluate itinerary generation.
Reach people exploring AI agents
See placements →What happened
The author reports a working flight, hotel, and itinerary prototype, approximately 25% fewer repeated tool executions, and configuration prepared for Cloud Run deployment.
Reported by hosnaakter on dev.toHow the agent did it
- Design flight, hotel, and planner agents.
- Run flight and hotel searches in parallel.
- Fix aggregation with structured outputs and deterministic merging.
Where a person stepped in
The author debugged race conditions and added logs, metrics, and evaluation scores; the text does not describe traveler review or booking approval.
A person approved each step before the agent continued.
The author built a travel multi-agent capstone during the Google five-day agents intensive. The working prototype fetches flights, finds hotels, and produces itineraries. Its core architecture has a Flight Agent, Hotel Agent, and Planner Agent, with flight and hotel searches running in parallel.
The first parallel attempt returned valid search results but merged them inconsistently because of race conditions. The author corrected this with strict structured outputs and deterministic aggregation in the planner. Custom FlightTool and HotelTool interfaces then standardized results for independent tool use.
An in-memory session service retained preferences, earlier searches, and planner state. A lightweight session identifier detected unchanged intent so cached decisions could be reused instead of repeating tool calls. The author reports approximately 25% fewer repeated executions.
For inspection, the project added action logging, search-result metrics, and agent evaluation scores. Finally, the author modularized the agents, exposed FastAPI endpoints, containerized the system with Docker, and prepared configuration for Google Cloud Run. The supplied text describes deployment preparation rather than a completed cloud deployment. Who it's for: developers learning multi-agent orchestration who want a travel-search prototype with explicit aggregation, memory, and evaluation.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: dev.to · hosnaakter
Frequently asked questions
Did the system book travel?
The supplied account describes fetching flights, finding hotels, and generating itineraries. It does not report purchases or completed bookings.
How did the author fix inconsistent itineraries?
The author enforced strict structured outputs and added deterministic aggregation in the Planner Agent to resolve race conditions.
More details
Remaining steps
- Implement session storage and reuse cached decisions.
- Add logging and evaluations, then containerize the system.
About this account
The flight and hotel agents invoke tools independently, while the planner aggregates results and generates the itinerary.
Platform: dev.to. Attribution: https://dev.to/hosnaakter/my-learning-journey-google-5-day-ai-agents-intensive-travel-multi-agent-system-4d4h. Prompt: Suggested (written by Agents In Use, not the author's). Sourced by the Agents In Use pipeline.
Credit: hosnaakter on dev.to
Source published 14 Dec 2025
Source checked 14 Oct 2026
Tools and topics
Python · FlightTool · HotelTool · FastAPI · Docker
Travel planning · Multi-agent · Session memory
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.