strait
All posts

What AI native infrastructure means at strait

Four pillars: natural language integrated vertically through the stack, a lossless bidirectional protocol between personal AI and hotel AI, data shaped for LLM trust and rigor, and infrastructure that survives AI-agent look-to-book economics. Strait is being built to solve this.

Omar Moussa ·

“AI native” infrastructure is a term that gets used a lot. For most, that term just means bolting an MCP server to their web 2.0 REST API. At strait, we go four levels deeper.

1. Natural language integrated vertically into the entire stack

Most travel infrastructure was built for humans clicking through forms and developers working with rigid schemas. AI trip planners building on top of this become thin LLM wrappers around old infrastructure. The rich user preferences and constraints captured in the LLM’s context get dropped at the tool boundary.

That matters because the whole point of an AI trip planner is acting on rich context. If that context dies at the first API call, the agent is just a search bot.

So we’re building strait to treat natural language as a first-class data type, propagated through the entire stack.

This means an LLM searching, pricing, and booking hotels through strait will be able to pass a rich, unstructured context to the tools and APIs it calls. This is important for semantic search (find hotels by vibe), aggregating by intent to surface inventory and functionality gaps, and writing guest preferences directly into the hotel PMS for a human or AI agent to act on.

Structured filters remain extremely important and necessary.

2. A lossless, bidirectional protocol between personal AI and hotel AI

There is no live channel between a traveler’s agent and a hotel today, and that absence is where the value gets stuck. The OTAs are catalogs and checkout flows. Once a reservation is made, the hotel and the guest are on their own. Email and phone calls exist, but they were built for humans, not for an agent asking about a late checkout or a dietary request. Without a way for the two sides to talk efficiently, both end up operating on stale assumptions and falling back to whatever the published rate and rigid booking form can hold.

We’re building strait to be that channel. A lossless protocol where no information gets silently dropped to fit a legacy schema, and a bidirectional one where both sides participate. The future of trip planning is not an agent calling rigid REST endpoints. It is a traveler’s AI negotiating with a hotel’s AI to plan a stay that actually fits the traveler.

A real protocol needs two things to be true:

  • Preferences propagate without flattening. “I sleep hot, I work late, I always want sparkling water” should reach the hotel as intent the hotel AI can act on, not as a checkbox set someone pre-decided would cover every traveler.
  • The hotel can talk back. Upgrades, alternatives, soft conflicts, and live constraints that were never captured in structured data all need a return path. Today no such path exists, and we are building one.

This is what unlocks the upgrade that wasn’t listed, the rate that was never published, and the clean cancellation when plans change. None of those fit in a REST schema, and all of them are part of a normal stay.

3. Data shaped for LLM trust and rigor

LLMs are extremely gullible. If you hand them a rate without tax and fees, they’ll quote it as the price. That messes up budget constraints. If you hand them a result with no reason it was returned, they’ll make one up. Garbage in, confident garbage out.

That matters because travelers want to feel in control. That’s why many still manually search, cross reference, and compare. They don’t trust a direct answer with no work shown. Users are looking for trust and rigor when planning their next trip, not just a one line answer. The LLM can do that work for them, but it has to prove the work.

So we’re designing strait so every piece of data returned to the LLM is well documented and explained in line. Rates come with the full breakdown of taxes and fees, not just a nightly number. Search results come with the reason a hotel ranked where it did. Cancellation policies come with the actual conditions in language. When a caveat applies, instructions are embedded in the result so the LLM knows how to talk about it.

When the LLM searches for a hotel, strait will return all the supporting information it needs to explain to the user why that hotel is the right pick.

4. Infrastructure that survives AI-agent look-to-book economics

Most travel APIs were built for a human clicking through a results page. They’re not blasting tens if not hundreds of searches in parallel. AI agents are different. A traveler asks for “a quiet hotel somewhere in southern Europe sometime in June,” and a good agent will autonomously evaluate dozens of properties across several candidate cities and date windows before recommending three.

1

user prompt

~200

live API calls

~1

booking, if you're lucky

A single agent turn fans out into hundreds of live supplier calls. Conversion is lower than human-driven flows because users still close the chat to think about it. The supplier still charges for every search.

That matters because live travel queries are not free. Every search cascades down to a hotel PMS, a CRS, or a GDS that has finite capacity and tracks how many lookups happen per confirmed booking. The travel industry has a name for this ratio: look-to-book. Duffel, the leading independent flight API, allows 1,500 searches per confirmed order and then charges $0.005 per excess search. The World Aviation Festival has documented real-world ratios reaching 10,000:1 in practice. On the hotel side, LiteAPI publishes a production rate cap of 27,000 requests per minute on top of a 2.9 to 3.9 percent transaction fee per booking. An exhaustive AI agent burning 200 live calls per user prompt would saturate that account at roughly 135 user prompts per minute, before any per-search excess fees apply.

This is the math that quietly buries some AI travel startups. An agent doing 200 live searches per user, with conversion rates below human-driven flows because users still close the chat to “think about it,” ends up paying more in excess-search fees and infrastructure costs than the rare booking commission returns. The usual workarounds are to quote cached historical pricing, which inevitably drifts from the real rate, or to refer the user out to an OTA like Skyscanner for the actual live search and lose the booking entirely.

So we’re building strait around a hard separation between cheap search-time data and expensive transaction-time data. The property catalog, rich descriptions, amenities, photos, soft attributes, and indicative rates will be served from infrastructure strait maintains and refreshes out-of-band. Live PMS calls will only happen when a traveler’s agent has narrowed to real booking intent, not during exploratory search. An agent will be able to do its full exhaustive research pass without burning a supplier’s quota, and the PMS will only see traffic that is close to conversion.

This is the unsexy part of the protocol that decides whether AI trip planners can actually be businesses, or whether they quietly pivot to referral engines every 18 months.

Sources for pillar 4: