Multi-Turn Reasoning in AI Trip Planning

Single-turn AI is easy. You ask a question, you get an answer. The model does not need to remember anything or track evolving constraints.

Travel planning is not a single-turn problem. The average international trip requires coordinating 5 to 8 separate bookings. The conversation between a traveler and an AI agent spans 20 or more turns as dates shift, budgets get negotiated, new destinations get added, and preferences get refined. Maintaining coherence across all of those turns, without contradicting earlier commitments or losing context, is one of the hardest problems in applied AI.

I want to walk through why multi-turn reasoning is difficult, how we handle it at Nowah, and where the frontier models still struggle.

Trip planning as multi-constraint optimization

When you plan a trip, you are solving a constraint satisfaction problem. The constraints include:

• Date ranges that must align with work schedules, school holidays, or events
• Budget ceilings that apply to the total trip, not individual components
• Preferences that interact with each other (you want a walkable neighborhood AND good restaurants AND under $200/night)
• Physical constraints like minimum connection times and maximum travel durations
• External dependencies like visa processing times and passport validity

These constraints do not arrive all at once. They emerge over the course of a conversation. Turn one: "I want to go to Italy in September." Turn five: "Actually, my partner can only get off work September 8-18." Turn nine: "We want to visit both Rome and Florence." Turn fourteen: "Can we keep the total under $4,000?"

The agent has to maintain a running constraint set that updates with every turn. It cannot treat each message as independent. Turn fourteen references a budget that applies to everything discussed in turns one through thirteen.

On traditional platforms, this kind of iterative planning takes 45 sessions spread over 30 days. Each session is disconnected. You search flights on one site, hotels on another, check dates against your calendar, text your partner, come back tomorrow and start over because you forgot the best option you found yesterday.

An AI agent compresses this into a single continuous conversation. But that compression demands something traditional platforms never needed: multi-turn reasoning with state.

The coherence challenge

Coherence means the agent's behavior in turn 20 is consistent with everything established in turns 1 through 19.

This sounds obvious. It is surprisingly hard. Here are the failure modes we have observed:

Constraint amnesia. The user set a budget of $4,000 in turn 5, but by turn 15 the agent recommends a hotel that would push the total to $5,200. It forgot the budget constraint while processing the most recent request.

Contradictory recommendations. In turn 8, the agent confirmed that direct flights were a priority. In turn 12, it recommends a connection-heavy itinerary because those flights are cheaper, without acknowledging the trade-off.

Reference confusion. The user says "the hotel you mentioned earlier." The agent retrieves the wrong hotel because there were two mentioned, one in turn 6 and one in turn 11.

Implicit constraint violation. The user said their partner joins on September 10. The agent books a hotel with a September 8 check-in for two guests, not realizing the first two nights should be a single room.

Each of these failures undermines trust. Users will tolerate an agent that takes a bit longer to find options. They will not tolerate an agent that forgets what they said.

Handling preference changes mid-conversation

Real conversations are not linear. People change their minds.

"Find me flights to Rome on September 8th." Three turns later: "Actually, push it to Wednesday the 10th." The agent needs to update the departure date in its working context, re-search flights, and carry forward all other constraints unchanged.

This is trickier than it appears because changes can cascade. Moving the departure date by two days might:

• Change which flights are available
• Shorten the Rome stay from 5 days to 3 days
• Make the Florence leg too short to justify the side trip
• Push the total cost up because the new date has higher fares

A good agent recognizes the cascade and surfaces it. "Shifting to Wednesday means you'd have 3 days in Rome instead of 5. The flight is also $80 more on that date. Want me to adjust the itinerary, or would you prefer to keep the original date and find another way to accommodate the schedule change?"

A naive agent just re-searches flights for the new date and ignores the downstream effects.

We handle this by maintaining a structured state object that tracks all active constraints, their interdependencies, and which turn established each one. When a constraint changes, the agent runs a dependency check to identify what else is affected and surfaces the trade-offs explicitly.

Working memory architecture

The agent's working memory during a conversation has several layers.

Conversation state is the raw message history. Every user message and agent response, including tool calls and results. With context windows exceeding 200,000 tokens, we can fit substantial conversation histories without truncation.

Active constraint set is a structured representation of everything the user has established. Dates, destinations, budget, traveler count, preferences. This is extracted from the conversation and maintained as structured data so the agent can query it efficiently.

Search context includes the results of recent tool calls. Flight options, hotel options, price data. This is ephemeral; it gets refreshed when the user changes parameters.

Long-term memory includes the user's persistent preferences and history, pulled from the agentic memory system. This provides context that the current conversation does not need to re-establish.

The interaction between these layers is where multi-turn reasoning happens. When the user says "cheaper," the agent checks the active constraint set for the current budget, checks search context for the current options and their prices, checks long-term memory for the user's historical price sensitivity, and determines how to proceed.

Multi-destination complexity

The constraint space grows non-linearly with destination count.

A single-destination round trip has a manageable constraint set: origin, destination, outbound date, return date, hotel dates, budget. Maybe 10-15 variables.

A three-city trip (Rome, Florence, Milan) multiplies this dramatically. Now you have three hotel stays, inter-city transport (train vs flight for each segment), time allocation per city, an open-jaw flight possibility, and constraints that span segments (total budget, total days, travel pace preference). The variable count jumps to 40-50, with complex interdependencies.

A five-city trip is combinatorial. The number of possible routings, time allocations, and transport combinations grows exponentially. Traditional search interfaces give up entirely at this point. Try booking a five-city trip with different transport modes between each city on any major OTA. You will be opening a dozen separate searches and tracking the constraints yourself.

This is where multi-turn AI trip planning is most valuable. The agent holds the full constraint set in working memory, reasons about trade-offs across segments, and presents integrated options rather than fragmented searches.

Comparison with human travel agents

Human travel agents handle multi-turn planning well. They take notes. They ask clarifying questions. They manage the constraint set in their heads (or on paper). They catch cascading changes.

Where AI agents currently match human agents:

• Constraint tracking across 20+ turns
• Preference recall from previous trips (with memory systems)
• Speed of searching and comparing options
• Availability 24/7 without scheduling conflicts

Where AI agents still lag:

• Detecting emotional subtext ("I guess that works" might mean the user is settling, not satisfied)
• Creative problem-solving for unusual requests
• Knowing when to push back on a bad plan ("you've only allocated one day in Paris, that's not enough")
• Handling truly novel situations that do not map to common patterns

We are closing these gaps, but I want to be honest about where they are. The best AI trip planning gets better every quarter. It is not yet equal to an excellent human travel agent in every dimension. It is better in some (speed, memory, availability) and worse in others (intuition, emotional intelligence).

Measuring multi-turn quality

Our north star metric for multi-turn reasoning is turns to completion: how many conversational turns does it take to go from initial intent to confirmed booking?

Fewer turns are better, to a point. An agent that books in 3 turns might be skipping important clarifications. An agent that takes 30 turns is probably asking redundant questions or failing to retain context.

We segment this metric by trip complexity:

• Simple round-trip: 4-6 turns is good
• Round-trip with hotel: 6-10 turns
• Multi-city: 12-20 turns
• Complex group trip: 15-25 turns

We also track context retention rate: when the user references something from an earlier turn, how often does the agent correctly resolve the reference? Our target is above 95%, and we are currently hitting it for references within the last 10 turns. Longer-range references (referencing turn 3 from turn 20) are harder, and we are at roughly 90%.

The tool calls compound across turns. Each complex query involves 3 to 7 tool calls. A 20-turn conversation might involve 40-80 total tool calls. The working memory has to track all of this while staying coherent.

Context windows of 200,000+ tokens make this feasible at the raw capacity level. The engineering challenge is not fitting the data. It is reasoning over it correctly. More context does not automatically mean better reasoning; it means more material for the model to potentially get confused by. Selective attention, knowing which parts of the conversation history matter for the current turn, is the real problem.

Error accumulation across turns

In a single-turn interaction, an error is localized. The model misunderstands one thing, and the impact is one bad response.

In a multi-turn conversation, errors accumulate. A misunderstood preference in turn 3 affects every subsequent recommendation. A wrong date recorded in turn 5 propagates through flight searches, hotel bookings, and activity scheduling.

We think about this as the "error cascade" problem. A 5% error rate per turn does not mean 5% of conversations have errors. It means 5% of turns have errors, and in a 20-turn conversation, the probability of at least one error is 1 - 0.95^20 = 64%. Most long conversations will contain at least one error.

The defense against error accumulation is not perfection per turn (that is impossible). It is error detection and correction. The agent needs to recognize when something does not fit: "You mentioned a $4,000 budget earlier, but the options I have found so far total $4,800. Should we adjust the hotel budget or look at different dates?"

We implement consistency checks that run periodically during long conversations. Every 5-7 turns, the agent reviews the active constraint set for internal consistency. Are the dates compatible with the requested trip length? Does the running total fit the budget? Do the hotel locations align with the activities? Catching inconsistencies early prevents them from compounding.

The state management challenge

Multi-turn reasoning requires the agent to maintain a structured representation of the conversation state. This is more than just keeping the message history.

The state includes:

Confirmed decisions. Things the user has explicitly agreed to. "Yes, book the morning flight to Rome." These are locked and should not be revisited unless the user asks.

Active constraints. Preferences and requirements that apply to all future decisions. "Total budget under $4,000." "Need to be back by the 18th." These persist until modified.

Pending searches. Searches that have been initiated but not yet acted on. "I found three hotels, which do you prefer?" The user has not decided yet.

Open questions. Things the agent needs to ask but has not yet. "I still need your passport number for the booking." These are tracked and asked at appropriate moments.

Contextual assumptions. Things the agent has inferred but not confirmed. "Based on your past trips, I am assuming you want a non-smoking room." These should be surfaced and confirmed at the right time.

Managing this state correctly across 20+ turns is the engineering core of multi-turn reasoning. Every turn potentially updates the state, and the update must be consistent with everything that came before.

The working memory architecture

The agent's working memory is more structured than a raw conversation history. It maintains several parallel data structures that are updated with each turn.

The constraint graph tracks all active constraints and their relationships. "Budget under $5,000" is a global constraint. "Hotel in Rome near the Colosseum" is a location constraint scoped to the Rome segment. "Need to arrive before 3 PM" is a time constraint on a specific flight leg. These constraints form a graph where changes to one node can propagate: increasing the Rome hotel budget means decreasing the available budget for Florence.

The decision log records every decision made during the conversation and whether it was confirmed or tentative. "User selected the direct flight to Rome" is a confirmed decision. "Agent suggested the Trastevere neighborhood for the hotel" is a tentative decision awaiting confirmation. The distinction matters because confirmed decisions are locked and tentative decisions can be overridden.

The search result cache stores the results of all tool calls during the conversation. When the user says "actually, go back to that second hotel you showed me," the agent retrieves it from the cache without making a new API call. This is essential for conversational efficiency and reduces latency on follow-up references.

The preference context combines long-term memory (the user always prefers boutique hotels) with session-specific preferences (this trip is an anniversary, so budget is less important). The preference context is injected into every tool call to ensure results are personalized.

These data structures are maintained in parallel and kept in sync. A change in one (the user increases the budget) triggers updates in others (the constraint graph relaxes, previously filtered results become available in the cache). The synchronization logic is complex but essential for coherent multi-turn behavior.

The comparison with traditional planning tools

Traditional trip planning tools handle multi-step coordination through a fundamentally different interaction model. You open multiple browser tabs. You search for flights in one tab, hotels in another, activities in a third. You manually cross-reference arrival times with hotel check-in policies. You keep a spreadsheet or notes app to track prices and running totals.

This manual coordination is error-prone. People forget to check whether the hotel allows early check-in before the 3 PM standard. They do not realize that the cheapest flight arrives at midnight, meaning they need an extra hotel night. They lose track of total spending across separate bookings on separate platforms.

A multi-turn AI conversation handles all of this coordination automatically. The agent knows that booking a midnight flight affects the hotel check-in. It tracks the running total. It catches constraint violations before they become costly mistakes.

The average international trip requires coordinating 5 to 8 separate bookings. In a traditional workflow, each booking is an independent task with manual coordination between them. In a multi-turn conversation, all bookings are managed within a single coherent session where the agent handles the cross-references.

Practical impact: a real planning session

Let me walk through what a typical multi-turn planning session looks like.

Turn 1: "I want to plan a trip to Italy for my anniversary in September." State: destination Italy, occasion anniversary, month September.

Turn 3: "We want to see Rome and the Amalfi Coast." State: multi-destination, cities Rome and Amalfi Coast, 2 travelers.

Turn 6: "Maybe 10 days total. We don't need to rush." State: duration 10 days, pace relaxed.

Turn 9: "Can we keep it under $5,000 for everything?" State: total budget $5,000.

Turn 12: "Actually, my wife just said she wants to see Florence too." State: add Florence, reassess time allocation and budget per city.

Turn 15: "What if we take the train between cities?" State: inter-city transport preference train, search options.

Turn 18: "The hotel in Rome looks great but can we find something closer to the water in Amalfi?" State: Rome hotel confirmed, Amalfi hotel search modified.

Turn 21: "Let's book it." State: trigger booking flow for all components.

Twenty-one turns. Each turn adds, modifies, or confirms state. The agent has to maintain perfect coherence: the Florence addition in turn 12 affects the time allocation, which affects the hotel dates, which affects the budget distribution. The train preference in turn 15 affects inter-city logistics, which affects departure and arrival times, which affects hotel check-in and check-out.

A human travel agent would take notes and manage this naturally. An AI agent has to do it programmatically, which is harder in some ways (state tracking requires explicit engineering) and easier in others (the agent never loses its notes).

Why multi-turn matters more than single-turn quality

There is a tendency in AI evaluation to focus on single-turn quality: given one input, how good is the one output? For a travel agent, this metric captures maybe 20% of the actual user experience.

The other 80% is multi-turn coherence. Does the agent remember what you said 10 turns ago? Does it correctly propagate a constraint change across all affected bookings? Does it ask for missing information at the right time, not too early (before context is established) and not too late (after a decision depends on it)?

Users forgive a mediocre first response if the conversation improves. They do not forgive an agent that forgets their budget after they stated it clearly three turns ago. The first feels like an AI learning. The second feels like a broken tool.

This is why we weight multi-turn metrics more heavily than single-turn metrics in our evaluation framework. An agent that produces slightly less polished individual responses but maintains perfect coherence across 20 turns is a better product than one that generates beautiful individual responses but loses the thread.

We are still improving. Every failed multi-turn conversation teaches us something about where the reasoning breaks down. The trajectory is clear: multi-turn AI trip planning is already better than the 38-website alternative, and the gap widens with every model improvement. The day when a 5-city trip can be planned in a single conversation as naturally as ordering dinner is not far away.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.