Understanding what makes a good agent prompt helps you get better results faster, and makes it easier to refine your agent as you use it.
Four things to define
1. Role
Give the agent a clear identity: what it is, who it works for, and what it's responsible for. A well-defined role helps the agent handle questions it wasn't explicitly trained for — it can reason from its role rather than guessing.
"You are a pre-departure operations assistant for a tour operator. Your job is to review upcoming bookings and flag anything that needs attention before departure."
A vague role ("you are a helpful assistant") produces a vague agent. Be specific.
2. Requirements
If the agent should always think in a certain way, follow a specific process, or present its output in a consistent format, put that in the system prompt. Anything you want to happen every time belongs here.
Common examples:
Always state the booking reference at the top of any report
Always present findings as a table, not prose
Always flag critical issues before lower-priority ones
Always ask for clarification before making assumptions about ambiguous input
The more consistently you need the output, the more explicitly you should specify it. The agent will produce what you describe — if you don't describe the format, it'll pick one.
3. Out of scope
Tell the agent what it should not do or answer. This matters more than it seems. Without guardrails, an agent connected to your booking data will try to help with anything a user asks — including questions it isn't set up to handle well.
Out-of-scope instructions serve two purposes: they keep the agent focused, and they protect users from confidently wrong answers on topics the agent doesn't have reliable data for.
"Do not answer questions about pricing or availability — direct users to the TripBuilder platform for these."
"Do not discuss flight delays or airline performance — these are outside your data sources."
Think about what your users might naturally ask that this agent shouldn't be answering, and tell it to redirect rather than guess.
4. Company terms
Agents are built on general-purpose AI — they understand standard English well but may not know your company's internal language. If your system prompt or your users' questions include terms that are specific to your business, define them.
This includes:
Internal codes or abbreviations (DCs, booking types, supplier names)
Terms your company uses differently from common usage (e.g. "service" meaning something specific in your context)
Product names or systems the agent needs to understand correctly
A short glossary in the system prompt is enough:
"'DC' means Distribution Channel — the channel through which a booking was made (e.g. direct, agency, online). Not a physical location."
Think about your audience
Before you write a word of the system prompt, answer two questions:
Who will use this agent? An agent built for your data analysts team can assume familiarity with booking terminology and handle complex queries. An agent built for travel agencies who contact your customer care team should communicate simply and not assume any knowledge of your internal systems.
What will they actually ask — and what topics regularly confuse them? If a certain topic comes up in questions but leads to bad outcomes (users who ask about pricing and get inconsistent answers, for example), put that topic explicitly out of scope. An agent that says "I can't help with that, but here's where to find it" is more useful than one that guesses.
These decisions shape the system prompt more than anything else.
The first version is never the last
A focused system prompt that does three or four things well is more useful than a comprehensive one that tries to do everything. Start narrow, test it with real questions from real users, and add to it based on what you see.
Soon we'll have a built-in feature for helping to write agents. Now the fastest way to improve an agent is to run it, export the chat (the export button is in the chat header), and read through what the agent assumed or decided on its own.
TripBuilder-specific guidance
Know which data source your agent uses
In TAI, agents access TripBuilder data through two connectors:
Cockpit Customer Care API — live booking data: individual bookings, traveller details, component status, payment state. Best for: per-booking lookups, health checks, status questions.
Snowflake data warehouse — historical and aggregated booking data. Best for: trends, reporting, analytics across many bookings.
Some questions span both (e.g. "show me all upcoming bookings with an outstanding balance" — that's aggregate, so Snowflake). Tell the agent which sources it has and what each is good for, so it doesn't try to answer warehouse questions with live booking data and vice versa.
Define TripBuilder terms
Some TripBuilder terminology has specific meanings that a general AI may interpret differently. If your agent prompt or your users will use these terms, define them:
Term | Define if... |
Component | Your users might say "service" instead — clarify which word to use |
DC / Distribution Channel | Abbreviation not obvious from context |
On-request | Might be confused with general "we'll consider it" language |
Booking reference format | If agents should recognise or validate a format |
Your product names | Any tour product names that aren't self-explanatory |
Set the right scope for your data
If your agent is built on Snowflake data, it can only answer questions about what's in your data warehouse.
Tell it explicitly:
"You have access to booking data from the last 24 months. Do not attempt to answer questions about older data or real-time inventory availability."
This prevents the agent from extrapolating or guessing when the data isn't there.
Examples
Top Booker Intelligence
A marketing agent that identifies high-value and lapsing customers for re-engagement campaigns. Used by a marketing team who don't need to know TripBuilder internals — they just need the output.
System prompt:
You are a customer intelligence analyst for a tour operator. When asked to generate a top booker report, you analyse booking history to identify high-value and frequent bookers and flag re-engagement opportunities.
Always:
Analyse at two levels: individual traveller and booking agency
Deduplicate passengers by email. Where email looks auto-generated (contains a timestamp, or domains such as @nezasabooking.ch), use passport number + name as the fallback key instead
Treat "drifting" as a distinct segment: passengers 3–9 months silent, separate from lapsing (12+ months). Catching drifting customers early costs far less than recovering fully lapsed ones.
Close with a priority hit-list table for marketing.
What a user would type:
Top booker report, last 12 months. Top 20 travellers and agencies by value and frequency, flag anyone not booked in 6 months.
Re-engagement list for marketing — all travellers who booked 2+ times between 2–3 years ago but haven't returned. Rank by historical value, include top destination.
Travel profile for our top 10 individual bookers: destinations, year-on-year shifts, group size, travel season.
What this illustrates:
Role — customer intelligence analyst, working for a tour operator
Requirements — two levels of analysis, specific deduplication logic, consistent output format ending with a hit-list table
Terms — "drifting" defined explicitly (3–9 months silent), auto-generated email pattern explained so the agent handles a known data quality issue consistently
Audience — the hit-list table is written "for marketing" — the agent knows who receives the output and frames its recommendations accordingly
Group Tour Departure Room List
An operations agent that compiles a supplier-ready room list for a specific group tour departure — sent directly to hotels before guests arrive.
System prompt:
You are a booking operations assistant for a tour operator, generating departure room lists that get sent directly to hotels and ground suppliers.
When given a tour template ID and departure date:
1. Identify all confirmed bookings for that departure
2. Fetch full itinerary detail for every booking
3. Extract per traveller: full name, passport name (flag if it differs from the preferred name), gender, date of birth, room type, and any special requests
Always:
- Use the passport name for hotel check-in — never the preferred name
- Flag every special request in its own section
- If the pax count from a warehouse query doesn't match the confirmed pax you resolved from the bookings, state the discrepancy explicitly
- If the template ID or departure date is missing, ask before proceeding
What a user would type:
Room list for the Morocco group, departing 15 August.
Full passenger manifest and room assignments for template TB-2024 departing 22 June. Include flight details and flag all special requests for the hotel.
How many rooms and pax do we have confirmed for the Italy tour on 3 September?
What this illustrates:
Role — booking operations assistant, output goes to hotels (external audience)
Requirements — strict processing order, explicit instruction on passport vs preferred name (caught a real error in testing), mandatory discrepancy flagging rather than silently reconciling counts
Out of scope — implicitly: if key inputs are missing, stop and ask rather than guessing or proceeding with incomplete data
Terms — "passport name" vs "preferred name" defined and distinguished, because the distinction matters operationally and the agent needs to treat them differently