The standard approach to travel search is a retrieval problem: given a query, return ranked results. Price ascending. Stars descending. Filter by airline. It works well enough for one-dimensional decisions. Travel is not one-dimensional.

From the beginning we knew we needed a model that could hold multiple constraints simultaneously — budget, timing, destination quality, layover count, hotel proximity — and reason about the tradeoffs between them. Not a ranker. A planner.

We built on top of a fine-tuned language model that takes a structured traveller profile alongside a live inventory snapshot. The profile captures both explicit preferences (max layover: 90 minutes) and inferred ones (the user consistently picks 4-star hotels when budget allows). The model's job is to reconcile these against what's actually available.

One early challenge was latency. Reasoning takes more compute than sorting. Our first prototype was unusable — 8 to 12 seconds to return results. We reduced this to under 1.8 seconds by separating the retrieval and reasoning passes: a fast retrieval layer narrows the candidate set to 40-60 options, then the reasoning model scores and explains just those candidates.

The explanation layer was the last piece. We didn't want users to feel like they were receiving oracle pronouncements. Every result card in Roavo shows a one-line rationale generated by the model: 'This flight avoids your typical layover at JFK and arrives before your meeting.' It sounds small. In testing it made a significant difference to trust and conversion.

There is still a lot of work ahead on the model side — multi-city itinerary reasoning, group travel, and long-horizon trip planning are all on the roadmap. But the core architecture is solid, and we expect to iterate quickly once early users start putting it to work.