--- name: otto-travel-trip-itinerary-booking description: Plan and book flights and hotels for a trip end to end with Otto Travel, from search through confirmation, asking for explicit approval before any booking is made and checking each option against the traveller's preferences and loyalty programmes. Use when the user asks to book a trip, find flights or hotels for a dates and destination, build an itinerary, or compare travel options with Otto. --- # Plan and book a trip with Otto Travel The job is to turn a trip brief into confirmed bookings that match what the traveller actually wants, without spending their money on a guess. Searching is free and reversible. Booking moves money and creates a commitment. Keep those two phases separate, and stop between them. ## 1. Pin down the brief before searching Do not search until you have, or have confirmed with the user: - **Traveller(s)** and which one this trip is for, if there is more than one. - **Origin, destination and dates**, including flexibility ("exact dates" versus "plus or minus two days"). - **Trip shape:** one way, return, or multi-city; whether the hotel is needed; any fixed event that constrains arrival or departure. - **Hard limits:** budget ceiling, cabin class, maximum stops, check-in and check-out needs, accessibility. Then read the traveller's saved preferences with `read_preferences` and their loyalty memberships with `read_loyalty_programs`. Treat these as defaults, but say so when a preference conflicts with the brief (for example, a saved preference for aisle seats against a request for a window). The user decides which wins. If the brief is missing a hard limit that would change which options are valid, ask one short question rather than guessing. ## 2. Search flights first, then hotels against the chosen arrival Start with `search_flights`. Narrow the results before presenting them: discard options that break a hard limit, then rank the rest by the trip's real priority (usually total time door to door, then price, then loyalty value). Use `query_flights` only to re-check or refine a specific search you have already run, not as a second search. Hotels follow the flights. Set the hotel dates from the actual arrival and departure times, not the calendar date: a 01:30 arrival needs a check-in that covers that night. Use `search_hotels`, then `get_hotel_rooms` for the two or three most promising properties to see what the rate actually includes (cancellation terms, breakfast, room type). A cheap headline rate with no free cancellation is often the wrong choice for an unsure traveller. Present options in small batches (three to five per category). Show enough to decide: times, stops, total price, cancellation terms, loyalty earn. Do not dump raw result lists. ## 3. Check each shortlisted option against loyalty and preferences For the shortlist, check: - **Loyalty fit:** does the traveller hold a programme with this carrier or hotel group? Is there a status benefit worth more than a small price difference? Say the trade-off in numbers the search results support, and do not invent points values. - **Preference fit:** seat, meal, room, floor, bed type, and any "never" items in the saved preferences. - **Connection risk:** a short connection on separate tickets is not protected if the first flight is late. Flag any connection under the traveller's comfort level and any itinerary that spans separate bookings. Mark each shortlisted option as matching, partly matching, or conflicting with the saved preferences, and say which. ## 4. Get explicit approval, then book Before any `book_flight` or `book_hotel` call, present a single complete summary: every item, its total cost and currency, the cancellation terms, the traveller name as it must appear on the ticket, and the loyalty number that will be attached. Then ask for approval and **wait for the user's explicit yes** for this specific set of items. A yes to "find me options" is not approval to book. A yes to one flight is not approval for the hotel. Book one item at a time. After each call, check the returned status before moving on. If a booking call fails or returns an unclear result, do not retry it blind: check `get_bookings` and `task_status` first to see whether something was actually created, then tell the user what you found before any retry. A retry on an unknown result can create a duplicate charge. ## 5. Verify the result against the plan When all bookings are placed, pull `get_bookings` and compare each confirmed item with the approved summary: names, dates, times, airports, room type, price, and loyalty attachment. Anything that differs is a finding to report at once, not something to smooth over. Give the user the confirmation references and the itinerary in date order. ## Common patterns and traps - **Booking the cheapest flight, then discovering the hotel check-in is after arrival.** Always fix the arrival time before choosing the hotel dates. - **Name mismatches.** A traveller name that differs from the passport or ID is a common reason for a refused check-in. Confirm the exact legal spelling before booking, and check it in the confirmation. - **Loyalty not attached.** If the number is not on the booking, the points or status are lost. Verify it in the booking record, not just in the summary. - **Connections on separate tickets.** No single airline covers a missed connection on another airline's ticket. Flag it rather than presenting it as one trip. - **Partial results.** A search that returns few or no options may be limited by dates, not by availability. Widen the dates by a day or two and say that you did so. - **Stale preferences.** Saved preferences may be out of date. If one conflicts with an explicit request in this conversation, the request wins for this trip only, and offer to update the saved preference. - **Price changes between search and booking.** The price shown at approval may differ at booking. If the booking returns a different price, stop and tell the user before continuing. ## Output ``` Brief: Shortlist: - | | | | | Recommended: