Multi-Turn Conversations: When Users Change Their Mind
Real travel conversations are messy -- users backtrack, switch cities, and resume hours later. Here is how we engineered an agent that keeps up.
If you only test your AI agent with single-turn interactions, you're testing the easy part. "Find me flights to Tokyo" followed by three results is a solved problem. The hard problem is what comes after.
"Actually, make that Osaka instead." "Wait, what about Seoul? How much cheaper would that be?" "Let me think about it." Then silence for six hours. Then: "OK let's go with Tokyo after all. Can you show me hotels near Shinjuku?" Then: "My partner wants to come too. Can we add a second traveler?"
Real conversations are messy, branching, multi-day affairs where users change their minds, switch topics, provide information out of order, and expect the AI to keep up. Engineering for this is fundamentally different from engineering for question-answer pairs.
Single-turn accuracy is a vanity metric
Most AI benchmarks measure how well a model handles a single user input and produces a single response. This is useful but limited. In practice, our agent handles conversations that average a dozen turns and sometimes span fifty or more across multiple sessions.
The quality that matters isn't "did the agent answer this one question correctly?" It's "did the agent maintain coherent state across a twenty-turn conversation where the user changed cities twice, adjusted dates, added a traveler, and came back the next day?"
That's a different kind of accuracy. It's not about individual responses. It's about the trajectory of the entire conversation toward a successful outcome.
Conversational AI reduces average booking time by three to five times compared to form-based search. But that speedup only holds if the conversation stays coherent. A multi-turn conversation that loses context and forces the user to repeat themselves is worse than a form.
Context window management for long conversations
Language models have finite context windows. Every message in the conversation, every tool result, every system instruction takes up space. A long conversation can exhaust the context window, and when that happens, the model starts losing important information.
We manage this through a combination of summarization and selective retention.
Recent messages are kept in full. They contain the most relevant context and the nuances of the current interaction. Older messages are summarized: the key decisions, preferences, and outcomes are preserved, but the word-for-word exchange is compressed.
Tool results get special treatment. A flight search that returned three options two turns ago is still relevant. A flight search from twenty turns ago that the user rejected is probably not. We score tool results by recency and relevance, keeping the useful ones in full and summarizing or dropping the stale ones.
Agentic memory helps here too. Long-term preferences and facts about the user don't need to live in the conversation history at all. They're stored externally and injected into the context window as needed. This means a returning user's context window isn't cluttered with "I prefer window seats" from a conversation three months ago. That preference lives in memory and gets injected when it's relevant.
Handling "actually, forget Barcelona"
Topic switches are the most interesting engineering challenge in multi-turn conversation. The user has been exploring flights to Barcelona for five turns. Then they say: "Actually, forget Barcelona. What about Lisbon?"
What should happen to the Barcelona context? In a stateless system, you'd just process the new query independently. But in a stateful conversation, the agent needs to:
- Recognize that the user is abandoning the Barcelona search
- Retain the non-location-specific context (travel dates, number of travelers, budget range)
- Carry forward any relevant preferences expressed during the Barcelona discussion ("I want a place with good seafood" applies to Lisbon too)
- Not accidentally mix Barcelona results with the new Lisbon search
We handle this with conversation state tracking. The agent maintains an internal model of the current topic, active constraints, and resolved decisions. When it detects a topic switch, it archives the abandoned branch and starts fresh with the carried-forward constraints.
The nuance is distinguishing a true topic switch from a comparison. "What about Lisbon?" might mean "forget Barcelona, search Lisbon" or it might mean "search Lisbon too so I can compare." The agent infers intent from context. If the user said "Actually, forget Barcelona. What about Lisbon?" that's a switch. If they said "What would Lisbon look like? Same dates," that's a comparison.
Session persistence across hours and days
People don't plan trips in one sitting. They research a bit over lunch, come back after dinner, pick it up again the next morning. The conversation needs to survive these gaps.
We persist full conversation state, including the AI's internal tracking of topics, constraints, and decisions, across sessions. When a user returns after hours or days, the agent doesn't just have the message history. It has the conceptual state of the planning process.
This means the agent can say "Welcome back. Last time we were looking at flights to Tokyo in the second week of April. Want to pick up where we left off?" instead of treating the user as a blank slate.
The technical implementation stores conversation state as a structured document alongside the message history. The state document captures: current planning phase (searching, comparing, ready to book), active constraints (destination, dates, budget, travelers), unresolved questions (the user hasn't specified return date yet), and any bookings in progress.
When the conversation resumes, this state document gets loaded into the agent's context along with a summary of the recent conversation history. The agent can orient itself quickly and continue without the user having to repeat anything.
Measuring conversation quality
How do you measure whether a multi-turn conversation was "good"? Individual response accuracy is necessary but insufficient. We track several conversation-level metrics.
Resolution rate. Did the conversation end with a completed booking or a clear answer to the user's question? Abandoned conversations without resolution are a signal that something went wrong.
Turn count to resolution. Fewer turns to reach the same outcome is generally better. If the agent asks unnecessary clarifying questions or makes the user repeat information, the turn count inflates.
User satisfaction signals. Explicit feedback when available, but also implicit signals: did the user accept the first recommendation or ask for alternatives? Did they come back for another conversation? Did they complete the booking?
Context coherence score. An automated metric that checks whether the agent's responses are consistent with the accumulated context. If the agent "forgets" a preference that was stated earlier, or contradicts a decision that was already made, the coherence score drops.
These metrics are more meaningful than raw accuracy metrics because they capture the experience of a real multi-turn interaction, not just the quality of individual responses.
The average traveler visits 38 or more websites before booking. A big part of that is losing context between sessions. You searched on one site, saved something on another, texted your partner from a third. Multi-turn conversation with persistent memory eliminates that fragmentation.
How competitors fail at multi-turn
Most AI travel features from traditional OTAs reset on every interaction. Their "chat" feature is really a series of independent question-answer pairs that happen to appear in a message-like UI. Ask about flights to Tokyo, get an answer. Ask about hotels in Tokyo, get an answer that doesn't reference the flights. Ask to book, and you get redirected to the regular booking flow that knows nothing about the conversation.
This happens because the AI is a feature within a product, not the product itself. The conversation state lives in a separate silo from the booking state, which lives in a separate silo from the user profile. There's no unified context that spans the full interaction.
We built the product the other way around. The conversation IS the state container. Everything happens within it. Flight search, hotel search, preference capture, booking, payment, confirmation. There's one thread of context from start to finish, and the AI has access to all of it.
That architectural decision, made early, is what makes genuine multi-turn conversation possible. You can't retrofit it onto a product that was designed around forms and pages.
70% of travelers are open to AI-assisted trip planning. Multi-turn conversation quality is what determines whether they stay open after trying it.
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.