DEV Community: Martin Tuncaydin

AI-Driven Dynamic Pricing in Hotels: A Data Engineer's Deep Dive

Martin Tuncaydin — Wed, 26 Aug 2026 09:01:11 +0000

I've spent the better part of a decade building data systems that power pricing decisions in the travel industry, and I can tell you this: dynamic pricing in hotels isn't just about running a regression model on historical booking data. It's an intricate dance between feature engineering, real-time inference, and the operational realities of revenue management teams who need to trust—and occasionally override—what the algorithms suggest.

The hotel industry has always practiced yield management, but the shift to AI-driven dynamic pricing represents a fundamental architectural challenge. Traditional revenue management systems operated on batch processes, recalculating rates once or twice daily. Modern systems demand sub-second inference capabilities, ingesting real-time signals from dozens of sources and adjusting prices continuously. But this isn't just a scaling problem—it's a complete reimagining of how pricing intelligence flows through an organisation.

The Feature Engineering Challenge in Hotel Pricing

When I first tackled hotel pricing systems, I underestimated how different this domain is from airline revenue management or e-commerce pricing. Hotels aren't selling fungible widgets. A room on the third floor facing the car park isn't the same product as a room on the tenth floor with a harbour view, even if they're both listed as "Deluxe Queen." The feature space explodes when you account for room-level attributes, guest history, channel-specific behaviour, and competitive positioning.

I've found that effective feature engineering for hotel pricing falls into several distinct categories. Temporal features are the foundation—day of week, days until arrival, length of stay, seasonality indicators, and local event calendars. But the real predictive power comes from layering in competitive intelligence. This means ingesting rate shopping data from sources like OTA platforms, metasearch engines, and direct competitor monitoring tools. The challenge is that this data arrives asynchronously, often with missing values or stale snapshots.

Demand signals constitute another critical feature set. I've built pipelines that track search volume trends, booking pace relative to historical patterns, cancellation rates by segment, and group block pickup. Tools like Google Cloud Dataflow and Apache Kafka have been instrumental in making these real-time signals available to the pricing engine without introducing latency that would render them useless.

Guest-level features add another dimension. Past booking behaviour, channel preference, loyalty tier, and even browsing patterns on the booking engine all inform willingness to pay. The engineering challenge here is joining disparate data sources—CRM systems, property management platforms, and web analytics—into a unified feature store that can be queried in milliseconds.

Then there's the contextual layer: weather forecasts, flight loads into the destination, major conferences or sporting events, and even social media sentiment about the destination. I've experimented with incorporating external datasets from weather APIs, aviation data providers, and event listing platforms. The key is determining which signals actually move the needle on booking probability versus which just add noise to the model.

Building Real-Time Inference Pipelines That Scale

The architectural leap from batch pricing to real-time dynamic pricing is where most implementations stumble. I've seen organisations invest heavily in sophisticated machine learning models only to deploy them in a system that can only recalculate prices every few hours. The result is a pricing engine that's perpetually fighting yesterday's battle.

My approach has been to separate the model training pipeline from the inference infrastructure entirely. Training happens in a batch environment—using frameworks like TensorFlow or XGBoost on historical data, often running on GPU clusters to handle the parameter tuning and cross-validation required for ensemble methods. But inference needs to happen in a completely different architecture optimised for latency and throughput. Full stop.

I've built inference layers using containerised microservices deployed on Kubernetes, with model artifacts stored in object storage and loaded into memory at startup. The pricing API sits behind a load balancer and can scale horizontally to handle traffic spikes during peak booking periods. Feature retrieval is the bottleneck in most systems, so I've invested heavily in feature stores—using technologies like Redis for hot features and BigQuery for historical lookups—that pre-compute and cache feature vectors.

The pricing engine itself receives a request with minimal context—property ID, room type, arrival date, length of stay—and needs to enrich that with dozens of features from various sources, run inference across potentially multiple models, and return a price recommendation in under 100 milliseconds. This requires careful orchestration of parallel data fetches, circuit breakers for unavailable data sources, and fallback strategies when upstream services are slow.

I've learned that model complexity is often the enemy of operationalisation. A gradient boosted tree with 500 estimators might achieve marginally better offline metrics than one with 100 estimators, but if it doubles your inference latency, you've made the wrong trade-off. I've had success with model distillation techniques, where a complex ensemble is trained offline and then a simpler student model is trained to approximate its predictions with much faster inference times.

Handling Concept Drift and Model Retraining

Hotel demand patterns shift constantly. A destination that was popular with business travellers pre-pandemic suddenly becomes a leisure hotspot. A new hotel opening nearby fundamentally alters competitive dynamics. Seasonal patterns that held for years break down when a major event calendar changes. Static models decay rapidly in this environment.

I've built systems that continuously monitor model performance in production, tracking not just prediction accuracy but also business metrics like revenue per available room and booking conversion rates. When performance degrades beyond defined thresholds, the system triggers a retraining workflow. This sounds straightforward in theory, but the engineering reality is complex.

The challenge is that you can't evaluate pricing model performance immediately. A price recommendation made today for a stay three months from now won't have ground truth data until after the stay date passes. I've implemented shadow mode deployments where new model versions run in parallel with production, generating predictions that are logged but not acted upon. This allows for safe validation before cutover.

Feature drift is particularly insidious in hotel pricing. A competitor might stop reporting rates to the GDS, suddenly leaving you with missing data where you once had complete visibility. An OTA might change its API response format, breaking your rate shopping parser. I've built data quality monitoring that tracks feature distributions over time and alerts when statistical properties shift unexpectedly.

Retraining frequency is a delicate balance. Too frequent and you risk overfitting to noise; too infrequent and you miss important signal shifts. I've settled on a hybrid approach: incremental updates weekly to capture short-term trends, full retrains monthly with expanded hyperparameter search, and ad-hoc retrains triggered by significant market events or persistent performance degradation.

The Human-in-the-Loop Reality

Here's what the vendor presentations don't tell you: no hotel revenue manager will ever let a fully automated system set prices without oversight. I've learned this lesson through multiple implementations. The most successful systems I've built aren't fully autonomous—they're recommendation engines that augment human expertise rather than replacing it.

I've designed interfaces that show revenue managers not just the recommended price, but the model's confidence level, the primary features driving the decision, and how the recommendation compares to recent human overrides. This transparency is crucial for building trust. When a model recommends a rate that seems counterintuitive, a revenue manager needs to understand why before accepting it.

Override patterns are themselves valuable training data. When a human consistently adjusts the model's recommendations in a particular direction for specific scenarios, that's a signal that the model is missing something important. I've built feedback loops that incorporate override data back into the training pipeline, treating human expertise as a label source for edge cases the model hasn't learned.

There are also business constraints that pure machine learning approaches struggle to encode. Minimum rate guarantees in corporate contracts, parity requirements across distribution channels, psychological price points—these rules need to be enforced as hard constraints on top of the model's output. I've implemented these as post-processing layers that adjust model recommendations to meet business requirements while minimising deviation from the optimal price.

Can every team pull this off? Honestly, no. The most sophisticated systems I've worked on include what I call "confidence-based automation levels." When the model has high confidence and the recommended price falls within normal bounds, it can automatically update rates across all channels. When confidence is moderate or the price represents a significant shift, it flags for human review. When confidence is low or multiple models disagree pretty substantially, it escalates for manual pricing. This tiered approach balances automation benefits with risk management.

The Data Infrastructure Foundation

None of this sophisticated pricing machinery works without rock-solid data infrastructure underneath. I've spent countless hours debugging pricing anomalies that traced back to data quality issues—duplicate booking records, timezone mismatches between systems, or stale cache entries serving outdated competitive rates.

My philosophy is that data pipelines for pricing systems need to be instrumented like production application code. Every transformation stage should emit metrics on record counts, latency, and data quality checks. I've used tools like Great Expectations to codify data quality rules and Apache Airflow to orchestrate the dependency graph of data preparation tasks.

The challenge with hotel data is that it lives in dozens of systems—property management systems, booking engines, channel managers, revenue management platforms, CRM systems, and various third-party data feeds. Each has its own data model, update frequency, and reliability characteristics. I've built integration layers that normalise these disparate sources into a unified schema, handling the inevitable inconsistencies and filling gaps where data is missing.

Versioning is critical but often overlooked. When you retrain a model, you need to be able to reproduce the exact feature values that were available at training time. I've implemented feature stores with temporal versioning, allowing you to query "what was the competitive rate set for this property on this date as of when the model was trained." This is essential for debugging model behaviour and conducting valid backtests.

My View on the Future of Hotel Pricing Intelligence

I believe we're still in the early innings of AI-driven hotel pricing. The current generation of systems are impressive, but they're largely optimising within existing frameworks—adjusting prices to maximise revenue given current demand patterns. The next frontier is systems that actively shape demand through more sophisticated understanding of customer behaviour and strategic pricing over longer time horizons.

I'm particularly excited about the potential for multi-agent reinforcement learning approaches that can simulate competitive dynamics and learn optimal pricing strategies through interaction rather than just supervised learning on historical data. I've begun experimenting with these techniques, though they're not yet production-ready given the sample efficiency challenges.

The integration of large language models for understanding unstructured signals—parsing social media sentiment, interpreting event descriptions, or extracting insights from customer reviews—represents another promising direction. These capabilities could enrich the feature space in ways that traditional structured data pipelines can't match.

What keeps me engaged with this problem space is the continuous evolution. Just when you think you've built a robust system, market dynamics shift, new data sources become available, or model architectures improve. The best pricing systems are never finished—they're constantly learning, adapting, and improving. That's the nature of applying machine learning to a domain as dynamic and competitive as hotel revenue management.

About Martin Tuncaydin

Martin Tuncaydin is an AI and Data executive in the travel industry, with deep expertise spanning machine learning, data engineering, and the application of emerging AI technologies across travel platforms. Follow Martin Tuncaydin for more insights on dynamic pricing, hotel technology.

Generative AI for Travel Content: Martin Tuncaydin on Opportunity and Risk

Martin Tuncaydin — Mon, 24 Aug 2026 09:01:04 +0000

Generative AI for Travel Content: on Opportunity and Risk

I've spent the better part of two decades watching technology reshape how we discover, book, and experience travel. But nothing has moved quite as fast—or raised quite as many questions—as generative AI's arrival in content creation. In the past eighteen months, I've seen travel brands rush to adopt tools like ChatGPT, Claude, and Jasper for everything from destination guides to hotel descriptions. The promise is irresistible: scale content production, reduce costs, serve more markets. The reality is considerably — more than most expect more nuanced.

The Efficiency Mirage: Why Scale Isn't Strategy

When I first experimented with GPT-4 to generate destination content, I was genuinely impressed. Ask it to write 500 words on "things to do in Porto," and you'll get coherent, structurally sound prose in seconds. The syntax is clean. The tone is confident. The problem emerges when you actually know Porto.

I've walked those streets. I know that the Livraria Lello bookshop, while stunning, is often so crowded that the experience can disappoint. I know that the best views aren't always from the obvious tourist miradouros. Generative AI doesn't know these things—it assembles patterns from training data, blending thousands of travel blogs and guides into a statistically plausible narrative. The result is content that reads well but feels generic, lacking the texture that comes from lived experience. Simple as that.

This matters profoundly for SEO (worth emphasising here). Google's helpful content updates since 2022 have made it increasingly clear that the algorithm rewards expertise, experience, authoritativeness, and trustworthiness—the E-E-A-T framework. Content that feels synthesised rather than authored by someone with genuine knowledge is less likely to rank well over time. I've seen several travel sites experience traffic declines after flooding their blogs with AI-generated articles that technically checked all the on-page SEO boxes but lacked depth.

The efficiency gains are real, but they're not a substitute for strategy. AI can help you produce more content faster. It cannot help you produce more valuable content unless you build the right workflows around it.

Hallucination Risk: When AI Invents the Facts

Does this mean avoiding AI entirely? Absolutely not. The most dangerous aspect of generative AI in travel content isn't what it gets slightly wrong—it's what it invents with complete confidence. I call these "plausible fabrications," and they're everywhere.

I once reviewed an AI-drafted guide to Tallinn that confidently recommended visiting a specific medieval museum. The museum name was plausible, the description detailed, the opening hours precise. The museum didn't exist. The model had synthesised elements from several real institutions into a fictional composite. For a reader unfamiliar with Tallinn, this would have been entirely convincing—right up until they tried to visit.

Hallucinations occur because large language models are fundamentally prediction engines, not knowledge databases. When asked for information, they generate the most statistically likely continuation of the text, not the most factually accurate. In domains like travel, where specificity matters—opening times, admission prices, seasonal closures, address details—this creates genuine liability.

I've seen AI confidently state that certain attractions are wheelchair accessible when they're not, recommend restaurants that closed years ago, and provide visa requirements that are outdated or simply wrong. Each of these errors erodes trust, damages brand reputation, and in some cases could expose organisations to legal risk if travellers make decisions based on incorrect information.

The solution isn't to avoid AI—it's to never trust it blindly. Every fact, every recommendation, every specific claim needs human verification. This is non-negotiable.

Human-in-the-Loop: The Only Sustainable Model

The travel brands I've seen succeed with generative AI are those that treat it as a drafting tool, not a publishing tool. The workflow looks fundamentally different from traditional content production, but it still centres on human judgement.

