\n
![](\"https:\/\/images.ctfassets.net\/jdtwqhzvc2n1\/2t04hE5kMFifED9FQ12PcA\/86ec4e3895472b25edb77273488d1c7a\/Booking.png?w=300&q=30\")
<\/p>\n
\n<\/p>\n
When many enterprises weren\u2019t even thinking about agentic behaviors or infrastructures, Booking.com had already \u201cstumbled\u201d into them with its homegrown conversational recommendation system. <\/p>\n
This early experimentation has allowed the company to take a step back and avoid getting swept up in the frantic AI agent hype. Instead, it is taking a disciplined, layered, modular approach to model development: small, travel-specific models for cheap, fast inference; larger large language models (LLMs) for reasoning and understanding; and domain-tuned evaluations built in-house when precision is critical. <\/p>\n
With this hybrid strategy \u2014 combined with selective collaboration with OpenAI \u2014 Booking.com has seen accuracy double across key retrieval, ranking and customer-interaction tasks.<\/p>\n
As Pranav Pathak, Booking.com\u2019s AI product development lead, posed to VentureBeat in a new podcast: \u201cDo you build it very, very specialized and bespoke and then have an army of a hundred agents? Or do you keep it general enough and have five agents that are good at generalized tasks, but then you have to orchestrate a lot around them? That's a balance that I think we're still trying to figure out, as is the rest of the industry.\u201d<\/p>\n
Check out the new Beyond the Pilot<\/i> podcast here, and continue reading for highlights. <\/p>\nMoving from guessing to deep personalization without being \u2018creepy\u2019<\/h3>\n
Recommendation systems are core to Booking.com\u2019s customer-facing platforms; however, traditional recommendation tools have been less about recommendation and more about guessing, Pathak conceded. So, from the start, he and his team vowed to avoid generic tools: As he put it, the price and recommendation should be based on customer context. <\/p>\n
Booking.com\u2019s initial pre-gen AI tooling for intent and topic detection was a small language model, what Pathak described as \u201cthe scale and size of BERT.\u201d The model ingested the customer\u2019s inputs around their problem to determine whether it could be solved through self-service or bumped to a human agent. <\/p>\n
\u201cWe started with an architecture of \u2018you have to call a tool if this is the intent you detect and this is how you've parsed the structure,\u201d Pathak explained. \u201cThat was very, very similar to the first few agentic architectures that came out in terms of reason and defining a tool call.\u201d <\/p>\n
His team has since built out that architecture to include an LLM orchestrator that classifies queries, triggers retrieval-augmented generation (RAG) and calls APIs or smaller, specialized language models. \u201cWe've been able to scale that system quite well because it was so close in architecture that, with a few tweaks, we now have a full agentic stack,\u201d said Pathak. <\/p>\n
As a result, Booking.com is seeing a 2X increase in topic detection, which in turn is freeing up human agents\u2019 bandwidth by 1.5 to 1.7X. More topics, even complicated ones previously identified as \u2018other\u2019 and requiring escalation, are being automated. <\/p>\n
Ultimately, this supports more self-service, freeing human agents to focus on customers with uniquely-specific problems that the platform doesn\u2019t have a dedicated tool flow for \u2014 say, a family that is unable to access its hotel room at 2 a.m. when the front desk is closed. <\/p>\n
That not only \u201creally starts to compound,\u201d but has a direct, long-term impact on customer retention, Pathak noted. \u201cOne of the things we've seen is, the better we are at customer service, the more loyal our customers are.\u201d<\/p>\n
Another recent rollout is personalized filtering. Booking.com has between 200 and 250 search filters on its website \u2014 an unrealistic amount for any human to sift through, Pathak pointed out. So, his team introduced a free text box that users can type into to immediately receive tailored filters. <\/p>\n
\u201cThat becomes such an important cue for personalization in terms of what you're looking for in your own words rather than a clickstream,\u201d said Pathak. <\/p>\n
In turn, it cues Booking.com into what customers actually want. For instance, hot tubs \u2014 when filter personalization first rolled out, jacuzzi\u2019s were one of the most popular requests. That wasn\u2019t even a consideration previously; there wasn\u2019t even a filter. Now that filter is live. <\/p>\n
\u201cI had no idea,\u201d Pathak noted. \u201cI had never searched for a hot tub in my room honestly.\u201d<\/p>\n
When it comes to personalization, though, there is a fine line; memory remains complicated, Pathak emphasized. While it\u2019s important to have long-term memories and evolving threads with customers \u2014 retaining information like their typical budgets, preferred hotel star ratings or whether they need disability access \u2014 it must be on their terms and protective of their privacy. <\/p>\n
Booking.com is extremely mindful with memory, seeking consent so as to not be \u201ccreepy\u201d when collecting customer information. <\/p>\n
\u201cManaging memory is much harder than actually building memory,\u201d said Pathak. \u201cThe tech is out there, we have the technical chops to build it. We want to make sure we don't launch a memory object that doesn't respect customer consent, that doesn't feel very natural.\u201d<\/p>\n
\nAs agents mature, Booking.com is navigating a central question facing the entire industry: How narrow should agents become? <\/p>\n
Instead of committing to either a swarm of highly specialized agents or a few generalized ones, the company aims for reversible decisions and avoids \u201cone-way doors\u201d that lock its architecture into long-term, costly paths. Pathak\u2019s strategy is: Generalize where possible, specialize where necessary and keep agent design flexible to help ensure resiliency. <\/p>\n
Pathak and his team are \u201cvery mindful\u201d of use cases, evaluating where to build more generalized, reusable agents or more task-specific ones. They strive to use the smallest model possible, with the highest level of accuracy and output quality, for each use case. Whatever can be generalized is. <\/p>\n
Latency is another important consideration. When factual accuracy and avoiding hallucinations is paramount, his team will use a larger, much slower model; but with search and recommendations, user expectations set speed. (Pathak noted: \u201cNo one\u2019s patient.\u201d)<\/p>\n
\u201cWe would, for example, never use something as heavy as GPT-5 for just topic detection or for entity extraction,\u201d he said. <\/p>\n
Booking.com takes a similarly elastic tack when it comes to monitoring and evaluations: If it's general-purpose monitoring that someone else is better at building and has horizontal capability, they\u2019ll buy it. But if it\u2019s instances where brand guidelines must be enforced, they\u2019ll build their own evals. <\/p>\n
Ultimately, Booking.com has leaned into being \u201csuper anticipatory,\u201d agile and flexible. \u201cAt this point with everything that's happening with AI, we are a little bit averse to walking through one way doors,\u201d said Pathak. \u201cWe want as many of our decisions to be reversible as possible. We don't want to get locked into a decision that we cannot reverse two years from now.\u201d<\/p>\n
Booking.com\u2019s AI journey can serve as an important blueprint for other enterprises. <\/p>\n
Looking back, Pathak acknowledged that they started out with a \u201cpretty complicated\u201d tech stack. They\u2019re now in a good place with that, \u201cbut we probably could have started something much simpler and seen how customers interacted with it.\u201d<\/p>\n
Given that, he offered this valuable advice: If you\u2019re just starting out with LLMs or agents, out-of-the-box APIs will do just fine. \u201cThere's enough customization with APIs that you can already get a lot of leverage before you decide you want to go do more.\u201d <\/p>\n
On the other hand, if a use case requires customization not available through a standard API call, that makes a case for in-house tools. <\/p>\n
Still, he emphasized: Don't start with the complicated stuff. Tackle the \u201csimplest, most painful problem you can find and the simplest, most obvious solution to that.\u201d <\/p>\n
Identify the product market fit, then investigate the ecosystems, he advised \u2014 but don\u2019t just rip out old infrastructures because a new use case demands something specific (like moving an entire cloud strategy from AWS to Azure just to use the OpenAI endpoint). <\/p>\n
Ultimately: \u201cDon't lock yourself in too early,\u201d Pathak noted. \u201cDon't make decisions that are one-way doors until you are very confident that that's the solution that you want to go with.\u201d<\/p>\n