TL;DR: Only 11% of travel companies currently have an AI agent capable of completing a booking and pricing it in real time — the other 89% are still built for human-era browsing channels. That gap is closing fast: 61% of travel businesses are already experimenting with or scaling agentic AI, NDC bookings jumped from 11% to roughly 24% of indirect airline ticket sales in three years, and IDC projects up to 30% of all travel bookings will be executed directly by AI agents by 2030. This guide covers what "AI-agent-ready" actually means technically — machine-readable inventory, NDC and MCP support, real-time API performance, and structured data that doesn't rely on client-side rendering — and why hotels and operators that don't make this shift risk becoming invisible to the AI assistants increasingly mediating travel bookings.

The gap is bigger than most operators realize

The headline statistic here is stark: only 11% of travel companies have an AI agent that can complete bookings and price them in real time, while the remaining 89% remain tuned for channels designed around a human clicking through a website (Gimmonix). That's not a niche gap — it's the overwhelming majority of the industry still running infrastructure that wasn't designed for the way travel is increasingly being booked.

The demand side is moving faster than the supply side can currently handle. Phocuswright's 2026 research found 61% of travel businesses are already experimenting with or actively scaling agentic AI, and nearly 40% of U.S. travelers used generative AI to help plan trips in 2025 alone (Gimmonix). IDC projects that by 2030, up to 30% of travel bookings will be executed directly by AI agents rather than a human navigating a website or app (Adamosoft). Concretely, in March 2026, OAG's Future of Travel coverage described the month as the point "agentic travel gets real," coinciding with major infrastructure moves like the Sabre-PayPal-MindTrip partnership building what they describe as the industry's first end-to-end agentic AI booking system, querying Sabre's Mosaic APIs across more than 420 airlines and two million hotel properties worldwide (OAG; Finextra).

The clearest warning from current industry analysis: hotels and tour operators that don't make their inventory machine-readable risk becoming invisible as AI assistants mediate a growing share of bookings (Technology.org). An AI travel agent can't book — or even recommend — inventory it can't parse reliably.

The protocol landscape: NDC, MCP, and A2A

Three distinct but complementary standards are converging to define how AI agents interact with travel inventory and with each other:

NDC (New Distribution Capability) lets airlines bypass traditional GDS rails to offer richer, direct content — ancillaries like Wi-Fi, extra legroom, and branded fare bundles — directly through connected channels. Adoption has accelerated sharply: NDC bookings made up roughly 24% of indirect airline ticket sales globally in early 2026, up from just 11% in 2023, and North American corporate NDC volumes grew 168% year-over-year over the same period (Adamosoft). Traditional GDS infrastructure remains important, but it's increasingly being re-evaluated specifically on real-time response performance — a requirement agentic booking flows impose much more strictly than human browsing ever did (Amadeus).

MCP (Model Context Protocol), originally released by Anthropic, has emerged as the universal protocol for how AI agents connect to tools and data sources — and its adoption has moved well beyond a single vendor's ecosystem, now supported by Microsoft, Google, and OpenAI, with the broader ecosystem seeing over 110 million monthly downloads (DEV Community). For a travel platform, MCP compatibility is what lets an AI assistant actually query your live inventory, availability, and pricing directly, rather than relying on stale or incomplete data scraped from a public-facing page.

A2A (Agent-to-Agent) protocol, which reached v1.0 in April 2026 and is now supported by over 150 organizations, defines how AI agents discover and interact with each other as peers — sharing tasks, streaming results, and coordinating work across organizational and framework boundaries (DEV Community). This matters for travel specifically because a realistic booking flow often involves multiple specialized agents — a general trip-planning assistant coordinating with an airline's own booking agent and a hotel's availability agent — rather than a single monolithic AI handling the entire transaction.

Industry framing puts it concisely: MCP is the agent-access protocol, A2A links agents to each other, and GDS/NDC rails are being re-judged specifically on real-time response as the underlying infrastructure agentic bookings depend on (DEV Community).

What "machine-readable" actually requires, technically

Beyond protocol support, current guidance converges on a consistent set of technical requirements that are described as non-negotiable for a modern, agent-ready travel platform (Technology.org):

Caching architecture that doesn't sacrifice freshness. AI agents need availability and pricing data that's accurate at query time, not cached from hours earlier — but naive real-time queries against every backend system for every AI agent request can overwhelm infrastructure that wasn't built for that query volume or pattern. This requires a caching layer specifically designed for short TTLs on volatile data (price, availability) while still serving cacheable, stable data (property descriptions, amenities) efficiently.

Data normalization across inventory sources. Just as with MLS data in real estate, travel inventory typically flows in from multiple sources — direct property management systems, channel managers, GDS/NDC feeds — each with its own schema quirks. An AI agent querying your platform needs a single, normalized representation of that inventory, not a patchwork the agent has to reconcile itself.

NDC support, specifically for airline inventory, since NDC's richer content model (branded fares, ancillaries, real merchandising data) is what lets an AI agent make a genuinely useful comparison and recommendation, rather than working from the more limited data GDS-only rails typically expose.

Server-rendered structured data, not client-side generated markup. This is a specific and easy-to-miss technical detail: current guidance is explicit that structured data should be present in the initial HTML response, because dynamically generated markup (rendered client-side via JavaScript after page load) makes crawls — including AI agent crawls — less frequent and less reliable, particularly for fast-changing price and availability data (search synthesis). For travel platforms where inventory freshness is the whole point, pre-rendered HTML with embedded structured data is a much stronger foundation than a JavaScript-heavy single-page application that renders pricing only after multiple client-side API calls.

The right schema vocabulary, applied consistently. Travel-specific schema.org types — LodgingBusiness for hotels, TouristTrip for packaged trips, TouristAttraction and TouristDestination for points of interest, Event for scheduled activities, and Offer nested within these for pricing — give both traditional search engines and AI agents a consistent, structured way to parse what you're actually offering (WordLift; JSON Schema App). An API-first architecture pairs well here — generating JSON-LD structured data directly from API responses, isolated in script tags, means structured data stays in sync with the actual underlying inventory system without requiring separate manual maintenance of the markup (Strapi).

A readiness checklist for booking platforms

  • Can an external AI agent query your live availability and pricing through a documented API or MCP-compatible interface, or is your inventory only accessible through a human-facing web UI?
  • Is your structured data (schema.org markup for lodging, trips, offers) present in server-rendered HTML, or does it depend on client-side JavaScript execution that agent crawlers may not reliably wait for?
  • Do you support NDC for airline inventory (if applicable), giving AI agents access to richer fare and ancillary data rather than GDS-only baseline fares?
  • Is your caching architecture tuned specifically for the query patterns AI agents generate — potentially higher volume, more granular queries than typical human browsing sessions — without serving stale pricing?
  • Have you normalized inventory data across your various source systems (PMS, channel manager, GDS/NDC feeds) into a single consistent representation an agent can reliably parse?
  • Have you evaluated MCP compatibility specifically, given its rapid, cross-vendor adoption (Microsoft, Google, OpenAI) as the emerging standard for how agents access external tools and data?
  • If your booking flow could realistically involve coordination between multiple specialized agents (a trip planner, an airline's booking agent, a hotel's availability system), have you considered A2A protocol support for that kind of cross-agent coordination?

Where Syslabs fits in

Becoming agent-ready isn't a single feature to bolt on — it touches API architecture, caching strategy, structured data implementation, and inventory normalization, often across several existing systems that weren't designed with AI agents as a consumer in mind. Syslabs works with travel and hospitality platforms on exactly this kind of infrastructure work: building MCP-compatible API layers, implementing server-rendered structured data that stays synchronized with live inventory, and designing caching architectures that serve both human traffic and the different query patterns AI agents generate. If your platform is still primarily built for human-era browsing channels — which, per current data, describes the large majority of the industry — it's worth an infrastructure assessment before agentic booking volume grows past the point where retrofitting is straightforward.

Conclusion

Agentic AI in travel has moved past the experimental stage for a majority of the industry, even though only a small fraction of companies currently have the technical infrastructure to actually transact with an AI agent in real time. The gap between those two numbers — 61% experimenting, 11% actually ready — is where the near-term competitive opportunity sits. Getting there is a concrete infrastructure project: machine-readable, normalized inventory; server-rendered structured data; NDC support for airline content; and MCP compatibility for how AI agents actually query external systems. None of it requires waiting for a single dominant standard to emerge — the protocol stack (NDC, MCP, A2A) is already converging, and platforms that build toward it now avoid being the ones still invisible to AI assistants when agent-mediated bookings become a larger share of the market.

Sources

Common mistakes booking platforms make preparing for agentic AI

Treating agent readiness as an SEO or marketing checkbox. Adding a handful of schema.org tags to a marketing page isn't the same as making live inventory queryable by an AI agent in real time. The two are related but distinct: structured data helps AI systems understand and surface your content in search and recommendation contexts, while true agent readiness requires an actual API or MCP-compatible interface an agent can query, authenticate against, and transact through. Platforms that stop at the schema markup layer without building the underlying live-query infrastructure will show up in an AI assistant's research phase but won't be bookable directly through that assistant.

Underestimating the query volume and pattern shift AI agents introduce. A human browsing a hotel booking site typically makes a handful of page loads and searches per session. An AI agent comparing options across many properties, date ranges, and configurations on a traveler's behalf can generate a much higher volume of granular queries in a much shorter window. Infrastructure sized and cached for human browsing patterns can buckle under this different load profile, or fall back to serving stale cached data specifically during the highest-value moments (active comparison shopping) where accuracy matters most.

Assuming GDS-only inventory is sufficient going forward. With NDC bookings nearly doubling as a share of indirect airline ticket sales in three years, and North American corporate NDC volumes growing 168% year-over-year, platforms relying solely on baseline GDS fares are increasingly showing AI agents (and human travelers) a thinner, less competitive slice of available inventory than platforms with NDC support. This gap is likely to widen, not narrow, as more airlines shift richer content exclusively to NDC channels.

Ignoring authentication and transaction security for agent-initiated bookings. As AI agents move from research and comparison into actually completing bookings and payments on a traveler's behalf, platforms need clear authentication and authorization patterns for agent-initiated transactions — distinct from a human completing a checkout flow with their own session and payment entry. This is still an evolving area of the protocol stack, and platforms building agent-facing booking flows now should design for auditability and clear transaction attribution back to the responsible human traveler, not just optimize for frictionless agent access.

Waiting for a single "winning" standard before investing. Given that MCP, A2A, and NDC are each solving different, complementary problems — agent-to-tool access, agent-to-agent coordination, and richer airline content respectively — waiting for consolidation before investing risks falling further behind while more of the industry adopts all three in parallel. The practical approach is prioritizing MCP compatibility first, given its broad cross-vendor momentum, then layering in NDC support and A2A readiness as your specific product's booking flows require them.