My preferred approach involves three distinct layers. First, use AI to generate structural scaffolding—outlines, section frameworks, initial research summaries. Tools like Claude are particularly good at this because you can provide context and constraints upfront. Second, have subject matter experts—people who've actually been to the destination or deeply understand the topic—expand, correct, and enrich that scaffolding with specific knowledge. Third, implement a verification layer where factual claims are checked against authoritative sources.

This isn't just about accuracy—it's about voice and differentiation. I can usually spot AI-generated travel content within two paragraphs because it lacks personality. It hedges constantly ("you might enjoy," "considered by many to be"), uses the same transitional phrases, and rarely takes a strong position. Human editors need to inject perspective, opinion, and the kind of specific detail that only comes from experience.

I've also found that AI works better for certain content types than others. It's reasonably good at synthesising information for practical guides—"how to get from the airport to the city centre" or "visa requirements for UK citizens." It's terrible at writing compelling narrative travel stories, nuanced cultural commentary, or anything requiring genuine emotional resonance.

The workflow challenge is real. Human-in-the-loop approaches don't eliminate costs—they shift them. You're no longer paying writers to create from scratch, but you are paying editors and fact-checkers to refine and verify. For many organisations, this still represents a significant efficiency gain, but it's not the order-of-magnitude cost reduction that some vendors promise.

SEO Implications: The Originality Problem

Google's algorithm updates have created a fascinating paradox for AI-generated content. On one hand, the technology has never been better at producing text that meets basic SEO requirements—proper heading structure, keyword integration, semantic relevance. On the other hand, the sheer volume of similar AI-generated content flooding the web has made originality more valuable than ever.

I've been tracking several travel websites that went all-in on AI content in early 2023. Many saw initial traffic gains as they rapidly expanded their content libraries. By mid-2023, most had plateaued or declined. The pattern is consistent: AI-generated content ranks adequately for low-competition, long-tail queries, but struggles to compete for valuable head terms against established, human-authored content.

The reason, I believe, comes down to differentiation signals. When hundreds of sites publish nearly identical AI-generated guides to popular destinations, Google's algorithm needs ways to determine which deserves to rank. It increasingly looks for signals that suggest genuine expertise—unique data, original photography, specific recommendations that differ from the consensus, author credentials, engagement metrics that suggest readers find the content valuable.

This has profound implications for content strategy. The competitive advantage no longer lies in simply having content on every topic—it lies in having content that offers something competitors don't. AI can help you achieve coverage, but it can't easily help you achieve differentiation.

I've also noticed that AI-generated content tends to cluster around the same keyword targets because the models identify the same obvious opportunities. This creates a race to the bottom where everyone publishes similar content for the same queries, and nobody ranks particularly well.

Building Responsible AI Content Workflows

Based on my experience implementing these systems, several principles have emerged as essential for anyone serious about using generative AI in travel content production.

First, establish clear guidelines about what AI can and cannot do without human oversight. In my workflow, AI never publishes directly. It never makes factual claims about specific businesses without verification. It never handles time-sensitive information like opening hours or prices without a human checking current sources.

Second, invest in prompt engineering and context provision. The quality of AI output is directly proportional to the quality of input. I've developed detailed prompt templates for different content types that include brand voice guidelines, target audience definitions, and specific constraints. A well-crafted prompt can dramatically reduce the editing burden downstream.

Third, build verification into the workflow as a distinct step, not an afterthought. I use a simple taxonomy: green for AI-generated content that can be lightly edited, amber for content requiring fact-checking, red for content that should be rewritten by a human. Most travel content falls into amber—it provides a useful starting point but needs significant verification before publication.

Fourth, maintain a feedback loop. When editors identify recurring errors or problems in AI output, feed that information back into your prompts and guidelines. The system should improve over time as you learn what works and what doesn't.

Finally, be transparent where appropriate. I don't think every piece of content needs to be labelled as AI-assisted, but when you're using AI to generate substantial portions of informational content, consider whether disclosure serves your audience's interests.

My View: AI as Amplifier, Not Replacement

I remain optimistic about generative AI's role in travel content, but only when we're honest about its limitations. The technology is extraordinarily good at certain tasks—synthesising information, maintaining consistent structure, adapting tone, generating variations—but it fundamentally cannot replace the insight that comes from experience.

The travel brands that will win in this new landscape are those that use AI to amplify human expertise, not replace it. Use AI to handle the scaffolding so your experts can focus on what makes content genuinely valuable: specific recommendations, nuanced cultural context, personal perspective, and the kind of detail that only comes from being there.

The risk isn't that AI will replace travel writers—it's that organisations will convince themselves it can, publish masses of mediocre content, and damage both their SEO performance and their brand reputation in the process. I've seen it happen, and it's entirely preventable.

My approach remains pragmatic: use the best tool for each job, verify everything, and never lose sight of what makes travel content valuable in the first place—the human experience of discovery, rendered in a way that helps others discover it too.

About Martin Tuncaydin

Graph Databases for Travel: How to Map Routes, Hubs, and Connections Efficiently

Martin Tuncaydin — Fri, 21 Aug 2026 09:01:08 +0000

Graph Databases for Travel: Mapping Routes, Hubs and Connections

The Problem Traditional Databases Can't Solve

I've spent years watching travel technology teams struggle with the same architectural challenge: how do you efficiently model and query a network where everything connects to everything else? Relational databases excel at storing structured records—flight schedules, hotel inventories, passenger manifests—but they fall apart when you need to answer questions like "What's the fastest three-hop journey from Manchester to Bali with a maximum two-hour layover at each stop?"

This isn't a hypothetical problem. Every multi-modal journey planner, every airline alliance route optimiser, every ground transportation network faces this reality daily. When I worked on international route planning systems, I watched SQL queries timeout after joining seven or eight tables just to trace connections between cities. The performance degradation was exponential, not linear.

Graph databases emerged as the answer to this specific class of problem. Unlike relational systems that treat relationships as expensive JOIN operations, graph databases treat connections as first-class citizens. A route between London and Singapore isn't a foreign key relationship—it's an edge in a network that can be traversed in microseconds, not seconds.

Why Travel Networks Are Inherently Graph-Shaped

The travel industry operates on networks, not hierarchies. Consider a typical passenger journey: they might take a bus to the airport, fly to a hub city, connect to a regional flight, then take a train to their final destination. Each leg involves different operators, different vehicle types, different booking systems—but from the traveller's perspective, it's one continuous journey.

I've found that attempting to model this in a relational schema creates what I call "relationship explosion." You end up with junction tables linking airports to flights, flights to airlines, airlines to alliances, alliances to code-share agreements, and so on. Querying across these tables to find optimal routes becomes computationally prohibitive.

Graph databases invert this model. In Neo4j or TigerGraph, airports become nodes, flights become edges, and properties like departure time, aircraft type, or fare class attach directly to those edges. When I need to find all routes between two cities with specific constraints, I'm traversing a native graph structure rather than reconstructing it from normalised tables on every query.

The performance difference is dramatic. Path-finding algorithms like Dijkstra's shortest path or A-star search run orders of magnitude faster on graph structures because they don't need to repeatedly JOIN tables—they simply follow pointers through memory.

Neo4j: Declarative Queries for Complex Route Logic

My first serious engagement with graph databases came through Neo4j, largely because of its Cypher query language. Cypher lets you express graph patterns declaratively, which maps beautifully to how travel planners actually think about routes.

When I need to find all two-stop journeys from Paris to Tokyo with specific layover constraints, the Cypher query reads almost like natural language. I can specify patterns like "airport to airport via hub" and attach filters on properties like connection time or airline alliance membership. The database engine handles the traversal optimisation.

What impressed me most was how Neo4j handles variable-length paths. In travel planning, you often don't know in advance how many hops a journey will require. You might want all routes up to four segments, or all routes within a certain total duration regardless of segment count. Neo4j's pattern matching syntax makes these queries straightforward rather than requiring recursive CTEs or procedural code.

I've also leveraged Neo4j's built-in graph algorithms library for hub identification. By running betweenness centrality calculations across a network of airports and routes, I can quantify which airports function as critical connection points. This isn't just academic—it directly informs capacity planning and disruption management strategies.

The visualisation capabilities matter more than I initially expected. When presenting route optimisation findings to business stakeholders, being able to render the actual network graph—with nodes sized by passenger volume and edges coloured by load factor—communicates insights far more effectively than spreadsheets ever could.

TigerGraph: Handling Scale and Real-Time Updates

As useful as Neo4j has been for my work, I've increasingly turned to TigerGraph when dealing with truly massive networks that require real-time updates (worth emphasising here). The travel industry operates at enormous scale—millions of route options, constantly changing availability, dynamic pricing that shifts by the minute.

TigerGraph's native parallel graph architecture handles this scale differently. Rather than optimising for single-threaded traversals, it distributes graph partitions across multiple nodes and processes queries in parallel. When I'm analysing global airline networks with hundreds of thousands of route segments, this architectural difference becomes critical.

I've found TigerGraph particularly valuable for multi-modal journey planning that combines air, rail, bus, and ferry networks into a single unified graph. The challenge isn't just the number of nodes and edges—it's the rate of change. Train schedules update hourly, flight availability changes with every booking, traffic conditions affect bus journey times in real-time.

TigerGraph's GSQL query language takes more effort to learn than Cypher, but it exposes lower-level control over traversal logic. For complex optimisation problems—like finding the minimum-cost journey across multiple operators with different pricing rules—I can write custom accumulators and traversal logic that would be difficult to express declaratively.

Does this mean avoiding AI entirely? Absolutely not. The real-time analytics capability has been transformative for disruption management scenarios. When a major hub experiences delays, I can run impact analysis across the entire network in seconds, identifying which downstream connections will be affected and which alternative routes exist. This kind of operational intelligence simply isn't feasible with batch-oriented relational systems.

Modelling Time and Context in Travel Graphs

One of the subtler challenges I've encountered in applying graph databases to travel is how to model temporal and contextual dimensions. A flight from London to New York exists as a route, but it operates on specific days, at specific times, with varying availability and pricing.

I've experimented with several approaches. The simplest is to treat each scheduled departure as a separate edge—so flight BA117 on Tuesday becomes a distinct relationship from BA117 on Wednesday. This works for small networks but creates edge explosion at scale.

A more sophisticated approach uses property graphs with rich metadata. A single route edge carries arrays of departure times, seat availability by class, and fare structures. Queries then filter based on temporal constraints rather than multiplying edges. This keeps the graph structure manageable while preserving the temporal detail needed for real journey planning.

Context matters too. The optimal route for a business traveller prioritising speed differs from a budget traveller prioritising cost, which differs from a traveller with mobility requirements. I've modelled this by attaching cost functions to edges rather than static weights—the same route segment can be evaluated differently depending on the query context.

Seasonal and event-based patterns add another layer. A route between two cities might have radically different capacity and pricing during a major sporting event or holiday period. I've found that combining graph databases with time-series data stores—using the graph for network structure and a columnar database for temporal patterns—provides the best of both worlds.

Integration Patterns and Practical Architecture

The question I'm asked most often is: should I replace my relational databases with a graph database? My answer is almost always no. Graph databases excel at specific problems—network traversal, relationship-heavy queries, pattern matching—but they're not general-purpose data stores.

In every travel technology architecture I've designed, graph databases sit alongside relational systems, not instead of them. Passenger records, booking transactions, inventory management—these are better served by traditional RDBMS or document stores. The graph database holds the network model: airports, routes, connections, and the metadata needed to traverse them intelligently.

The integration pattern I've found most effective uses event-driven synchronisation. When a new route is added to the scheduling system, an event triggers an update to the graph database. When availability changes, the relevant edge properties update. This keeps the graph current without requiring it to be the system of record for operational data.

I've also learned that graph databases require different indexing strategies. In relational systems, you index columns you'll filter on. In graph databases, you need to consider traversal patterns—which node types will be starting points for queries, which properties will be used to filter during traversal, which relationship types will be followed most frequently.

Query optimisation is different too. In SQL, you worry about JOIN order and index usage. In graph queries, you worry about traversal direction and pattern specificity. I've found that starting with highly specific node matches and expanding outward more or less performs better than starting with broad patterns and filtering down.

The Future I See for Graph Databases in Travel

My view is that we're still early in understanding how to leverage graph databases effectively in travel technology. The current applications—route planning, hub analysis, alliance networks—are just the beginning.

I believe the next frontier is combining graph structures with machine learning for predictive journey planning. Rather than just finding the shortest path as the network exists today, we could predict likely delays, estimate connection risk, and recommend routes based on historical success rates. The graph becomes not just a map of possibilities but a probabilistic model of likely outcomes.

Multi-modal integration remains largely unsolved at industry scale. We have good graph models for air travel, decent models for rail, but genuine door-to-door journey planning that seamlessly combines air, rail, bus, ride-share, and active transport is still rare. The technical capability exists—we can model it all in a unified graph—but the commercial and data-sharing barriers remain high.

I'm also watching developments in distributed graph databases with interest. As networks grow and update frequencies increase, the ability to partition graphs geographically while maintaining fast cross-partition queries becomes critical. TigerGraph has made progress here, but I expect this to be an area of significant innovation.

Ultimately, I see graph databases as essential infrastructure for any travel technology platform that takes multi-modal journey planning seriously. They're not a silver bullet—they require careful data modelling, thoughtful integration architecture, and specific query optimisation—but for the problems they're designed to solve, nothing else comes close. The travel industry is fundamentally about connecting places and people through networks, and graph databases are the most natural way to model that reality in software.

About Martin Tuncaydin

Agentic AI Workflows for Corporate Travel Management: When Intelligent Systems Handle the Chaos

Martin Tuncaydin — Wed, 19 Aug 2026 09:01:20 +0000

I've spent years watching corporate travel procurement evolve from fax machines to web portals, and now we're standing at the threshold of something fundamentally different. The buzzword "agentic AI" gets thrown around carelessly, but when applied properly to travel management, it represents a genuine paradigm shift—one where autonomous software agents don't just execute tasks, but negotiate, decide, and collaborate on behalf of travellers and finance teams.

The corporate travel landscape is uniquely suited to multi-agent architectures because it's inherently a coordination problem involving multiple stakeholders with competing priorities. A single business trip involves fare negotiations, policy compliance, approval workflows, expense reconciliation, and disruption management. Traditional automation handles these in silos. Agentic systems orchestrate them as an intelligent collective.

The Architecture of Autonomous Travel Agents

When I talk about agentic AI in this context, I'm describing systems where specialised agents operate semi-independently within defined boundaries, communicating through structured protocols to achieve complex outcomes. Think of it as a digital travel department where each agent has a specific mandate and expertise.

The Negotiation Agent monitors fare volatility across GDS platforms, NDC channels, and low-cost carrier APIs (not a popular view, but an accurate one). Unlike traditional scrapers that simply retrieve prices, this agent understands temporal pricing patterns. It knows that corporate routes on certain airlines show predictable fare drops 21 days before departure. It can hold virtual "conversations" with supplier APIs, making conditional offers based on volume commitments or flexible date ranges. I've observed implementations where negotiation agents reduced average ticket costs by 12-18% simply by timing purchases strategically and bundling requests.

The Policy Compliance Agent acts as the institutional memory of travel rules. Rather than presenting travellers with a PDF of guidelines, it interprets policy in real-time. When a traveller searches for a flight, this agent evaluates options against class restrictions, preferred supplier agreements, advance booking requirements, and sustainability targets. Critically, it can explain deviations. If someone books outside policy, the agent documents the rationale—perhaps the policy-compliant option required a 14-hour connection while the exception was direct. This contextual compliance logging transforms audit trails from adversarial to collaborative.

Is the investment worth it? In most cases, yes. The Approval Orchestration Agent manages the human-in-the-loop elements that still require judgment. It routes requests based on trip cost, traveller seniority, destination risk profiles, and current approval workload. I've seen these agents dramatically reduce approval latency by predicting which managers are likely to approve quickly and which requests need additional documentation upfront. The agent might automatically attach a business case template if the trip exceeds certain thresholds, or escalate to a backup approver if the primary contact is on leave.

The Disruption Management Agent is where agentic architecture truly shines. Flight cancellations cascade through an entire travel programme—missed connections, hotel check-ins, meeting schedules, car rentals. A traditional system sends alerts. An agentic system autonomously evaluates alternatives, books replacement flights within policy, notifies affected parties, and updates downstream reservations. During the summer 2023 European air traffic control outage, I watched a properly configured disruption agent rebook 47 affected travellers across six countries in under 90 minutes—a task that would have consumed days of human effort.

Multi-Agent Collaboration Patterns

The real power emerges when these agents collaborate through structured protocols. I design these systems around a message bus architecture where agents publish events and subscribe to relevant topics. When the Negotiation Agent identifies a fare opportunity, it publishes a "fare-alert" event. The Policy Agent subscribes to these alerts and evaluates compliance. If approved, it triggers the Approval Agent for human sign-off. Upon approval, the booking executes and the system publishes confirmation events that update expense forecasts and calendar systems.

This decoupled design prevents the monolithic brittleness of traditional booking tools. When a new policy requirement emerges—say, carbon emission caps per trip—you deploy a new Carbon Agent that subscribes to booking events and flags high-emission itineraries. You don't rewrite the entire workflow.

Consensus mechanisms become critical when agents disagree. Imagine the Negotiation Agent finds a fare 40% below policy maximum, but it requires a 6-hour layover. The Policy Agent flags the long connection as potentially fatiguing for the traveller. The Approval Agent notes the traveller is senior leadership. How do we resolve this?

I implement weighted voting systems where each agent scores options against its domain criteria. The final decision incorporates all perspectives, sometimes escalating to human judgment when scores are close. The key is transparency—the traveller sees why the system recommended option A over option B, building trust in autonomous decisions.

Large Language Models as Agent Reasoning Engines

Modern agentic systems leverage LLMs not as chatbots, but as reasoning engines within agent logic. The Approval Orchestration Agent, for instance, uses an LLM to parse unstructured justification text from travellers. When someone writes "need to meet Tokyo team re: Q4 product launch," the model extracts entities (Tokyo, Q4, product launch) and infers urgency and strategic importance.

This natural language understanding transforms rigid rule engines into adaptive systems. Instead of programming every approval scenario, you give the agent examples of approved and rejected trips with explanations. The LLM learns the implicit decision criteria—strategic value trumps cost for customer-facing trips, internal meetings require stronger justification for long-haul travel, etc.

I've also deployed LLMs for supplier negotiation dialogue. When an agent interacts with airline or hotel APIs that support conversational booking (increasingly common with NDC adoption), the LLM generates contextually appropriate requests. "Can you offer a lower rate for a 3-night stay next week given our company's annual spend with your brand?" This isn't scripted API calls—it's adaptive negotiation within guardrails.

The critical discipline is prompt engineering with constraints. I never deploy an LLM agent with open-ended instructions. Every prompt includes explicit boundaries: maximum spend thresholds, required approval levels, blacklisted suppliers, data privacy requirements. The model operates within these rails, using its reasoning capability to navigate complexity while honouring firm limits. Simple as that.

Real-Time Data Pipelines and Agent Intelligence

Agentic systems are only as good as the data they consume. I architect these platforms around streaming data pipelines that feed agents with real-time market intelligence. A Negotiation Agent monitoring GDS fares is useless if it's working from stale data pulled hourly. I use event-driven architectures where fare changes, inventory updates, and policy modifications flow immediately to relevant agents.

The data integration challenge is substantial. Corporate travel touches GDS systems, NDC connections, expense platforms, HR databases, calendar systems, and communication tools. I've standardised on a canonical data model approach where all incoming data maps to consistent schemas. When the Negotiation Agent sees a fare, it doesn't care whether it came from Amadeus, Sabre, or a direct airline connection—it's normalised into a standard Fare object with predictable attributes.

Historical pattern recognition elevates agent decision-making from reactive to predictive. My Disruption Management Agent doesn't just respond to cancellations—it anticipates them. By analysing historical data, it knows certain routes have 30% cancellation rates during winter months. When a traveller books one of these flights, the agent automatically identifies and monitors backup options, sometimes pre-positioning alternatives before disruption occurs.

This predictive capability extends to spend management. The system learns that certain departments consistently book last-minute travel in March (end of fiscal quarter), or that specific travellers habitually upgrade to business class. Finance teams receive early warnings about budget variances before they materialise, with agent-generated recommendations for intervention.

The Human-Agent Partnership Model

A common misconception is that agentic AI eliminates human involvement. In practice, I design these systems around progressive autonomy—agents handle routine scenarios independently while escalating edge cases and high-stakes decisions.

For a €200 domestic flight that fits policy perfectly, the agent books autonomously after approval. For a €8,000 last-minute international trip with policy exceptions, the agent prepares a detailed recommendation but waits for explicit human confirmation. The boundary between autonomous action and human oversight is configurable based on organisational risk tolerance.

I've found that travellers actually prefer this model. They don't want to micromanage routine bookings, but they do want control over unusual situations. The agent becomes a trusted assistant that handles tedious details while keeping humans in the loop for meaningful choices.

Explainability is non-negotiable. Every agent decision includes a reasoning trace—why this flight over that one, why this hotel was within budget, why the approval went to this manager. I implement this through structured logging where agents record their decision factors in human-readable formats. Auditors and travellers alike can trace any booking back through the agent logic that produced it.

Measuring Success in Agentic Travel Systems

The metrics for these systems extend beyond traditional automation KPIs. Yes, I track processing time and error rates, but the real value shows up in second-order effects.

Approval cycle time typically drops by 60-75% because agents route requests intelligently and prepare complete documentation upfront. Policy compliance rates improve by 20-30 percentage points because real-time guidance prevents non-compliant bookings rather than flagging them post-facto. Disruption resolution time decreases dramatically—what took hours of manual rebooking happens in minutes.

But I've also observed unexpected benefits. Travel satisfaction scores increase because agents handle the frustrating parts (searching dozens of options, chasing approvals, managing changes) while travellers make only the meaningful decisions. Finance team productivity improves as agents generate exception reports, trend analyses, and budget forecasts that previously required manual data wrangling.

The most compelling metric is decision quality. Agentic systems consistently find options that human bookers miss—the combination of three one-way fares that's cheaper than a round-trip, the hotel with corporate rates that isn't in the preferred supplier list but offers better value, the routing through a secondary hub that saves four hours of travel time. Agents can evaluate thousands of permutations that humans simply cannot process.

The Road Ahead

I believe we're still in the early innings of agentic AI for corporate travel. The current generation of systems handles well-defined workflows admirably, but the next evolution will involve agents that learn organisational preferences implicitly and negotiate across corporate boundaries.

Imagine a future where your company's Travel Agent collective negotiates directly with a supplier's Revenue Management Agent collective—autonomous systems finding mutually beneficial deals at scale without human intermediation for routine transactions. Or agents that learn individual traveller preferences so thoroughly they can book trips that feel personalised while remaining policy-compliant.

The technical foundations are in place. What's needed now is thoughtful implementation that respects the complexity of corporate travel, maintains appropriate human oversight, and builds systems that genuinely serve travellers rather than just enforcing policy. Done right, agentic AI transforms corporate travel from a necessary friction into a seamless enabler of business objectives.

My view is that this technology succeeds when it makes itself invisible—when travellers simply find themselves with the right flights booked, approvals flowing smoothly, and disruptions resolved before they notice. That's the promise of truly agentic systems: intelligence that works tirelessly in the background so humans can focus on the journey, not the logistics.

About Martin Tuncaydin

MLOps in Travel: From Notebook to Production in 30 Days

Martin Tuncaydin — Mon, 17 Aug 2026 09:01:10 +0000

I've spent the better part of two decades watching travel technology teams struggle with the same fundamental challenge: brilliant data science work that never makes it to production. A hotel ranking algorithm that performs beautifully in a Jupyter notebook but sits idle for months while engineering teams debate infrastructure. A personalisation model that could transform conversion rates, trapped in experimental limbo because nobody knows how to monitor it in the wild.

The gap between data science experimentation and production deployment has cost the travel industry countless opportunities (which surprised me, honestly). I've seen it firsthand across dozens of implementations—revenue management systems that could have captured millions in yield optimisation, search ranking improvements that would have lifted bookings by double digits, all delayed or abandoned because the path from notebook to production felt insurmountable.

The emergence of MLOps practices has changed this equation entirely. What once took six months of custom engineering can now be accomplished in thirty days with the right approach and tooling. I'm not talking about shortcuts or compromises—I mean genuinely production-grade machine learning systems that serve millions of requests, maintain model quality over time and adapt to changing travel patterns.

Let me walk you through how this transformation happens in practice, using a hotel ranking system as our example. This isn't theoretical—it's a pattern I've refined through multiple implementations across different travel verticals.

The Thirty-Day Framework

The key to rapid MLOps deployment isn't moving faster recklessly—it's eliminating the friction points that traditionally slow teams down. When I map out a thirty-day timeline for moving a hotel ranking model from notebook to production, I'm building on three core principles: experiment tracking from day one, feature engineering as a first-class concern, and deployment infrastructure that's standardised rather than custom-built.

Week one focuses entirely on establishing the experiment tracking foundation. I start every project by integrating MLflow into the data science workflow before a single line of model code is written. This feels counterintuitive to many teams—why add infrastructure overhead when you're still exploring the problem space? But I've learned that retrofitting experiment tracking after you've run dozens of model iterations is exponentially more painful than building it in from the start.

The hotel ranking use case makes this especially clear. A typical ranking model considers hundreds of features: property attributes, pricing signals, availability patterns, user preferences, seasonal demand indicators, competitive positioning, review sentiment, and countless derived features. Without systematic experiment tracking, you quickly lose track of which feature combinations drove which performance improvements. MLflow captures every experiment run, every hyperparameter configuration, every performance metric, and most importantly, the exact feature set and data version used for each run.

Week two is where feature engineering becomes the central focus. In travel, feature quality matters more than model complexity. I've seen simple gradient boosting models outperform elaborate neural architectures purely because the features captured the right business logic. The challenge is making those features reproducible and consistent between training and serving environments.

This is where feature stores enter the picture. I usually implement a lightweight feature store using either Feast or a custom solution built on top of existing data infrastructure. For hotel ranking, the feature store becomes the single source of truth for everything from basic property attributes to complex derived features like "7-day rolling average booking velocity" or "price position relative to compset."

The critical insight here is that features need to be computed identically whether you're training a model on historical data or scoring a live search request. Feature stores solve this by defining features as code—transformation logic that can be applied consistently across batch and real-time contexts. Without this consistency, you end up with training-serving skew, where your model performs brilliantly in backtesting but fails in production because the features don't match.

From Experiments to Deployable Models

Week three bridges the gap between experimentation and deployment readiness. This is where MLflow's model registry becomes invaluable. Every promising model variant gets registered with its full lineage: which experiment produced it, which features it depends on, which preprocessing steps it requires, and which performance metrics it achieved on holdout data.

