Airbnb wants search to feel like a conversation. That’s a bigger engineering shift than it sounds.

Airbnb is pushing AI into the parts of its product that matter most: search, discovery, customer support, and internal engineering. On its Q4 2025 earnings call, CEO Brian Chesky said the company wants to become “AI-native.” Unlike a lot of earnings-call AI talk, this comes with real product signals.

The short version: Airbnb is testing natural-language search for listings, its LLM-based support bot already resolves about 33% of customer support tickets in North America, and it plans to expand that with voice and more languages. It’s also thinking about where sponsored listings fit inside conversational search, which is where the business logic starts colliding with product trust.

This is worth watching because Airbnb has something many AI products lack: dense first-party data tied to clear intent. Listings, availability, host rules, reviews, identity data, preferences, trip history. That’s a solid base for an assistant that can actually help, instead of turning filters into chat bubbles.

Why this matters now

Travel search is full of messy, multi-constraint queries. People don’t think in database fields. They say things like:

“I need a dog-friendly place near a trail, quiet at night, under $180, with parking, and no weird cleaning fee.”

Classic filters can handle parts of that. Then they fall apart. “Quiet” lives in reviews. “Near a trail” needs location context. “No weird cleaning fee” is partly pricing logic and partly human judgment. That’s where a conversational interface can do better, assuming it’s grounded in real data.

Support is the other big reason to push here. A marketplace at Airbnb’s scale generates endless policy-heavy cases around cancellations, refunds, date changes, guest counts, fees, and local rules. If an AI support system can safely resolve a third of those tickets already, that’s a meaningful operational result. Chesky said he wants that number well above 30% over the next year.

That only matters if the bot is actually finishing the job. Plenty of support bots are good at sounding helpful while doing very little.

What the system probably looks like

Airbnb hasn’t published the full design, but the shape of it is fairly obvious.

A plain chat model won’t work here. Listing search needs live availability, real prices, date-aware constraints, and policy checks. The likely setup is retrieval-heavy, with tool use, policy enforcement, and ranking systems doing most of the hard work.

Retrieval first

Queries like “walkable to coffee shops” or “quiet neighborhood” don’t map cleanly to keywords. You need embeddings across listing descriptions, reviews, host rules, maybe neighborhood summaries and image metadata. That gives you semantic recall for traits users care about but hosts describe inconsistently.

A practical stack probably includes:

• structured filters for hard constraints like dates, guest count, bedrooms, and pet policy
• BM25 or similar lexical retrieval for exact matches
• vector search over listing and review embeddings for fuzzier traits
• a learned re-ranker to combine everything into a final list

That hybrid setup is standard for a reason. Pure vector search still misses obvious exact matches. Pure keyword search is brittle. The re-ranker is where Airbnb can lean on its own signals: past bookings, saves, clicks, conversion history, cancellations, and review quality.

Retrieval quality matters more than model size here. If the candidate set is weak, the chat layer just wraps bad options in polished prose.

Tool use has to be built in

Any travel assistant that’s actually useful has to call live systems. Availability changes constantly. Fees change. Cancellation terms vary. Travel times depend on route and time of day. A model answering from memory would be a mess.

So expect a tool-routing layer that can hit:

• pricing and availability APIs
• policy engines for cancellation rules, occupancy limits, tax disclosures, and host restrictions
• geospatial services for “10 minutes from downtown” or “near transit”
• possibly trust and safety systems for fraud and abuse checks

This is where function calling matters. The model interprets intent, decides which systems it needs, and builds a response from current data instead of inventing facts. If Airbnb gets this right, the user sees a clean conversational result with some kind of verification cues attached to pricing, rules, or host details.

That matters. Conversational commerce only works if users can tell the system is pulling from live, checkable data.

Support is harder, and more interesting

Search gets more attention because users see it. Support is where the engineering gets stricter.

Airbnb says its LLM-powered support bot resolves around 33% of tickets without human help in North America. That’s a strong number if “resolves” means completed outcomes rather than “the user gave up.” At marketplace scale, even moderate automation shifts staffing, escalation paths, and cost structure.

Voice support is the obvious next step, but it raises the bar quickly.

A decent voice stack needs:

