Planning a trip means juggling dozens of tabs: flights, stays, opening hours, transit, visas, weather and budget. An LLM agent with search and map tools turns a loose wish ("five days in Portugal in May, two adults, rail, no car") into a realistic day-by-day plan, explains trade-offs and adapts it when things change. Typical benefit: hours of research saved and fewer logistics mistakes; the traveller still decides and pays.
Problem & value
- Today: people combine review sites, forums, blogs, map apps and spreadsheets. Plans break on closed days, long transfers, missed connections or hidden fees. Group trips add coordination overhead.
- AI value: (1) fast inspiration and shortlisting, (2) geographically coherent day plans (clustering sights, ordering stops), (3) one place that merges bookings from email into a timeline, (4) on-trip help: translation, re-routing, rainy-day alternatives.
- Evidence status: vendors report rapid uptake of AI in trip planning, but no neutral, widely accepted benefit figure exists; measure time saved yourself (see KPIs).
Variants
- Leisure city or road trip: sights, restaurants, driving or transit legs.
- Family and group trips: child-friendly filters, shared voting on options, split costs.
- Accessibility-aware travel: step-free routes, quiet hours, dietary needs (see PERS-007).
- Business travel (employee view): policy-compliant booking inside a corporate tool; see CONV-012 for the provider-side concierge.
- Trip companion on the road: live translation, document scanning, disruption handling.
How it works
- wishes + constraints (dates, budget, group, interests)
- clarifying questions
- candidate generation (LLM + live search / travel APIs)
- grounding (opening hours, distances, transit times, prices from tools)
- itinerary optimisation (clustering, ordering, time windows)
- draft plan + alternatives + budget
- human review and edits
- booking handoff (links, or agent fills the form; traveller pays)
- trip timeline from confirmation emails; live re-planning
- Grounding is the key step. A plain LLM invents opening hours, prices and even venues. Good assistants call tools (maps, places, flight and hotel search, weather, rail timetables) and cite the result.
- Route optimisation: the LLM proposes stops; a small solver (e.g. OR-Tools, or the routing APIs of map providers) orders them and checks travel times.
- Human-in-the-loop: the traveller approves the plan and always confirms payment and personal data entry.
Data preparation
Little preparation is needed because the main input is free text and public data. Useful private data lives in e-mail (booking confirmations), calendar entries, screenshots of tickets, saved map places and notes from earlier trips. Typical gaps are confirmations scattered over several mailboxes, outdated opening hours, missing mobility or dietary needs, and tickets as photos only. Preparation steps: forward booking mails to one folder or a trip document, write down a short preference profile (budget, pace, interests, group, mobility), save candidate places in one map list, and let OCR or a vision model extract dates and booking numbers from screenshots. For a developer product, use maps, opening-hours and transit APIs as sources instead of model memory, and cache them. Check every time-critical fact (hours, prices, visa rules) against the official source. Effort is low, about 10-20 percent of the total. Related preparation topics are PREP-007 for mail archives, PREP-006 for paper tickets and DOC-014 for extracting data from documents.
Implementation paths
Which path for whom
- Private: A - general assistants and travel apps already plan trips well, and no sensitive business data is involved.
- Developer: B - cloud model APIs combined with maps, transit and booking APIs give the best result; a self-hosted model rarely has current opening hours or prices.
Path A — Buy (recommended for private users)
- General assistants: ChatGPT, Claude, Gemini, Microsoft Copilot and Perplexity all plan trips with web search; Google offers trip planning in Search/Maps and Gemini with Google Flights and Hotels data, Apple and Google Maps add AI-assisted lists.
- Travel-specific apps: Tripadvisor, Booking.com, Expedia, Kayak and Airbnb have embedded AI planners; Wanderlog, Mindtrip and Layla are dedicated planners; TripIt organises confirmations from email. European players include Booking.com (NL), Trivago (DE), GetYourGuide (DE), Omio (DE), Komoot (DE, outdoor routes) and Wanderlog-like tools; check each one's data policy.
- Choose A when: you want results today, bookings go through the usual portals, and sharing travel details with a US or EU provider is acceptable.
Path B — Build on cloud APIs
- Models: any frontier LLM with tool use (Claude, Gemini, GPT, Mistral as EU provider) with EU data residency where offered.
- Data/tools: Google Maps Platform (Places, Routes), Amadeus Self-Service or Duffel APIs for flights, Open-Meteo for weather, Navitia/transport.rest or national rail APIs for transit, OpenStreetMap/Overpass for POIs. Tools are commonly exposed through MCP servers.
- Orchestration: an agent loop (LangGraph, OpenAI Agents SDK, Claude Agent SDK) or n8n; output as a shared Google Doc, Notion page or .ics calendar file.
- Choose B when: you want a family or club planner with your own preferences, or a niche service (cycling, accessible travel).
Path C — Self-host (open source)
- Models: open-weight LLMs with tool calling such as Qwen3, Llama, Mistral Small or gpt-oss via Ollama or vLLM; Whisper for voice notes; NLLB or Opus-MT for translation.
- Tools: self-hosted OpenStreetMap stack (Nominatim, OSRM/Valhalla/GraphHopper, Overpass), OR-Tools, SearXNG for web search, Open-Meteo.
- Hardware: HW1 for small models on a laptop; HW2 for comfortable tool-using 20-30B models. See PERS-005.
- Trade-off: full privacy, but no live prices or booking data without external APIs.
Path D — Custom training
Not worthwhile for individuals. Providers fine-tune ranking and recommender models on click and booking data; this needs large interaction logs.
State of the art (2026)
- Agentic booking: assistants increasingly operate browsers or partner APIs to search, fill forms and hold bookings, with the user confirming the final purchase. Reliability is uneven; expect fallbacks to links.
- Chat-embedded travel apps: major travel platforms publish integrations for chat assistants via tool protocols such as MCP, so plans link to real inventory.
- Reasoning models handle multi-constraint plans (budget, time windows, connections) much better than 2023-era chatbots, yet still fail on long dependency chains.
- Limits and failure modes: hallucinated venues or closed attractions, stale prices, wrong transit transfers, underestimated transfer or queue times, over-packed days, visa and entry rules out of date (check official sources), and sponsored results presented as neutral advice. Always verify opening days, entry requirements and cancellation terms at the source.
Shared resources & combinations
- Same stack (llm-general + agent-framework + search): PERS-011 shopping and deal agent, PERS-009 household organisation, AGENT-003 browser agent.
- Combines with: LANG-009 translation on the road, PERS-017 lifelogging (trip memories), PERS-006 photo library organisation, PERS-015 consumer-rights help for flight compensation or cancelled trips, PERS-001 budgeting.
- Provider-side counterpart: CONV-012 travel and hospitality concierge.
Effort, cost & KPIs
- Path A: minutes; free tiers or a subscription of the assistant.
- Path B: a weekend for a prototype; API costs per plan are usually small, flight/hotel APIs may require partner approval.
- Path C: a day to a few days for setup; hardware you may already own.
- KPIs: planning time saved, share of suggestions verified correct, number of plan changes needed on the trip, budget deviation, traveller satisfaction.
People & change
Private travellers should involve the whole travel group early, since preferences, budget and mobility needs differ. Share only the data the assistant needs: passport numbers and payment data do not belong in prompts. Developers or businesses building a planner need the DPO because itineraries, locations and companions are personal data; an AVV (Art. 28 GDPR) is required with every cloud processor, and a DPIA is normally not needed unless location tracking at scale is added. No works council is involved for private use; if a company offers a travel assistant for business travel and the system logs employee trips, §87(1) no. 6 BetrVG may apply. AI literacy: Art. 4 AI Act asks organisations to support staff literacy; users should know that assistants can invent opening hours or connections. Typical concerns are wrong bookings and hidden costs; address them by making the assistant propose and the person book, and by checking critical facts at the source. Start with one short trip as a pilot and compare the plan with reality. Humans remain in control of all payments and bookings. See GUIDE-005, GUIDE-006 and GUIDE-009.
Risks, regulation & compliance
- EU AI Act: minimal risk for a personal planning assistant; transparency duties (Art. 50) apply to providers of chatbots. No Art. 5 issue unless a product adds emotion inference or manipulative nudging.
- GDPR: trips reveal location, dates, companions, health or religious needs and passport data. Prefer EU processing, do not paste passport scans into general chat tools, and delete chat history after the trip. Sharing co-travellers' data with a provider needs their consent.
- Consumer law: the Package Travel Directive (EU) 2015/2302 gives strong protection only for packages and linked travel arrangements; self-assembled bookings via an AI usually fall outside it. Air passenger rights (Reg. 261/2004) still apply to flights.
- Risks: wrong information, unauthorised purchases by agents, prompt injection from web pages read by the agent, affiliate bias. Mitigations: confirmation before every payment, spending limits, virtual cards, source citations, read-only tool permissions.
Getting started
- Write a one-paragraph brief (dates, budget, group, must-haves, no-gos) and ask an assistant for two alternative itineraries with travel times.
- Ask it to cite sources for opening hours and prices, then verify five key facts yourself.
- Forward booking confirmations to a trip organiser or let the assistant build one timeline and calendar file.
- Prepare offline copies (maps, tickets) and a translation tool for the trip.
- After the trip note what was wrong and reuse the corrected preferences next time.
Sources
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Directive (EU) 2015/2302 on package travel — https://eur-lex.europa.eu/eli/dir/2015/2302/oj
- Regulation (EC) No 261/2004, air passenger rights — https://eur-lex.europa.eu/eli/reg/2004/261/oj
- Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Model Context Protocol specification — https://modelcontextprotocol.io
- Google OR-Tools routing — https://developers.google.com/optimization/routing
- Amadeus for Developers — https://developers.amadeus.com
- Open-Meteo API documentation — https://open-meteo.com/en/docs
- Valhalla routing engine — https://github.com/valhalla/valhalla