For a hotel ranking system, I typically maintain multiple model variants in the registry simultaneously. There's usually a stable baseline model that's been serving production traffic reliably, one or more challenger models being evaluated through A/B tests, and several experimental variants being prepared for future deployment. The registry makes this complexity manageable by providing clear versioning, staging environments, and transition workflows.

Model packaging is where many teams stumble. I've seen data scientists deliver pickle files with verbal instructions about dependencies, leading to weeks of debugging when the model fails to load in production. MLflow eliminates this by packaging models with their complete environment specification—Python version, library dependencies, preprocessing code, and serving interface—all bundled together as a deployable artifact.

The hotel ranking model gets packaged as a self-contained unit that accepts a search request context (destination, dates, user profile, available inventory) and returns a scored, ranked list of properties. The packaging includes the feature transformation logic, the trained model weights, and the post-processing steps that convert raw scores into business-friendly rankings.

Production Deployment Architecture

Week four focuses on production deployment using Seldon Core as the serving infrastructure. I've evaluated numerous model serving frameworks over the years, and Seldon stands out for its Kubernetes-native architecture and support for complex deployment patterns that travel systems require.

The hotel ranking deployment needs to handle several challenging requirements simultaneously. First, there's the scale consideration—major travel searches can generate thousands of ranking requests per second during peak booking periods. Second, there's latency sensitivity—search results need to render in milliseconds, not seconds. Third, there's the need for sophisticated deployment strategies like canary releases and A/B testing at the request level.

Seldon addresses these through its microservices-based architecture. The ranking model runs as a containerised service that auto-scales based on traffic patterns. During peak booking windows, additional container instances spin up automatically. During quiet periods, resources scale down to minimise costs.

The real power emerges in Seldon's support for multi-armed bandit and A/B testing scenarios. For hotel ranking, I typically deploy new model versions as canary releases that initially receive only a small percentage of traffic. Seldon routes requests between model versions based on configurable rules, while collecting performance metrics from each variant. If the new model performs better on business metrics—click-through rate, booking conversion, revenue per search—traffic gradually shifts toward it. If it underperforms, the rollback is automatic and immediate.

Monitoring and Continuous Improvement

Production deployment isn't the finish line—it's the starting point for continuous improvement. The monitoring infrastructure I implement during the final days of the thirty-day cycle focuses on three categories of metrics: model performance, business impact, and data quality.

Model performance monitoring tracks the statistical behaviour of predictions. For hotel ranking, this means watching the distribution of prediction scores, the diversity of recommendations, and the stability of feature values over time. Significant drift in any of these signals often indicates underlying data quality issues or changing market dynamics that the model hasn't adapted to.

Business impact monitoring connects model behaviour to outcomes that matter: booking conversion rates, revenue per search, customer satisfaction scores, and competitive positioning metrics. I've learned that technical model metrics like AUC or NDCG are necessary but insufficient—what ultimately matters is whether the model drives better business results.

Data quality monitoring watches for the subtle degradation that happens in live systems. Feature values that were stable during training might exhibit different distributions in production. Upstream data pipelines might introduce latency or occasional null values. User behaviour patterns might shift due to external events like seasonality, economic changes, or competitive actions. The monitoring system needs to catch these issues before they degrade model performance.

The Continuous Learning Loop

The most sophisticated aspect of a production MLOps system is its ability to learn continuously from new data. I implement automated retraining pipelines that refresh the hotel ranking model as new booking patterns emerge, new properties join the inventory, and seasonal trends evolve.

The retraining pipeline pulls fresh training data from the feature store, launches a new MLflow experiment run with the updated dataset, evaluates the retrained model against current production performance, and registers successful candidates in the model registry for staged deployment. This entire cycle runs automatically on a schedule—typically weekly for hotel ranking, though the cadence varies by use case.

Human feedback loops are equally important. I instrument the production system to capture implicit signals like which hotels users click, which properties they book, and which search results lead to abandoned sessions. These signals flow back into the feature store and become training labels for future model iterations.

The result is a self-improving system where production deployment isn't a one-time event but an ongoing process of measurement, learning, and refinement. The thirty-day timeline gets you from notebook to initial production deployment, but the real value compounds over the months that follow as the system continuously learns from live traffic.

Why This Matters for Travel

Travel is uniquely suited to benefit from mature MLOps practices. The industry operates at massive scale with thin margins, where small improvements in conversion or yield optimisation translate to significant revenue impact. Travel data is inherently temporal and seasonal, requiring models that adapt continuously rather than remaining static. And travel systems need to balance multiple objectives simultaneously—relevance, diversity, pricing, availability, business rules—which benefits from the rapid experimentation that MLOps enables.

I've watched the industry's technical sophistication evolve dramatically over the past decade. The teams that embrace MLOps practices aren't just deploying models faster—they're fundamentally changing how they approach product development. Instead of debating requirements for months before building anything, they deploy minimal viable models quickly, measure real user response, and iterate based on evidence rather than opinions.

Can every team pull this off? Honestly, no. The thirty-day timeline I've outlined isn't aspirational—it's a proven pattern I've seen work across different organisations, different travel verticals, and different technical stacks. The specific tools might vary, but the principles remain consistent: systematic experiment tracking, feature stores for consistency, containerised deployment, comprehensive monitoring, and automated retraining.

My view is that MLOps maturity will become a key competitive differentiator in travel technology over the next several years. The companies that can deploy, measure, and improve machine learning systems rapidly will outpace competitors still treating model deployment as a heavyweight, infrequent event. The infrastructure and practices I've described aren't exotic anymore—they're increasingly table stakes for serious data-driven product development.

The real question isn't whether to adopt MLOps practices, but how quickly your organisation can make the transition. Thirty days from notebook to production is achievable, but only if you're willing to challenge the traditional boundaries between data science, engineering, and operations teams. The technical tools are ready. The question is whether the organisational will is there to use them.

About Martin Tuncaydin

Fine-Tuning Open-Source LLMs on Travel Domain Data: A Practitioner's Guide to LoRA Adapters

Martin Tuncaydin — Fri, 14 Aug 2026 09:01:11 +0000

Fine-Tuning Open-Source LLMs on Travel Domain Data: A Practitioner's Journey with LoRA Adapters

The travel technology landscape has always been data-rich but context-poor. I've spent years watching teams struggle to extract meaning from cryptic fare rules, arcane GDS command structures and the labyrinthine logic that governs airline pricing. When large language models emerged as a credible tool for domain-specific tasks, I knew we had an opportunity—but only if we could teach these models the peculiar language of travel commerce.

Generic foundation models like GPT-4 or Claude understand natural language beautifully, but ask them to interpret a SABRE cryptic entry or decode a fare basis code, and you'll quickly hit their limits. The answer isn't to wait for OpenAI to suddenly care about travel domain expertise. Instead, I've been exploring how open-source models—specifically Mistral and Llama variants—can be fine-tuned with travel-specific data using parameter-efficient techniques like Low-Rank Adaptation.

Why Open-Source Models Matter for Travel Technology

I've always been cautious about vendor lock-in, particularly when it comes to the intelligence layer of travel systems. Relying entirely on proprietary APIs means you're at the mercy of pricing changes, rate limits, and model deprecations. When OpenAI retired older GPT-3 variants, teams scrambled to rewrite integrations. I watched this happen in real time.

Open-source models like Mistral 7B, Llama 2, and their instruction-tuned variants offer a different path. You can deploy them on your own infrastructure, control versioning, and—most importantly for our purposes—fine-tune them on proprietary domain data without sending sensitive fare rules or booking patterns to a third party. For travel companies handling competitive pricing intelligence or negotiated corporate rates, this matters enormously.

The challenge, of course, is that base models trained on general internet text have virtually no understanding of GDS syntax, fare construction rules, or the semantic relationships between booking classes and cabin codes. This is where fine-tuning becomes essential—not optional.

Understanding LoRA: Efficient Adaptation Without Full Retraining

When I first experimented with fine-tuning language models, the resource requirements were prohibitive. Full fine-tuning of even a 7-billion-parameter model demands significant GPU memory and training time. For most travel technology teams, this simply isn't practical.

Low-Rank Adaptation changed this calculus entirely. Instead of updating all model parameters, LoRA introduces small trainable matrices that capture domain-specific adaptations. Think of it as teaching the model a new dialect rather than rebuilding its entire language faculty. I can fine-tune a Mistral 7B model on travel data using a single high-end GPU, and the resulting adapter file is often just a few hundred megabytes—tiny compared to the base model.

The technical elegance is in the decomposition. LoRA assumes that the weight updates needed for domain adaptation are low-rank, meaning they can be represented by much smaller matrices. In practice, I've found that rank values between 8 and 32 work well for travel domain tasks. The adapter matrices sit alongside the frozen base model, and during inference, their contributions are merged efficiently.

What this means practically: I can maintain one base Mistral or Llama model and swap in different LoRA adapters for different travel tasks—one for fare rule interpretation, another for GDS command generation, another for customer service automation. The modularity is powerful.

Building Training Datasets from Travel Domain Sources

The quality of fine-tuning depends entirely on the training data. I've learned this the hard way. Early experiments with scraped travel blog content produced models that could write fluently about destinations but completely failed at technical tasks. The model needs to see examples of the actual work you want it to perform.

For fare rule interpretation, I've built datasets from ATPCO fare filings, anonymised booking records with associated rules, and structured examples pairing cryptic fare basis codes with plain-language explanations. The format matters: I structure these as instruction-following examples where the input is a raw fare rule or GDS output, and the target is the structured interpretation or natural language summary.

GDS terminology presents a unique challenge because it's deliberately terse. A command like "WPRQ*CTY" in SABRE has specific meaning that isn't intuitive from the text alone. I've found that creating synthetic training examples—where I generate variations of GDS commands with different parameters—helps the model generalise better than relying solely on historical logs.

One approach that's worked particularly well: taking real fare rules and generating multiple paraphrases of the same constraint. If a rule states "Travel must commence within 24 hours of booking," I'll create variations: "Departure within one day of reservation," "Flight must begin same-day or next-day after ticketing," and so on. This teaches the model to recognise semantic equivalence despite different phrasings.

I'm careful about data balance too. If 80% of my training examples involve refundable fares, the model will develop a bias toward interpreting ambiguous cases as refundable. I've learned to stratify datasets across fare types, booking classes, and rule complexity levels.

Practical Implementation with Hugging Face and PEFT

The tooling ecosystem has matured remarkably. I rely heavily on Hugging Face's Transformers library for loading base models and PEFT (Parameter-Efficient Fine-Tuning) for implementing LoRA. The integration is clean enough that I can go from raw data to a fine-tuned adapter in a few hours of focused work.

My typical workflow starts with preparing the dataset in a conversational format—system prompts, user inputs, and assistant responses. For a fare rule task, the system prompt might establish the role: "You are a travel pricing specialist who interprets airline fare rules." The user input provides the raw rule text, and the assistant response gives the structured output.

I've experimented extensively with different base models. Mistral 7B Instruct has impressed me with its reasoning ability on complex fare logic. Llama 2 13B offers better performance but at the cost of inference speed. For production deployments where latency matters, I often prefer the smaller Mistral variant with a well-tuned adapter over a larger base model.

Training hyperparameters require careful attention. I usually use a learning rate around 2e-4, train for 3-5 epochs, and monitor validation loss closely. Overfitting is a real risk with smaller domain datasets—I've seen models memorise training examples rather than learning generalisable patterns. Early stopping based on validation performance is essential.

One subtle but important detail: I always include a diverse validation set that covers edge cases the model hasn't seen during training. Fare rules are full of exceptions and corner cases. If my training data only includes US domestic fares, the model will struggle with international fare construction. I've learned to explicitly include rare but important scenarios.

Real-World Applications and Observed Limitations

The models I've fine-tuned have proven genuinely useful in several contexts. I've deployed LoRA-adapted Mistral models for automated fare rule summarisation, where the input is a dense ATPCO filing and the output is a customer-friendly explanation of restrictions. The accuracy isn't perfect, but it's good enough to reduce manual review time significantly.

Another successful application: GDS command assistance. I fine-tuned a model to suggest SABRE or Amadeus commands based on natural language queries. An agent can type "check availability for London to New York next Tuesday" and get back the appropriate cryptic command structure. This bridges the gap between how people think and how legacy systems operate.

I've also seen these models excel at normalising inconsistent data. Travel content comes from hundreds of sources—airline websites, OTAs, GDS feeds—each with different formats and terminology. A fine-tuned model can standardise this into a consistent schema, recognising that "Economy Class," "Coach," and "Y Cabin" all refer to the same product tier.

But I'm realistic about limitations (and the data bears this out). These models still hallucinate, particularly when faced with ambiguous or incomplete information. I've seen a fare rule model confidently assert that a ticket is refundable when the actual rule requires a 50-dollar fee—subtle distinctions that matter enormously in practice. This is why I never deploy these models in a fully autonomous mode for customer-facing decisions. Human review remains essential.

Can every team pull this off? Honestly, no. The models also struggle with numerical reasoning. Calculating complex fare constructions involving currency conversion, percentage-based fees, and tiered pricing often produces errors. I treat the LLM as a semantic understanding layer, not a calculator. For numerical operations, I integrate with traditional rule engines.

The Path Forward: Hybrid Intelligence in Travel Systems

