Building a Travel Knowledge Graph for AI Agents

An AI agent that can only search a travel API is just a natural language wrapper around a search form. You type "find flights to Tokyo" and it converts that into an API call. Useful, but not intelligent.

An AI agent with domain knowledge is something different. It knows that Narita is 60 minutes from central Tokyo but Haneda is 20 minutes. It knows that cherry blossom season in late March means higher prices and crowded attractions. It knows that JAL and ANA are the dominant carriers on US-Japan routes and that routing through Seoul on a Korean carrier is often cheaper. It knows that a 90-minute layover in Frankfurt is comfortable but a 45-minute layover in Heathrow Terminal 5 is risky.

This domain knowledge is what separates a travel-booking API wrapper from an AI travel agent. We encode it as a structured knowledge graph that the agent can query alongside live search results.

What the agent needs beyond raw search

Travel data APIs give you flights, prices, and schedules. They do not give you context. And context is what makes recommendations intelligent.

Consider this request: "Find me the cheapest flight from any East Coast city to anywhere in Southeast Asia for two weeks in March."

A raw search would need to query every East Coast airport to every Southeast Asian airport for every date combination in March. That is thousands of searches. Impractical and expensive.

An agent with domain knowledge can narrow this intelligently. It knows that the major gateways for Southeast Asia from the East Coast are JFK, EWR, and IAD (through carriers with Asian hubs). It knows that Singapore, Bangkok, and Kuala Lumpur are the most connected Southeast Asian hubs. It knows that mid-March is typically cheaper than early March for this region. It can make 10-20 targeted searches instead of thousands.

Encoding domain expertise

Our knowledge graph encodes several categories of travel expertise.

Hub and routing knowledge. For any origin-destination pair, which airports are the most common connection points? What are the usual routing patterns? This lets the agent suggest efficient routings and warn about problematic ones. "The cheapest option routes through Istanbul with a 14-hour overnight layover. Want me to find a better connection?"

Alliance and partnership knowledge. Which airlines are in the same alliance? Which code-share agreements exist? This helps with fare recommendations. "If you have miles with American Airlines, their partner carriers Japan Airlines and Cathay Pacific fly this route too."

Seasonal patterns. Pricing and weather patterns by destination and month. Cherry blossom season in Japan (late March to mid-April) means premium pricing. Monsoon season in Thailand (June to October) means lower prices but wet weather. Shoulder seasons often offer the best balance. Seasonal pricing patterns can save travelers 20-40% on well-timed bookings.

Airport-specific knowledge. Terminal layouts, connection times, common delays, transportation options. A 50-minute connection at a small regional airport might be fine. A 50-minute connection at a large international hub where you need to change terminals is risky. The knowledge graph encodes minimum recommended connection times by airport.

Destination knowledge. Visa requirements, currency, tipping customs, safety advisories, local transportation options. This feeds the agent's ability to provide practical advice alongside booking options.

Structure of the knowledge graph

We model this knowledge as entities and relationships, stored in a combination of our reference database and structured configuration files.

Entities include airports, airlines, cities, countries, regions, and seasonal periods. Each entity has properties and metadata.

Relationships include "serves" (airline serves route), "connects" (airports have connections), "member-of" (airline is member of alliance), "in-region" (city is in region), and "seasonal" (destination has seasonal pricing pattern).

The graph is not a traditional graph database. It is a set of relational tables and JSON structures that our agent queries through specialized tool functions. When the agent needs routing knowledge, it calls a tool that queries the graph. When it needs seasonal context, it calls a different tool.

This pragmatic approach works for our current scale. The knowledge graph has tens of thousands of entities and hundreds of thousands of relationships. A purpose-built graph database would offer query advantages at larger scale, but our relational approach is simpler to operate and fast enough for now.

Keeping knowledge current

Travel knowledge changes. Airlines add and drop routes. Airports open new terminals. Countries change visa policies. Seasonal patterns shift with climate and economic changes.

We update the knowledge graph through multiple channels:

Automated syncs for structured data like airline routes and schedules. We pull updated data from aviation databases on a regular schedule.

Manual curation for qualitative knowledge like connection risk assessments and seasonal recommendations. Our team reviews and updates this data quarterly, often based on real user conversations where the agent gave advice that could have been better.

Feedback loops from agent conversations. When a user corrects the agent ("actually, you don't need a visa for Japan if you're American"), we flag the knowledge for review. These corrections feed back into the graph after verification.

The balance between automated updates (fast but potentially noisy) and manual curation (slow but high-quality) is something we are still calibrating. For factual data (routes, schedules, visa requirements), automated updates with validation are best. For qualitative recommendations (which airports are pleasant for layovers, which neighborhoods are best for hotels), human curation produces better results.

Simple API wrappers versus intelligent agents

The knowledge graph is what differentiates an AI agent from a chatbot that can search flights-layer-ai-agent-search-flights). Basic OTA chatbots convert natural language to structured search queries and return the results. They have no opinion about which results are good. They do not know that a 45-minute connection in Atlanta is different from a 45-minute connection in CDG. They cannot tell you that flying through Dubai is usually cheaper but flying through London is usually faster for that particular route.

Our agent can do all of this because the knowledge graph gives it structured domain expertise that supplements the raw search data. The AI model provides reasoning capability. The knowledge graph provides something to reason about.

This combination produces recommendations that feel like they come from an experienced travel advisor, not a search engine. And that is the experience we are building toward.

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.