Prompt Engineering for Travel Agents
System prompts define personality, policy, and capability boundaries. Here are the lessons from building production prompts for AI travel booking.
The model instructions is the most important artifact in an AI agent. It defines the agent's personality, its policies, its capabilities, and its limitations. In a production travel booking agent, the model instructions is not a clever paragraph someone wrote once. It is a living document that evolves weekly based on production data, user feedback, and failure analysis.
I want to share the lessons we have learned about writing and maintaining production prompts for AI travel booking. Not the beginner tips. The hard-won lessons from watching real conversations break in real time.
System prompts as the agent's DNA
The model instructions has several layers, each serving a different purpose.
Personality layer. Who is this agent? We define tone (professional but approachable), level of formality (conversational, not corporate), and personality traits (opinionated about travel, honest about limitations). The personality layer determines how the agent sounds.
"You are a knowledgeable travel advisor who has opinions. When you recommend a flight, explain why. When you think a user's plan has issues, say so politely but directly."
Policy layer. What rules does the agent follow? Booking confirmation requirements. Privacy handling. Cancellation policy communication. Safety guidelines. This layer prevents the agent from doing things it should not do and ensures compliance with business rules.
"Never book a flight without explicit user confirmation. Always disclose the cancellation policy before booking. If a user asks about visa requirements, query the visa tool rather than relying on training data."
Capability layer. What tools are available and when should each be used? This layer describes the tool suite and provides guidance on tool selection.
"Use the flight search tool when the user wants to find flights. Use the price analysis tool when the user asks if a price is good. Use the booking tool only after the user has confirmed they want to proceed."
Safety layer. What should the agent refuse to do? Boundaries on discussion topics. Restrictions on financial advice beyond travel. Guardrails against manipulative or harmful user requests.
Each layer interacts with the others. Personality affects how policies are communicated. Capabilities affect what the agent can do when policies require certain actions. Safety overrides all other layers.
Few-shot examples for edge cases
The model instructions can describe ideal behavior, but description alone does not reliably produce the desired behavior for unusual situations. Few-shot examples fill this gap.
We include examples for scenarios that have caused problems in production:
Sold-out dates. Without an example, the agent might hallucinate availability. With an example, it knows to say "no flights are available on those dates" and suggest alternatives.
Bizarre requests. "Book me a flight to the moon." Without an example, the agent might try to search or generate a confused response. With an example, it handles it gracefully: "I can only book real flights to real destinations. Where would you like to go?"
Contradictory constraints. "I want a direct flight under $300 from SFO to NRT in peak season." This might not exist. Without an example, the agent might either hallucinate an option or give up. With an example, it explains the tradeoff: "Direct flights on this route in peak season start around $650. I can find flights under $300 with 1-2 stops. Which constraint is more flexible?"
Sensitive situations. "I need to fly somewhere my partner doesn't know about." The agent should not assist with deception, but it also should not moralize. A few-shot example helps calibrate the response.
Few-shot examples work because they provide concrete reasoning patterns for the model to follow. Abstract rules are interpreted. Concrete examples are imitated.
Tone calibration
The agent's tone is the first thing users evaluate. Get it wrong and they disengage regardless of capability.
We spent weeks calibrating tone. The failure modes:
Too formal: "I would be delighted to assist you in procuring air transportation to your desired destination." Nobody talks like this. It creates distance.
Too casual: "lol tokyo flights are wild rn, want me to check?" Undermines trust for financial transactions.
Too apologetic: "I'm so sorry, I couldn't find any direct flights! I really apologize for the inconvenience!" Excessive apology makes users worry the agent is incompetent.
Too robotic: "Found 47 results. Top 3 displayed below." No personality. No engagement. No explanation.
The calibration we landed on: knowledgeable friend who happens to be a travel expert. Confident but not arrogant. Honest about limitations without being self-deprecating. Direct without being curt. The agent has opinions ("I'd go with option B") but respects the user's decision.
Tone also adapts to context. A first-time user exploring destinations gets a warmer, more conversational tone. A returning user rebooking a familiar route gets a more efficient, concise tone. A user dealing with a disruption gets a calm, reassuring tone focused on solutions.
Policy encoding
Travel has complex rules. Fare rules, cancellation policies, baggage allowances, visa requirements, loyalty program terms. The agent needs to communicate these accurately.
We encode policies in the model instructions rather than relying on the model's training data. Training data about airline policies may be outdated. The model instructions contains current rules, or better yet, directs the agent to query the relevant tool for the latest information.
"When a user asks about cancellation policy, always query the booking details tool for the specific fare rules. Never state a cancellation policy from general knowledge."
This prevents a common failure: the agent confidently stating an airline's cancellation policy based on training data when the actual policy has changed since the data cutoff.
The iterative loop
System prompts are not written once. They evolve continuously.
Our iteration cycle:
- Monitor production conversations. Look for failures: wrong tool selection, tone issues, policy violations, user confusion.
- Identify patterns. One failure is an anecdote. Ten failures with the same root cause are a pattern.
- Hypothesize a fix. Usually a clarification in the prompt, a new few-shot example, or a restructured instruction.
- Test against eval dataset. Run the modified prompt against our evaluation scenarios to ensure the fix does not introduce regressions.
- Deploy and monitor. Ship the update and watch for improvement on the target metric and stability on other metrics.
We make prompt changes weekly. Some weeks are minor tweaks (adjusting how the agent handles a specific edge case). Other weeks are significant restructurings (reorganizing tool descriptions for better selection accuracy).
Iterative prompt development is continuous. Prompts evolve weekly based on production data. The prompt that ships today is measurably better than the prompt from a month ago, which was better than the one from two months ago.
What not to put in prompts
Not everything belongs in the model instructions.
Real-time data. Flight prices, availability, schedules. These change constantly. The prompt should direct the agent to query tools, not contain the data itself.
User-specific information. Preferences, history, profile data. These come from the memory system and are injected into the context, not hardcoded in the prompt.
Complex logic. Multi-step decision trees with many branches are hard to express in natural language and hard for the model to follow reliably. These are better implemented as tool logic that the agent invokes.
Fine-grained formatting. Detailed HTML or markdown formatting rules tend to be followed inconsistently. Better to handle formatting in the rendering layer than to fight with the model over exact output structure.
The model instructions defines behavior. Tools provide data. Memory provides personalization. The rendering layer handles presentation. Each layer does what it is best at. Overloading the prompt with responsibilities that belong elsewhere leads to brittleness.
Function calling accuracy depends heavily on schema design in the model instructions. The prompt is the foundation. But it is a foundation, not the whole building. Getting it right is necessary. Expecting it to do everything is a recipe for fragile agents.
The best travel app has a model instructions that is clear, comprehensive, and continuously improving. It reads like a well-organized handbook for a competent travel advisor, not like a list of rules for a machine to follow.
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.