Looking ahead, I'm convinced the future isn't about replacing existing travel technology infrastructure with LLMs. It's about creating hybrid systems where language models handle the semantic, interpretive, and conversational layers while traditional systems maintain the transactional integrity and numerical precision.

Fine-tuned open-source models give us the flexibility to build this hybrid architecture without surrendering control to external API providers. I can iterate on adapters quickly, experiment with different prompt strategies, and deploy models that understand the specific nuances of my domain—whether that's corporate travel policy interpretation, loyalty programme rules, or ancillary product recommendations.

The tooling will continue to improve. I'm watching developments in quantisation techniques that make even 13B and 70B parameter models feasible on consumer hardware. Mixture-of-experts architectures promise better efficiency for multi-task scenarios. The ability to fine-tune models on my laptop today would have seemed impossible just two years ago.

I believe the real opportunity lies in making travel technology more accessible to non-technical users. GDS systems have remained arcane partly because the learning curve is so steep. If we can layer natural language interfaces—powered by domain-adapted models—over these systems, we democratise access to powerful capabilities that currently require months of training to use effectively.

My view is that every travel technology team should be building domain-specific datasets now, even if they're not yet fine-tuning models. The data infrastructure you create today—structured fare rules, annotated GDS commands, curated policy documents—becomes the training corpus for tomorrow's intelligent systems. This isn't a distant future; it's the immediate opportunity in front of us.

About Martin Tuncaydin

The Future of Personalization in Travel: AI-Powered Recommendations at Scale

Martin Tuncaydin — Wed, 12 Aug 2026 22:48:23 +0000

The Future of Personalization in Travel: Recommendations at Scale

I've spent years watching the travel industry grapple with a paradox: we have more data about traveller preferences than ever before, yet most platforms still serve generic results that ignore individual context. A business traveller searching for hotels in London sees the same recommendations as a family planning a summer holiday. The search results might be sorted differently, but the underlying intelligence—the ability to truly understand what this specific person wants right now—remains frustratingly absent.

The future of travel personalization isn't about better filters or smarter search algorithms. It's about fundamentally reimagining how we represent, store and serve recommendations at scale. I believe we're at an inflection point where vector embeddings, collaborative filtering, and real-time serving architectures are converging to make genuine personalization not just possible, but economically viable for platforms of any size.

Why Traditional Recommendation Systems Fall Short in Travel

Most travel platforms still rely on rule-based systems or simple collaborative filtering approaches borrowed from e-commerce. The assumption is straightforward: if users who booked Hotel A also booked Hotel B, then Hotel B is a good recommendation for anyone looking at Hotel A. This works reasonably well for products with stable attributes—books, electronics, clothing—but travel is fundamentally different.

Travel inventory is temporal, contextual, and highly dimensional. A hotel room isn't just a product; it's a product available on specific dates, at a specific price point, in a specific location, with amenities that matter differently to different people at different times. The business traveller who needs proximity to a conference centre this week might be planning a family beach holiday next month. Traditional collaborative filtering can't capture this nuance because it treats each interaction as independent, ignoring the rich context that makes travel decisions unique.

I've observed that the platforms making real progress are those treating personalization as a multi-dimensional matching problem rather than a simple similarity calculation. They're moving beyond "users who liked X also liked Y" toward "users with similar travel patterns, booking at similar times, with similar contextual needs, found value in these options."

Vector Embeddings: Representing Travel Intent in High-Dimensional Space

The breakthrough I find most promising is the application of vector embeddings to travel entities. Instead of representing a hotel as a row in a database with discrete attributes (star rating, location, amenities), we can represent it as a dense vector in high-dimensional space—usually 256, 512, or even 1,024 dimensions.

These embeddings capture latent relationships that traditional attributes miss. A boutique hotel in Shoreditch and a design-forward property in Brooklyn might be thousands of miles apart geographically, but in embedding space, they're neighbours because they attract similar travellers with similar preferences. The mathematics allows us to encode "vibe," "style," and "typical guest profile" in ways that structured data simply cannot.

I've seen implementations using tools like Pinecone, Weaviate, and Qdrant for vector storage and similarity search. And the key insight is that once you have quality embeddings, finding similar items becomes a nearest-neighbour search in vector space—an operation that can be performed in milliseconds even across millions of properties. The challenge isn't the search itself; it's generating embeddings that actually capture meaningful travel semantics.

The most effective approaches I've encountered combine multiple embedding strategies. Content-based embeddings derived from property descriptions, reviews, and images capture what a property is. Behavioural embeddings derived from booking patterns, search interactions, and session data capture what a property means to real travellers. User embeddings represent individual preferences and context. The magic happens when you combine these perspectives to match travellers with properties in ways that feel almost telepathic.

Collaborative Filtering in the Age of Deep Learning

Traditional collaborative filtering—matrix factorization, user-item interaction matrices—still has a place, but I'm increasingly convinced that deep learning approaches offer a step change in capability. Neural collaborative filtering, using architectures that can learn non-linear relationships between users and items, captures patterns that linear methods miss entirely.

What excites me most is the ability to incorporate side information directly into the recommendation model. A traditional matrix factorization approach treats each user-item interaction as a black box. A neural approach can consume the user's search history, their booking history, their demographic information, the current search context (dates, location, party composition), and real-time signals like time of day or device type—all as inputs to the same model.

I've worked with transformer-based architectures that treat a user's interaction history as a sequence, similar to how language models process sentences. The model learns that booking a beach resort in Thailand followed by a city break in Singapore suggests different intent than booking two consecutive beach resorts. Temporal patterns matter. The order of interactions matters. Context matters.

Tools like TensorFlow Recommenders and PyTorch-based frameworks make these sophisticated architectures accessible, but the real challenge is data engineering. You need high-quality, well-structured interaction data, and you need it in volumes large enough to train models that don't overfit. For smaller platforms, transfer learning—starting with embeddings or models pre-trained on larger datasets—offers a viable path forward.

Real-Time Serving: The Infrastructure Challenge

Even perfect recommendations are worthless if they take three seconds to load (this took longer than I expected to figure out). I've learned that the architecture for serving personalised recommendations is just as important as the models themselves. The travel booking funnel is unforgiving—users abandon searches in seconds, not minutes.

The serving challenge has two components: latency and freshness. Latency is about responding to a recommendation request in tens of milliseconds, not hundreds. Freshness is about ensuring recommendations reflect the most recent user behaviour and inventory changes.

I've seen successful implementations using a tiered architecture. Pre-computed candidate generation happens offline, using batch processing frameworks like Apache Spark or cloud-native batch services. This step might run hourly or daily, generating a broad set of candidate properties for each user segment. These candidates are stored in a fast key-value store—Redis, DynamoDB, or similar—indexed by user or session identifiers.

At request time, a lightweight ranking service retrieves candidates, applies real-time context (current search parameters, inventory availability, dynamic pricing), and scores them using a smaller, faster model optimised for inference. This two-stage approach—offline candidate generation plus online ranking—balances accuracy with performance.

Feature stores have become essential infrastructure in this architecture. Tools like Feast or Tecton provide a centralised repository for features used in both training and serving, ensuring consistency and reducing the complexity of maintaining multiple data pipelines. I cannot overstate how much operational overhead a well-implemented feature store eliminates.

The Cold Start Problem and Bootstrapping Intelligence

Every personalisation system faces the cold start problem: what do you recommend to a brand-new user with no history? And how do you recommend new properties that no one has booked yet?

I've found that hybrid approaches work best. For new users, fall back to content-based filtering using embeddings derived from property attributes and descriptions. If a user's first search is for "boutique hotels in Paris," you can serve properties that are semantically similar to that query even without behavioural data. As the user interacts—views properties, filters results, clicks through to details—you rapidly build a behavioural profile.

For new properties, the same principle applies in reverse. Use content-based embeddings to position new inventory in the same vector space as established properties. A new hotel with similar amenities, location attributes, and review sentiment to a popular property can inherit some of that property's collaborative signals until it builds its own booking history.

I'm particularly interested in meta-learning approaches that can learn to make good recommendations with minimal data. Few-shot learning techniques, borrowed from computer vision and natural language processing, show promise for travel applications where sparsity is inherent to the domain.

My View on What Comes Next

I believe the next frontier in travel personalization is contextual awareness that goes beyond historical preferences. The most sophisticated systems I'm tracking now incorporate real-time signals—weather forecasts, local events, flight delays, even social media sentiment—to adjust recommendations dynamically.

Imagine a scenario: a traveller's flight to Barcelona is delayed by six hours. The system doesn't just rebook the hotel; it recognises that the traveller now has an unexpected evening in their departure city and surfaces restaurant recommendations, entertainment options, or lounge access. It understands that context has changed and adjusts accordingly.

This level of intelligence requires moving beyond static embeddings and batch-processed models toward systems that continuously learn and adapt. Online learning, reinforcement learning, and multi-armed bandit approaches allow models to improve with every interaction, treating each recommendation as both a prediction and an experiment.

The infrastructure to support this is becoming mainstream. Stream processing frameworks like Apache Flink and Kafka Streams enable real-time feature computation. Model serving platforms like Seldon and KServe support dynamic model updates without downtime. Cloud-native architectures make it economically feasible to run sophisticated ML pipelines at scale.

What gives me confidence is that these technologies are no longer experimental. They're proven, productionised, and accessible. The barrier to entry for building world-class personalization has never been lower. The platforms that win will be those that combine technical sophistication with deep domain understanding—that recognise travel is not just transactions to optimise, but experiences to enhance.

I remain convinced that personalisation at scale isn't just a competitive advantage; it's rapidly becoming table stakes. Travellers have been trained by consumer internet platforms to expect experiences that feel custom-built. The travel industry can no longer hide behind complexity as an excuse for generic recommendations. The tools exist. The frameworks are proven. What's needed now is the will to implement them thoughtfully and the discipline to do it well.

About Martin Tuncaydin

AI-Driven Dynamic Pricing in Hotels: A Data Engineer's Deep Dive into Revenue Management Systems

Martin Tuncaydin — Fri, 22 May 2026 09:01:12 +0000

AI-Driven Dynamic Pricing in Hotels: A Data Engineer's Deep Dive

I've spent years building data pipelines for revenue management systems, and I can tell you this: dynamic pricing in hotels isn't just about algorithms—it's about engineering infrastructure that can process thousands of signals in milliseconds while maintaining pricing logic that won't alienate your guests.

The conversation around AI in hospitality often focuses on the glamorous end—machine learning models predicting demand, neural networks optimising room rates. But I've learned that the real challenge lies upstream: how do you engineer features that capture market dynamics in real-time? How do you serve predictions at scale without your infrastructure buckling during peak booking hours?

Let me walk you through what I've discovered building these systems from the ground up.

The Feature Engineering Challenge in Revenue Management

When I first approached dynamic pricing for hotels, I made the classic mistake of treating it like an academic ML problem. I thought: gather historical booking data, train a model, deploy it, done. Reality hit hard when I realised that hotel pricing operates in a fundamentally different context than e-commerce or ride-sharing.

A hotel room is a perishable inventory item with a fixed capacity constraint. Unlike an Uber ride where supply can theoretically expand, or an Amazon warehouse that can restock, a hotel has exactly N rooms on any given night. Once that night passes, unsold inventory vanishes. This creates a unique urgency in the pricing decision.

The feature engineering for this problem becomes an exercise in capturing market context across multiple temporal horizons simultaneously. I've found that effective revenue management systems need features that operate on at least four time scales:

Micro-level signals track real-time booking velocity—how many rooms have been booked in the last hour, the last four hours, the last day. These signals help detect sudden demand surges, perhaps from a concert announcement or a corporate event booking nearby.

Meso-level patterns capture weekly and monthly seasonality. I've built features that encode day-of-week effects, proximity to weekends, and monthly demand patterns. A Tuesday in January behaves very differently from a Friday in August, and your feature set needs to communicate this to the model.

Macro-level indicators bring in competitive intelligence and market-wide events. This is where I integrate data from rate shopping tools—systems that scrape competitor pricing across OTAs and direct booking channels. I've also engineered features around local events calendars, conference schedules, and even flight arrival data.

Historical context features provide the model with a sense of how this specific property performs over time. Occupancy rates from the same period last year, revenue per available room trends, and booking lead time distributions all inform the model's understanding of baseline demand.

The technical challenge here isn't just feature creation—it's feature freshness. I've architected systems using Apache Kafka and Flink to ensure that features update within seconds of new bookings arriving. When a competitor drops their rate by fifteen percent, your model needs to know within minutes, not hours.

Real-Time Inference Architecture at Scale

Serving ML predictions for pricing is where many well-intentioned systems fall apart. I've seen architectures that work perfectly in staging environments collapse under production load during peak booking windows.

The core problem is that pricing decisions need to happen synchronously. When a guest lands on your booking page, you have perhaps two hundred milliseconds to:

Fetch current inventory state
Pull the latest feature values from multiple data sources
Run inference through your pricing model
Apply business rules and constraints
Return a price to display

Two hundred milliseconds. That's your budget.

I've approached this by building a layered caching architecture that balances freshness with performance. At the base layer, I maintain a feature store—I usually use Redis or DynamoDB for this—that pre-computes and caches features that change infrequently. Room characteristics, property attributes, historical performance metrics—these get refreshed on a hourly or daily schedule.

The next layer handles semi-real-time features that update every few minutes: competitor pricing, local demand indicators, booking velocity metrics. I use a combination of streaming aggregations and scheduled jobs to keep these current.

For truly real-time signals—current inventory levels, bookings in the last hour—I fetch these directly from the operational database but with aggressive connection pooling and read replicas to avoid overwhelming the transactional system.

Model serving itself deserves careful consideration. I've deployed pricing models using TensorFlow Serving, but I've also had success with lighter-weight options like ONNX Runtime when model complexity allows. The key insight I've learned is that you don't always need the most sophisticated model architecture—a well-engineered gradient boosting model with the right features often outperforms a deep learning approach that takes three times longer to serve predictions.

I also implement circuit breakers and fallback logic extensively. If the ML service becomes unresponsive, the system falls back to rule-based pricing. If the feature store is stale, I degrade gracefully to using cached values with a clear signal to the monitoring system that data freshness has been compromised.

Handling Inventory Constraints and Business Rules

Here's something I wish I'd understood earlier: no hotel will ever let you deploy a purely algorithmic pricing system without guardrails. Nor should they.

I've built constraint layers that enforce minimum and maximum price boundaries, typically set as a percentage of the base rate. I've implemented logic that prevents sudden price jumps between consecutive dates—guests find it jarring when Monday is priced at two hundred pounds and Tuesday at three hundred fifty.

One of the more interesting challenges I've tackled is group booking protection (worth emphasising here). When a corporate client reserves a block of thirty rooms, your dynamic pricing system needs to understand that those rooms are now off-limits for the transient market. I've engineered features that distinguish between committed group inventory and rooms that are merely held under option.

Rate parity constraints add another layer of complexity. Many hotels have contractual obligations with OTAs that require maintaining specific rate relationships across channels. I've built systems that monitor these relationships in real-time and adjust pricing accordingly to avoid penalties.

The inventory optimisation piece becomes particularly nuanced when you factor in room types. A property might have standard rooms, deluxe rooms, and suites—each with different inventory levels and different demand curves. I've implemented recommendation engines that suggest upgrades when lower-tier inventory is constrained, dynamically adjusting the price differential to encourage guests to book the available room type.

Measuring Impact and Model Performance

Traditional ML metrics—RMSE, MAE, R-squared—tell you almost nothing about whether your pricing system is actually working. I've learned to focus on business metrics that matter to revenue managers.

Revenue per available room remains the gold standard. But I've also implemented A/B testing frameworks that compare algorithmic pricing against human-set rates on similar properties or during similar periods. The challenge here is that you can't run a true controlled experiment—you can't price the same room at two different rates simultaneously. Instead, I've used techniques like matched market tests, where I compare performance across similar properties or date ranges.

Booking conversion rates deserve careful monitoring. A model that maximises revenue by setting very high prices might actually damage long-term performance if it drives guests to competitors. I've built dashboards that track conversion rates by channel, by lead time, and by price point to ensure the model isn't optimising for short-term revenue at the expense of market share.

Forecast accuracy matters more than you'd think. Your pricing model implicitly makes demand forecasts—if it sets a high price, it's betting that demand will be strong. I've implemented feedback loops that compare predicted occupancy against actual outcomes, feeding this information back to retrain the model.

I also track business rule violations and overrides. When revenue managers manually override the algorithmic price, I log the reason and the outcome. This creates a valuable dataset for understanding model weaknesses and refining constraints.

The Human-in-the-Loop Reality

Despite all the sophisticated engineering, I've never seen a fully automated pricing system in production. Nor would I recommend one.

Revenue managers bring context that no feature engineering can fully capture. They know about the renovations starting next month, the VIP guest arriving on Tuesday, the negative review that went viral last week. I've built systems that make it easy for humans to intervene—to set temporary price floors or ceilings, to mark certain dates as requiring manual approval, to flag anomalies for review.

Does this mean avoiding AI entirely? Absolutely not. The most successful implementations I've seen treat the ML system as a decision support tool, not a replacement for human expertise. The algorithm suggests prices, provides confidence intervals, explains its reasoning through feature importance scores. The revenue manager reviews, adjusts, approves. No exceptions.

I've implemented audit trails that track every pricing decision—whether it came from the model, was overridden by a human, or fell back to rule-based logic due to a system issue. This transparency builds trust and provides the data needed for continuous improvement.

My View on the Future of Hotel Pricing

I believe we're still in the early stages of truly intelligent revenue management. The systems I've built are sophisticated by today's standards, but they're constrained by the features I can engineer and the data I can access.

The next frontier involves incorporating much richer contextual signals: social media sentiment, local economic indicators, weather forecasts, even satellite imagery of parking lot occupancy at nearby attractions. The challenge isn't just accessing this data—it's engineering it into features that models can actually use, and doing so with low enough latency to support real-time pricing.

I also see an opportunity to move beyond point-in-time predictions toward more sophisticated optimisation across multiple time horizons. Rather than pricing each night independently, future systems will optimise the entire booking curve—understanding how today's pricing decisions affect demand tomorrow and next week.

But the core principle I've learned remains: dynamic pricing in hotels is fundamentally an engineering problem, not just an algorithm problem. The best model in the world is worthless if it can't serve predictions in two hundred milliseconds, if it doesn't respect business constraints, or if revenue managers don't trust it enough to use it. That's where the real work lies—in building systems that are fast, reliable, explainable, and designed for humans to work with, not be replaced by.

About Martin Tuncaydin

Conversational AI in Online Travel Agencies: Beyond Traditional Chatbots

Martin Tuncaydin — Wed, 20 May 2026 09:01:01 +0000

Conversational AI in Online Travel Agencies — Beyond Chatbots

I've spent the better part of two decades watching travel technology evolve, and nothing has excited me quite like the shift we're seeing right now in conversational AI. For years, online travel agencies have deployed chatbots that amount to glorified FAQ systems — useful for checking baggage policies or finding a booking reference, but fundamentally limited in their ability to understand what travellers actually need.

The technology landscape has changed dramatically. Large language models with tool-calling capabilities are enabling a new generation of travel agents — not the scripted, button-driven interfaces we've grown accustomed to, but genuinely conversational systems that can orchestrate complex planning workflows. I'm not talking about incremental improvements to existing chatbots. I'm talking about a fundamental reimagining of how we help people discover, plan, and book travel experiences.

The Limits of Traditional Travel Chatbots

Most travel chatbots I encounter still operate on intent classification and slot-filling architectures. A user types "I want to go to Paris," the system recognises a destination entity, and it presents a search form or asks for dates. This works fine for straightforward queries, but it breaks down the moment someone asks something open-ended like "Where should I take my family for a week in March that's warm but not too touristy?"

I've tested dozens of these systems, and the pattern is always the same. They're built to route queries to predetermined flows, not to reason about travel as a problem space. They can't compare options across multiple dimensions, weigh trade-offs, or synthesise information from disparate sources. They're essentially interactive menus dressed up with natural language understanding.

The business impact of this limitation is significant. Conversion rates remain stubbornly low because users abandon the interaction when the bot can't help them think through their options. Customer service teams still field the same complex questions they always have, because the bot escalates anything that doesn't fit its narrow scripts. We've automated the easy queries and left the valuable, conversion-driving conversations to overwhelmed human agents.

Tool-Calling LLMs as Planning Engines

What's changed is the emergence of large language models that can reason about complex domains and invoke external tools to augment their capabilities. OpenAI's function calling, Anthropic's tool use, and similar capabilities from other providers have opened up a new architectural pattern for travel AI systems.

Instead of hardcoding decision trees, I can now build systems where the LLM acts as a planning engine. It understands the user's context — their constraints, preferences, previous travel history — and orchestrates a sequence of tool calls to search inventory, check availability, compare prices, retrieve reviews, and synthesise recommendations. The model reasons about which tools to call, in what order, and how to interpret the results in light of what the user has expressed.

I've built experimental systems using this architecture, and the difference is night and day. When someone asks about family-friendly destinations in March, the system can invoke weather APIs, search for destinations with appropriate climate, filter for family amenities, retrieve sentiment from review platforms, check flight availability and pricing, and present a curated set of options with genuine reasoning about why each might be suitable. It's not retrieving a pre-written answer. It's constructing a response based on real-time data and contextual understanding.

The technical stack for this looks fundamentally different from traditional chatbot platforms. I'm working with orchestration frameworks like LangChain and LlamaIndex that manage tool definitions, prompt engineering, and conversation state. I'm integrating with travel APIs — Amadeus, Sabre, Skyscanner — not just as data sources but as callable functions the model can invoke. I'm using vector databases like Pinecone and Weaviate to enable semantic search over unstructured travel content, reviews, and destination guides.

Multi-Step Journey Planning and Dynamic Itinerary Generation

The real power of tool-calling LLMs emerges when you tackle multi-step planning workflows. Trip planning isn't a single query; it's a conversation that unfolds over multiple interactions as preferences are refined and constraints are discovered. Traditional chatbots struggle here because they lack memory and reasoning capabilities across turns.

With modern LLM architectures, I can maintain conversation state and build up a rich understanding of what the user needs over time. Someone might start by asking about beach destinations, then mention they're travelling with elderly parents, then reveal a budget constraint, then ask about accessibility features. A tool-calling agent can incorporate each piece of information, re-evaluate previous suggestions, and adjust its recommendations accordingly.

I've prototyped systems that can generate complete itineraries by orchestrating multiple API calls and reasoning about temporal constraints, geographic proximity, and user preferences. The model might call a points-of-interest API to find attractions in a destination, retrieve opening hours and ratings, check travel times between locations using mapping APIs, and assemble a day-by-day plan that maximises the user's stated interests while respecting their available time and mobility constraints.

This goes beyond what any human agent could do at scale. The system can simultaneously evaluate hundreds of combinations, apply complex optimisation logic, and present options with transparent reasoning about trade-offs. It can explain why it's suggesting a particular hotel over another, not just based on price but on proximity to planned activities, neighbourhood characteristics, and alignment with stated preferences.

Personalisation Through Context and Memory

One of the most underutilised capabilities in travel AI is genuine personalisation. Most systems store booking history but don't leverage it to understand travel patterns, preferences, or life stage. Tool-calling LLMs with access to user context can operate at a different level entirely.

I'm particularly interested in systems that maintain long-term memory of user preferences — not just "likes beach destinations" but deeper insights about travel style, pace preferences, willingness to splurge on certain categories, dietary requirements, mobility considerations, and past satisfaction signals. With access to this context, an AI agent can make nuanced recommendations that feel genuinely personal.

The technical implementation requires careful design of context retrieval mechanisms. I use embedding models to encode past interactions and booking patterns into vector representations, then retrieve relevant context based on semantic similarity to the current conversation. This allows the system to surface pertinent information without overwhelming the model's context window with the user's entire history.

Privacy and consent are paramount here. I believe strongly that users must have transparent control over what data is retained and how it's used. The systems I design include explicit opt-in for personalisation features and clear mechanisms for users to view, modify, or delete their preference data. The goal is to build trust through transparency, not to obscure data practices behind complex interfaces.

Integration with Inventory and Operations Systems

For conversational AI to move beyond recommendation into actual transaction completion, it must integrate deeply with inventory management, pricing engines, and booking systems. This is where many experimental systems fall down — they can have great conversations but can't actually complete a purchase.

I've worked extensively on bridging this gap (easier said than done, of course). The architecture requires the LLM to invoke booking APIs with precise parameters, handle authentication and session management, validate user inputs against business rules, and manage error cases gracefully. It's not enough for the model to understand that the user wants to book a flight; it must translate that intent into exact API calls with correct parameters, handle availability changes, manage payment processing, and generate confirmations.

Does this mean avoiding AI entirely? Absolutely not. The challenge is that travel inventory systems are notoriously complex and fragmented. A single booking might require coordination across airline GDS systems, hotel property management systems, payment gateways, and loyalty programme APIs. The LLM-based agent needs to orchestrate this complexity while maintaining a natural conversational interface that shields the user from the underlying messiness.

I've found that hybrid architectures work best — using the LLM for natural language understanding and high-level planning, but delegating transaction execution to specialised services with robust error handling and business logic. The LLM acts as the intelligent orchestrator, but it doesn't directly execute critical operations like payment processing. This separation of concerns improves reliability and makes it easier to audit and test transactional logic independently.

The Road Ahead: Autonomous Travel Agents

I believe we're moving toward a future where conversational AI systems function as genuinely autonomous travel agents. These won't be reactive chatbots that wait for user queries. They'll be proactive systems that monitor user preferences, track pricing and availability, identify opportunities, and initiate conversations when they find compelling options. Simple as that.

Imagine a system that knows you usually travel to see family during school holidays, monitors flight prices to that destination, understands your booking patterns and budget constraints, and proactively notifies you when a particularly good deal emerges — not with a generic alert, but with a reasoned explanation of why this represents good value compared to historical patterns and alternative options.

The technical foundations for this exist today. We have the LLM capabilities, the tool-calling architectures, the API integrations, and the personalisation frameworks. What's missing is the careful design work to make these systems trustworthy, transparent, and genuinely useful rather than intrusive.

My view is that the online travel agencies that win in the next decade will be those that master this transition from transactional platforms to intelligent travel companions. The technology is ready. The question is whether the industry will embrace the architectural and cultural changes required to build AI systems that genuinely understand travel as a human experience, not just as an inventory management problem.

I'm optimistic. The conversations I'm having with industry leaders suggest a real appetite for this evolution. We're past the hype cycle of putting "AI-powered" labels on traditional chatbots. We're entering a phase of serious technical investment in systems that can reason, plan, and operate autonomously in complex domains. Travel is the perfect proving ground for this next generation of conversational AI, and I'm excited to be part of building it.