• fast ASR transcription
• intent extraction with low error rates on messy spoken input
• the same retrieval and tool-use core behind chat
• TTS that’s clear enough for customer service
• support for interruption, retries, and handoff

Latency matters a lot more on voice than text. Users will wait a bit for chat. Dead air on a phone line feels broken almost immediately. If Airbnb wants voice to feel usable, it probably needs sub-500ms turn latency for basic interactions and graceful fallbacks when tool calls take longer.

Then there’s compliance. Refunds, emergency rebookings, accessibility requests, discrimination complaints, and local legal obligations are support issues, but they’re also risk issues. The model can’t be the final authority. A policy layer has to sit between the model and any action.

That part needs to live in code. Prompting won’t carry it.

Airbnb does have a real data edge

A lot of companies say they’re adding AI to search. Many of them are just stapling a chat box onto a weak backend.

Airbnb actually has the ingredients for a strong vertical AI product. Its data graph is unusually rich:

• identity and profile data
• listing metadata
• host rules
• review text
• pricing and calendar state
• saved listings
• booking history
• support interactions

That makes personalization possible without leaning too heavily on generic LLM priors. A user embedding based on past searches and stays can improve ranking. Review embeddings can capture softer traits like “good for remote work” or “quiet after 10 p.m.” A collaborative filtering model can narrow the candidate pool before an LLM starts asking follow-up questions.

There’s a limit, though. Personalization gets creepy fast when the system sounds too certain about private preferences. The good version helps narrow options. The bad version feels invasive.

Travel is also a punishing domain for mistakes. A bad movie recommendation wastes an evening. A bad lodging recommendation can wreck a trip.

Sponsored listings will test trust fast

Airbnb says it’s considering sponsored listings in conversational search, but only after it gets the experience right. Fair answer. Also the easy answer.

Ads inside chat are harder than ads inside a standard results page. In a list, users understand placement and ranking cues. In a conversation, the assistant sounds authoritative by default. If paid placement gets blended too casually into recommendations, users will read that as judgment rather than advertising.

That creates product and ranking problems at the same time.

The system will need clear disclosure, hard separation between organic and sponsored slots, and relevance controls tight enough that the chat still feels useful. A multi-objective ranker can balance ad revenue with booking likelihood, cancellations, satisfaction, and downstream trust metrics. But once monetization enters the loop, recommendation quality usually gets squeezed. That’s how these systems tend to go.

Teams building similar products should pay attention to that. Conversational interfaces compress UI space and blur intent. Ad labeling becomes a product requirement, not a legal footnote.

Internal AI use matters too

Airbnb’s CTO Ahmad Al-Dahle came from Meta’s Llama effort, and Chesky said 80% of Airbnb engineers already use AI tools internally, with a target of 100%.

Part of that is cultural signaling. Part of it matters.

When a company says all engineers should use AI, it usually points to a few practical changes:

• code generation becomes part of the default workflow
• internal docs and APIs need to be machine-readable
• evals matter more because generated code fails in repetitive ways
• security review gets harder when more code is produced faster

The useful measure here isn’t “AI adoption rate.” It’s bug density, review load, time to ship, test coverage, and incident rates. If Airbnb is serious, it’ll need much better observability around both developer tooling and customer-facing models.

What to take from it

If you’re building conversational search or support, Airbnb’s direction reinforces a few basics.

Data quality beats model flash. Missing metadata, stale calendars, weak policy encoding, and sloppy review parsing will wreck relevance long before you hit frontier-model limits.

Treat the LLM as planner and interface, not source of truth. Facts should come from tools. Constraints should come from code. Trust depends on grounded output.

Evaluation has to go beyond generic chatbot scores. You want ranking metrics like NDCG, groundedness checks, task completion rates, escalation rates, refund accuracy, and region-specific policy compliance. Then you need live experiments to catch the failures your offline set missed.

And cost still matters. At Airbnb traffic levels, inference spend can get ugly fast. The sensible setup is tiered serving: small models for intent classification and routing, larger ones for harder synthesis, aggressive caching, and probably some distillation for narrow tasks.

Airbnb’s AI push looks credible because it lines up with real product pain instead of investor fashion. That only gets it to the starting line. Search has to return places people actually want to book. Support has to solve cases without creating new ones. And if chat starts nudging users toward sponsored listings in ways that feel slippery, people will notice fast.