About Martin Tuncaydin

Agentic AI Workflows: The Next Evolution in Corporate Travel Management

Martin Tuncaydin — Mon, 18 May 2026 09:01:06 +0000

I've spent years watching corporate travel teams struggle with the same recurring problems: last-minute fare negotiations, bottlenecked approval chains and the chaos that ensues when a flight cancellation ripples through fifty travellers' itineraries (a pattern I keep running into). Traditional booking tools improved efficiency, but they never fundamentally changed the nature of the work—they just digitised manual processes.

What I'm observing now is different. We're entering an era where autonomous AI agents don't just assist travel managers; they actively negotiate, decide, and coordinate on their behalf. Multi-agent systems are beginning to handle the complex orchestration that corporate travel demands, and the implications for how we think about travel operations are profound.

Understanding Agentic AI in Travel Operations

When I talk about agentic AI, I'm referring to systems that can pursue goals with minimal human intervention. Unlike traditional automation that follows rigid if-then rules, these agents use large language models to interpret context, make judgements, and take action. They're not merely responding to queries—they're proactively managing workflows.

In corporate travel, this means an agent can understand that a traveller's flight delay will cascade into missed connections and hotel no-shows, then autonomously initiate rebooking, notify stakeholders, and adjust downstream reservations. The agent reasons about trade-offs, considers policy constraints, and makes decisions that would typically require human judgement.

Is this a new problem? Not really. The technical foundation here involves frameworks like LangChain and AutoGPT, which provide the scaffolding for agents to chain together multiple reasoning steps, call external APIs, and maintain state across complex workflows. I've seen implementations where agents use function calling to interact with GDS systems, expense platforms, and internal approval tools—all while maintaining a coherent understanding of the traveller's needs and the company's policies.

Multi-Agent Systems for Fare Negotiation

One of the most compelling applications I've encountered involves multi-agent negotiations. Traditional corporate travel procurement involves lengthy RFP processes and static contracts. What if, instead, you had an agent that could negotiate rates in real-time, leveraging current market conditions and your company's booking patterns?

I've been exploring architectures where one agent represents the buyer's interests—it knows your travel policy, budget constraints, and preferred suppliers. A second agent represents the supplier, armed with dynamic pricing models and inventory availability. These agents engage in structured negotiation protocols, making offers and counteroffers based on their respective objectives.

The buyer agent might say, "I can commit to twenty rooms over the next quarter if you offer a fifteen percent discount on your standard corporate rate." The supplier agent evaluates this against occupancy forecasts and margin requirements, then responds with a counteroffer. This happens in seconds, not weeks, and the negotiation adapts to real-time market signals.

I'm particularly interested in how these systems handle multi-party negotiations. For a large conference, you might have agents negotiating simultaneously with hotels, airlines, and ground transportation providers, coordinating to find the optimal combination that satisfies budget and logistical constraints. The agents communicate through structured protocols—often using JSON schemas to exchange proposals—and they can escalate to human decision-makers when negotiations reach impasse.

Automated Approval Workflows with Context-Aware Agents

Approval bottlenecks have always frustrated me. A traveller books a flight outside policy, and it sits in someone's inbox for days. Or a senior executive needs urgent travel, but the system treats it like any other request.

Agentic systems change this dynamic by understanding context and acting with appropriate autonomy. I've designed workflows where an agent evaluates a booking request against policy, risk factors, and business justification. If everything aligns with established parameters, the agent approves automatically. If there's an exception, it doesn't just flag it—it gathers relevant information, assesses urgency, and routes it to the appropriate decision-maker with a synthesised briefing.

For example, if a sales director books a last-minute flight to meet a major client, the agent recognises the opportunity value, checks the client's status in your CRM, and either auto-approves based on predefined rules or escalates with a recommendation. It might even proactively suggest alternative flights that balance urgency with cost, presenting options that a human approver can quickly accept or modify.

The key insight here is that agents don't just enforce rules—they interpret them. Using retrieval-augmented generation, an agent can reference your travel policy documents, past approval decisions, and business context to make nuanced judgements. I've seen systems where agents learn from approval patterns, gradually expanding their autonomous decision-making scope as they demonstrate reliability.

Disruption Management Through Coordinated Agent Networks

Flight disruptions are where the real complexity emerges. A storm cancels flights across a hub, affecting dozens of your travellers. Each one needs rebooking, hotel accommodations, ground transportation, and possibly expense adjustments. Manually coordinating this is a nightmare.

I've been working on multi-agent architectures specifically for disruption scenarios. Each affected traveller is assigned an agent that monitors their itinerary in real-time. When a disruption is detected, these agents don't wait for the traveller to call—they immediately begin exploring alternatives.

Here's where it gets interesting: these agents coordinate with each other. If five travellers were connecting through the same hub, their agents might collaborate to negotiate group rebooking or shared ground transportation. One agent might discover available seats on an alternative route and share that information with other agents managing travellers on similar itineraries.

The agents also coordinate with external systems. They call APIs from airlines, hotels, and TMCs to check availability, make tentative reservations, and even negotiate exception fares when standard inventory is exhausted. I've implemented systems where agents use tools like Amadeus APIs for flight data and OpenAI function calling to structure their interactions with these services.

What I find most valuable is the agents' ability to prioritise. They understand that a traveller heading to a board meeting needs immediate rebooking, while someone returning from a conference has more flexibility. They balance cost, convenience, and urgency without requiring explicit instructions for each scenario.

Implementation Considerations and Practical Constraints

I'd be misleading you if I suggested this is simple to implement. Building reliable agentic systems requires careful design around failure modes, security, and observability.

One challenge I consistently encounter is ensuring agents don't make decisions that violate hard constraints. I use a layered approach: agents operate with defined boundaries, and any action beyond those boundaries triggers human review. For example, an agent can rebook a flight up to a certain cost threshold, but exceeding that requires approval. This is implemented through guardrails—programmatic checks that validate agent actions before they're executed.

Observability is critical. When an agent makes a decision, I need to understand its reasoning. I've built systems that log every step of an agent's thought process, including which tools it called, what information it retrieved, and how it weighted different factors. This creates an audit trail that's essential for both debugging and compliance.

Security is another major consideration. Agents need access to sensitive systems—booking platforms, payment methods, personal traveller data. I implement strict access controls, ensuring agents operate with least-privilege principles. They can query data and make bookings, but they can't modify policies or access financial information beyond what's necessary for their specific tasks.

I also think carefully about when to use agents versus traditional automation. Not every task benefits from agentic approaches. Simple, repetitive processes with clear rules are better handled by conventional workflows. I reserve agentic systems for scenarios that require contextual reasoning, negotiation, or complex coordination.

The Human-Agent Collaboration Model

What excites me most is not the idea of agents replacing travel managers, but how they augment human capabilities. I envision a collaboration model where agents handle routine operations and escalate complex decisions with synthesised recommendations.

A travel manager's role shifts from executing tasks to setting strategic parameters, reviewing agent performance, and handling edge cases. The manager defines policies, approves new negotiation strategies, and intervenes when agents encounter scenarios they can't resolve. Meanwhile, agents handle the operational burden—monitoring itineraries, negotiating rates, managing disruptions, and ensuring compliance.

I've seen this play out in pilot implementations. Travel managers report that they spend less time on reactive firefighting and more time on strategic initiatives like supplier relationship management and policy optimisation. Travellers benefit from faster responses and more personalised service. And the organisation gains from better cost control and improved compliance.

The key is transparency. Travellers and managers need to understand what agents are doing and trust their decisions. I design interfaces that surface agent actions in digestible formats—notifications that explain why a booking was rerouted, dashboards that show negotiation outcomes, and audit logs that detail approval reasoning.

My Perspective on the Road Ahead

I believe we're at an inflection point. The technology for agentic AI in corporate travel is mature enough for production use, but the industry hasn't yet fully grasped the operational transformation it enables. Most organisations are still thinking about AI as a chatbot or a recommendation engine, not as an autonomous coordinator that can manage complex workflows end-to-end.

My view is that the winners in this space will be those who embrace a fundamentally different operating model. Instead of asking "How do we automate this task?" they'll ask "What goals can we give agents, and how do we design systems where agents collaborate to achieve them?" This requires rethinking processes from the ground up, not just layering AI onto existing workflows.

I'm particularly optimistic about the potential for agents to democratise sophisticated travel management capabilities. Today, only large enterprises with dedicated travel teams can effectively negotiate rates, manage disruptions, and enforce complex policies. Agentic systems could bring those capabilities to smaller organisations, levelling the playing field.

The challenges are real—technical complexity, change management, regulatory considerations. But the trajectory is clear. Multi-agent systems will become the standard architecture for corporate travel operations, just as reservation systems became standard decades ago. Those who invest now in understanding and implementing these systems will have a significant competitive advantage in the years ahead.

About Martin Tuncaydin

Applying RAG Architectures to Travel Knowledge Bases: A Practitioner's Guide

Martin Tuncaydin — Fri, 15 May 2026 09:01:08 +0000

Applying RAG Architectures to Travel Knowledge Bases: A Practitioner's View

The Challenge of Unstructured Travel Knowledge

I've spent years working with global distribution systems, fare rules databases, and destination content repositories. One pattern has become crystal clear: the travel industry sits on an enormous mountain of valuable knowledge that remains stubbornly inaccessible to most users who need it.

Traditional search interfaces fail spectacularly when someone asks "Can I use my frequent flyer miles on this codeshare flight?" or "What are the baggage rules for a multi-city itinerary touching three different airline alliances?" The information exists—buried in PDFs, encoded in cryptic fare basis codes, or scattered across multiple API endpoints—but retrieving and synthesising it requires either deep domain expertise or clicking through dozens of screens.

This is precisely where retrieval-augmented generation architectures shine. Rather than forcing users to navigate rigid menu structures or master complex query languages, RAG systems can understand natural language questions, locate relevant context from multiple sources, and generate coherent answers grounded in actual data.

I've come to view RAG not as a replacement for traditional search, but as a complementary layer that bridges the gap between how people naturally think about travel and how travel data is actually structured.

Why Travel Data Demands Retrieval Augmentation

The fundamental problem with applying large language models directly to travel queries is that they hallucinate. An LLM trained on general internet data might confidently tell you that a particular airline flies to a destination it hasn't served in five years, or invent plausible-sounding fare rules that don't actually exist.

Travel is a domain where accuracy isn't optional. Getting the wrong information about visa requirements, baggage allowances, or fare change penalties can cost real money and ruin trips. This is why I've become convinced that pure generative approaches without retrieval are fundamentally unsuited to travel applications.

RAG architectures solve this by grounding generation in retrieved documents. Instead of asking an LLM to answer from memory, we first search a curated knowledge base for relevant content, then ask the model to synthesise an answer using only that retrieved context. This dramatically reduces hallucination while maintaining the natural language interface that makes LLMs useful.

In my work with GDS content, I've found that the retrieval step is often more technically challenging than the generation step (not a popular view, but an accurate one). Travel data comes in wildly inconsistent formats—ATPCO fare rules use archaic category codes, IATA's NDC schemas are verbose XML, destination content might be in a CMS, and operational updates arrive via email. Building a unified retrieval layer over this heterogeneity requires serious data engineering.

Embedding Strategies for Multi-Modal Travel Content

The core technical challenge in any RAG system is creating effective embeddings—vector representations that capture semantic meaning in a way that makes similar concepts cluster together in embedding space.

For travel content, I've learned that a one-size-fits-all embedding approach doesn't work. Fare rules require different treatment than destination descriptions, which need different handling than flight schedules. Each content type has its own structure, vocabulary, and retrieval patterns.

When working with fare rules, I've found that chunking strategy matters enormously. A typical fare rule document might span dozens of pages, covering everything from advance purchase requirements to blackout dates. Embedding the entire document as a single vector loses granularity—you can't distinguish which sections are relevant to a specific query. But chunking too aggressively breaks the logical flow and loses context. Simple as that.

My preferred approach involves hierarchical chunking: creating embeddings at multiple levels of granularity and using metadata filters to narrow retrieval before semantic search. For example, I'll first filter by route and fare class using structured queries, then use vector similarity to find the specific rule sections relevant to the user's question.

For destination content, the challenge is different. Hotel descriptions, activity recommendations, and cultural information are more naturally suited to semantic search, but they need to be enriched with structured metadata about location, category, and seasonality. I've had success using hybrid retrieval that combines dense embeddings with sparse keyword matching, particularly for proper nouns and specific attraction names that might not be well-represented in embedding space.

Building Retrieval Pipelines Over GDS Data

Global distribution systems present unique architectural challenges for RAG implementations. GDS data is fundamentally transactional—it's designed for booking workflows, not knowledge retrieval. Availability, pricing, and rules are generated dynamically in response to specific queries rather than stored as static documents.

This means you can't simply crawl and embed GDS content the way you might index a documentation site. Instead, I've found success with a hybrid approach that combines cached reference data with real-time retrieval.

For relatively static content like airline policies, airport information, and general fare rules, I maintain an embedding database that's refreshed periodically. This provides fast retrieval for the majority of queries that don't require real-time pricing.

For dynamic content like availability and current fares, I've implemented a pattern where the RAG system first retrieves relevant cached context to understand the query, then makes targeted GDS API calls to fetch current data, and finally uses the LLM to synthesise cached and real-time information into a coherent response.

Does this mean avoiding AI entirely? Absolutely not. The key insight is that users rarely need real-time data for every aspect of their query. Someone asking "What's the best time to visit Tokyo?" doesn't need live flight prices—they need seasonal information, event calendars, and general budget guidance. But if they then ask "Show me flights for those dates," that's when you invoke the GDS.

This selective real-time retrieval keeps latency manageable while ensuring accuracy where it matters. I've measured median response times under two seconds for most queries, with real-time pricing queries taking three to five seconds—well within acceptable bounds for a conversational interface.

Evaluation and Quality Assurance in Travel RAG

The hardest part of deploying RAG systems in production isn't building them—it's proving they work reliably enough to trust with customer-facing queries.

Traditional information retrieval metrics like precision and recall are necessary but insufficient. A system might retrieve perfectly relevant documents but still generate a misleading answer due to subtle ambiguities in how fare rules are interpreted. I've seen cases where the retrieved context was technically correct, but the LLM synthesised it in a way that missed an important exception or edge case.

My evaluation approach involves multiple layers. First, I test retrieval quality independently using curated question-and-document pairs. For each test query, I verify that the top-K retrieved chunks contain the information needed to answer correctly. I track metrics like mean reciprocal rank and normalised discounted cumulative gain to quantify retrieval performance.

Second, I evaluate end-to-end answer quality using a combination of automated and human review. For automated evaluation, I use a stronger LLM as a judge, comparing generated answers against reference answers and scoring them on accuracy, completeness, and groundedness. This catches obvious hallucinations and omissions.

But automated evaluation only takes you so far. I maintain a programme of regular human review where travel domain experts assess a sample of real user queries and their generated responses. This has been invaluable for catching subtle errors that automated metrics miss—cases where an answer is technically accurate but misleading in context, or where the system misunderstands industry jargon.

One pattern I've observed is that failure modes tend to cluster. When the system gets something wrong, it's rarely an isolated incident—it usually indicates a systematic problem with how certain content is chunked, embedded, or retrieved. This makes targeted improvements possible once you identify the pattern.

The Path Forward: Agentic RAG and Multi-Step Reasoning

The RAG architectures I've described so far are relatively straightforward: retrieve relevant context, generate an answer, done. But I'm increasingly convinced that the future lies in more sophisticated agentic approaches that can reason across multiple retrieval steps and interact with structured data sources.

Consider a query like "I'm flying from London to Sydney via Singapore with a six-hour layover. Can I leave the airport, and what do I need to know?" Answering this properly requires retrieving information about visa requirements, airport facilities, luggage handling policies, and potentially real-time flight status to confirm the layover duration.

A single-shot RAG system struggles with this because it's really multiple queries bundled together. An agentic approach would break this down into sub-tasks, retrieve relevant information for each, potentially query structured databases for visa rules and flight status, and then synthesise everything into a coherent answer.

I've been experimenting with frameworks that allow RAG systems to plan retrieval strategies dynamically. Instead of retrieving once and generating an answer, these systems can iteratively refine their searches based on what they've found so far, similar to how a human travel agent might look up information in stages.

The technical challenge is controlling execution time and cost. Each additional retrieval step adds latency and LLM tokens. I've found that setting clear stopping criteria and using smaller, faster models for planning and routing helps keep performance acceptable.

My View on RAG as Infrastructure

I believe we're at an inflection point where RAG architectures will become standard infrastructure for any organisation that needs to make large knowledge bases accessible through natural language interfaces. The technology has matured beyond research prototypes into production-ready systems.

For the travel industry specifically, RAG offers a path to unlock decades of accumulated knowledge trapped in legacy formats and systems. The economic case is compelling: better self-service reduces support costs, improved information access drives conversion, and natural language interfaces lower the barrier to entry for complex products.

But success requires treating RAG as a data engineering challenge, not just an LLM integration. The retrieval pipeline is where most of the complexity lives. Getting chunking strategies right, building robust metadata enrichment, implementing hybrid search, and maintaining evaluation frameworks—these are the unglamorous but critical foundations.

I'm excited about where this technology is heading, but I'm also cautious about overpromising. RAG systems are probabilistic by nature. They'll never be 100% accurate, and that means designing appropriate guardrails, fallbacks, and human oversight. The goal isn't to replace human expertise but to make it more accessible and scalable.

The organisations that will succeed with RAG are those that view it as a long-term investment in knowledge infrastructure, not a quick chatbot implementation. It requires commitment to data quality, ongoing evaluation, and continuous improvement. But for those willing to put in that work, the potential to transform how people access and use travel information is genuinely transformative.

About Martin Tuncaydin

Building Travel Copilots with OpenAI's Assistants API: Function Calling and Persistent Threads

Martin Tuncaydin — Wed, 13 May 2026 09:01:14 +0000

Building Travel Copilots with OpenAI's Assistants API: A Practitioner's Guide to Function Calling and Persistent Threads

I've spent the last eighteen months working with travel technology teams who are trying to answer one deceptively simple question: how do we build AI assistants that actually help our agents close bookings faster? Not chatbots that frustrate users with canned responses, but genuine copilots that understand context, retrieve the right information and execute real actions.

The answer, I've found, lies in OpenAI's Assistants API—a framework that combines function calling, file search, and persistent conversation threads in ways that feel purpose-built for complex B2B workflows like travel agent desks. But this isn't about replacing human expertise. It's about augmenting it with tools that remember context, surface relevant policy documents, and automate the tedious lookups that consume hours of an agent's day.

Why Traditional Chatbots Fail in B2B Travel

I've watched dozens of travel companies deploy chatbots that follow the same pattern: they handle simple FAQs brilliantly, then collapse the moment a customer asks about group bookings with mixed cabin classes, or tries to modify a multi-leg itinerary with different fare rules per segment.

The problem isn't the underlying language model. GPT-4 can absolutely reason through complex travel scenarios. The problem is architecture. Most chatbots are stateless—they forget context between messages, can't access live inventory systems, and have no mechanism to retrieve internal policy documents that govern edge cases.

I remember sitting with a corporate travel team in Frankfurt who showed me their agent desktop. Each booking required checking five different systems: the GDS for availability, a PDF library for corporate travel policies, a CRM for traveller preferences, a separate tool for duty-of-care alerts, and a spreadsheet tracking unused tickets. Their agents were brilliant, but they spent more time switching contexts than actually serving customers.

This is where the Assistants API becomes transformative. It's designed around three capabilities that map perfectly to travel agent workflows: function calling to execute actions in external systems, file search to retrieve policy knowledge, and persistent threads that maintain conversation context across days or even weeks.

Function Calling: Turning Conversations into Actions

The breakthrough with function calling is that it lets language models decide when to stop generating text and start executing code. I describe it to clients as giving the AI a toolkit: instead of just talking about flight options, it can actually query availability, calculate fares, or check seat maps.

In a travel context, this means defining functions like search_flights, check_hotel_availability, retrieve_booking, or calculate_fare_rules. The model reads the conversation, determines which function to call, extracts the right parameters from natural language, and returns structured results.

What makes this powerful is that it's not rule-based. I don't have to anticipate every possible way an agent might phrase a request. If they say "show me morning flights from London to Dubai next Tuesday under £600 in business class", the model maps that to the right function parameters: origin LHR, destination DXB, date, price ceiling, cabin class.

I've built systems where a single assistant can orchestrate calls across a dozen different functions—checking availability, applying corporate discounts, validating traveller profiles, even generating PDF itineraries. The model decides the sequence, handles errors, and asks clarifying questions when parameters are ambiguous.

Does this mean avoiding AI entirely? Absolutely not. The key is designing functions that return rich context, not just raw data. Instead of returning a JSON blob of flight options, I return formatted text that includes not just price and times, but fare rules, baggage allowances, and refund policies. This lets the model weave that information into natural responses that agents can immediately relay to customers.

File Search: Making Policy Knowledge Instantly Accessible

Every travel organisation has a sprawling library of documents that govern how bookings should be handled: corporate travel policies, supplier agreements, fare rule PDFs, destination guides, duty-of-care protocols. Agents are expected to know all of this, but in reality they spend enormous time searching through folders or asking colleagues.

The Assistants API's file search capability solves this by creating a vector store—essentially a searchable index of all your documentation. You upload files in formats like PDF, Word, or Markdown, and the API automatically chunks them, generates embeddings, and makes them retrievable.

What I love about this approach is that it's not keyword search. When an agent asks "what's our policy on last-minute cancellations for executives?", the system retrieves relevant passages based on semantic meaning, not just matching the word "cancellation". It understands synonyms, context, and intent.

I recently worked with a team managing corporate travel for pharmaceutical companies. Their policies were Byzantine: different rules for clinical trial participants versus sales reps, special provisions for emergency medical travel, complex approval hierarchies. We uploaded their entire policy library—about two hundred documents—and suddenly agents could ask questions in plain language and get precise answers with citations.

The citations are crucial. The API doesn't just paraphrase policy; it tells you which document and which page it found the information on. This builds trust. Agents can verify answers and show customers the source material when needed.

I usually combine file search with function calling. An agent might ask about rebooking options for a delayed flight. The assistant searches policy documents to understand rebooking rules, then calls a function to check alternative flight availability, then synthesises both into a coherent recommendation. Full stop.

Persistent Threads: Context That Survives the Shift Change

This might be the most underrated feature for B2B workflows. In most chatbot architectures, each conversation is isolated. If an agent starts helping a customer, then needs to escalate or hand off to a colleague, all that context evaporates.

The Assistants API uses persistent threads—conversation histories that live beyond a single session. Each thread has a unique identifier. You can pause a conversation, come back hours later, and the assistant remembers everything: previous questions, retrieved documents, function calls, even the customer's preferences mentioned in passing.

I've seen this transform handoff workflows. An agent in London starts a complex booking for a group travelling to Singapore. They get partway through, then their shift ends. The next agent—maybe in a different time zone—opens the same thread and immediately sees the full context: who the travellers are, what's been discussed, which options were considered and rejected, what policies were consulted.

Threads also enable asynchronous workflows. An agent can ask the assistant to research something complex—"find all available options for getting twelve people from Paris to Tokyo during cherry blossom season, staying within budget, with specific dietary requirements"—then move on to other tasks while the assistant works through multiple function calls and file searches.

I structure threads hierarchically. The main thread tracks the overall booking journey. If an agent needs to deep-dive on a specific question—say, understanding visa requirements for a particular nationality—I create a sub-thread focused on that topic, then merge the insights back into the main conversation.

Designing the Agent Experience

The technology is powerful, but I've learned that success depends on how you design the interface. Agents don't want to type essays to an AI. They want quick answers, suggested actions, and the ability to override when the model gets it wrong.

I typically build a split-screen interface: the conversation thread on one side, and actionable widgets on the other. When the assistant finds flight options, it doesn't just describe them in text—it renders them in a structured table with "Book" buttons. When it retrieves a policy, it shows the relevant excerpt in a panel with a link to the full document.

I also give agents control over function execution. When the model suggests calling a function—say, creating a booking—I show the parameters it extracted and ask for confirmation before executing. This catches errors and builds trust.

Another pattern I use is proactive suggestions. The assistant monitors the conversation and surfaces relevant actions: "I noticed this is a last-minute booking—would you like me to check our emergency travel policy?" or "This route often has better fares if we include a connection—should I search those options?"

Real-World Constraints and Trade-Offs

I'd be misleading you if I said this was effortless to implement. There are real challenges I work through on every project.

Latency is the first. Function calling adds round-trips: the model generates a function call, your code executes it, then the model processes the result. For complex queries involving multiple functions, this can take ten or fifteen seconds. I mitigate this with streaming responses—showing partial answers as they're generated—and by designing functions that batch operations where possible.

Cost is another consideration. Each API call consumes tokens for the conversation history, file search results, and function definitions. For high-volume agent desks, this adds up. I've found the sweet spot is using GPT-4 for complex reasoning and decision-making, but offloading simple lookups to direct database queries or cheaper models.

Accuracy requires constant tuning. The model sometimes hallucinates function parameters or retrieves irrelevant documents. I address this with detailed function descriptions, few-shot examples in the system prompt, and validation logic that catches impossible parameters before execution.

Integration complexity is the biggest hurdle. Travel systems are notoriously fragmented—GDS platforms, inventory APIs, CRM systems, payment gateways. Each has its own authentication, data format, and quirks. Building robust function adapters that handle errors gracefully is where I spend most of my implementation time.

The Future I'm Building Toward

I believe we're at the beginning of a fundamental shift in how B2B software works. The traditional model—specialised applications with rigid workflows—is giving way to conversational interfaces that adapt to how people actually think and work.

In travel specifically, I'm seeing assistants evolve from tools that answer questions to true copilots that anticipate needs. Imagine an assistant that notices a pattern—this corporate client always books window seats, prefers afternoon flights, has a shellfish allergy—and proactively applies those preferences to new bookings without being asked.

I'm also excited about multi-agent systems: specialised assistants that collaborate. One focuses on flights, another on hotels, a third on ground transportation. They coordinate through a master orchestrator that ensures the full itinerary makes sense as a whole.

My view is that the most successful implementations won't be the ones with the fanciest AI. They'll be the ones that deeply understand agent workflows, integrate cleanly with existing systems, and earn trust through consistent accuracy and transparency. The technology is ready. The question is whether we're ready to rethink how we design software for the people who use it every day.

Tags: openai, travel-tech, ai-agents, assistants-api, conversational-ai