Bjorn Harvold

5 posts by Bjorn Harvold

The Hospitality Industry Is Looking at Agentic Commerce the Wrong Way

2026. aug. 15.

The industry is asking the wrong question

Most conversations about AI and hotel distribution are focused on visibility. Will ChatGPT find my hotel? Will Gemini recommend my property? Will Perplexity show my brand? Will my content be optimized for AI search?

These questions matter, but they are not the core issue. Discovery is not where the real battle will be won. The real question is this: when an AI agent finds the right hotel, who controls the transaction?

That is the point the industry is not taking seriously enough. Agentic commerce is not only about being recommended by AI. It is about being bookable by AI, in real time, under hotel-controlled rules, with direct payment, confirmation, attribution and settlement. If hotels solve discovery but fail to solve transaction control, they will have optimized for visibility while losing the booking.

Discovery was never the hardest part

AI will become very good at finding hotels. It can understand location, guest intent, budget, trip purpose, reviews, amenities, family needs, loyalty preferences and travel context. It can compare options faster than any human browsing session. That is not the hard part. The hard part is what happens after the recommendation.

Can the AI access live rates and availability? Can it understand which rooms are actually bookable? Can it respect cancellation rules, occupancy rules, rate plans and restrictions? Can it take secure payment? Can it confirm the booking instantly? Can it attribute the transaction correctly? Can it settle funds to the right parties? Can it service the booking after purchase?

This is where hotel distribution becomes infrastructure. AI describing a hotel is search. AI completing a hotel booking directly — with hotel-controlled inventory, rules and economics — is commerce. And commerce requires a transaction layer.

The OTA risk repeats in a new form

The hotel industry has seen this movie before. When digital demand moved online, hotels needed distribution, reach and conversion. OTAs filled that gap with technology, payment flows, customer trust and transactional infrastructure. They solved the booking problem at scale — but the cost was high: commissions, dependency, data leakage, weaker direct relationships and reduced control over the guest journey.

Agentic commerce could repeat the same pattern in a new form. If AI agents cannot complete a booking directly with the hotel, they will route the guest to whoever can — usually Booking.com, Expedia or another platform with the rails already in place. The AI may recommend the hotel. The guest may like the hotel. The final transaction may still happen somewhere else.

That is the danger. The winner in AI travel will not only be the company that appears in the answer. It will be the company that can execute the booking.

Independent hotels have the most to lose

Large hotel groups have more resources, stronger direct channels, loyalty programs, central reservation systems and technology budgets. Independent hotels do not.

For independent hotels, AI discovery could look like an opportunity at first. A guest asks an AI assistant for a boutique hotel in Bangkok, a family-owned resort in Bali, or a design hotel in Lisbon. The AI may surface excellent independent properties that would never have won a traditional paid-search battle.

That sounds positive. But if the booking cannot be completed directly, the value still leaks away. The guest relationship moves to the platform that can transact. The payment moves through someone else’s infrastructure. The data sits outside the hotel’s control. The economics are shaped by the intermediary. The hotel becomes content in someone else’s commerce flow. Being discoverable is not enough — hotels must become transaction-ready for AI.

What AI agents actually need

AI agents do not need brochures. They need structured supply — hotel inventory that can be read, priced, filtered, booked, paid for, confirmed and serviced programmatically. That means real-time access to room types, rates and availability, rate rules, cancellation policies, occupancy rules, taxes and fees, payment requirements, booking confirmation, guest details, attribution, settlement and post-booking servicing.

This is not a marketing problem. It is not just an SEO problem. It is not only a content problem. It is a systems problem. For an AI agent to book directly, the hotel’s commercial logic needs to be exposed in a secure, structured and controlled way. That is the infrastructure gap.

The missing layer is the transaction layer

The next layer of hotel distribution will not simply be search. Search finds options. Commerce executes decisions. Agentic commerce requires the ability to turn intent into a confirmed booking without pushing the guest into a separate, OTA-controlled environment.

That means the industry needs a transaction layer built for hotel-controlled commerce — a layer where hotels expose inventory directly, where rates and rules remain controlled by the hotel, where payment happens securely, where bookings are confirmed instantly, where attribution and settlement are handled correctly, and where new demand interfaces connect without every hotel building custom technology. This is the missing infrastructure, and it is where the conversation should be focused.

Wink has built it

This is what Wink has built. Wink connects hotel-controlled supply to the new demand layer through APIs, MCP, Booking Engine, payment, attribution and settlement.

That demand layer is not only AI agents. It includes platforms, developers, creators, publishers, travel apps, embedded maps, bookable cards, conversion banners, storefronts and any interface where travel intent appears.

The principle is simple. Hotels control the supply. Wink makes that supply programmable, bookable and payable. Demand partners can transact without becoming OTAs. AI agents can book without redirecting everything through legacy platforms. Creators and publishers can turn content into booking points. Developers can build travel commerce without rebuilding hotel infrastructure from scratch.

Wink is not trying to become the consumer destination. Wink is the invisible transaction infrastructure that lets hotel bookings happen wherever demand is created. The future of hotel commerce will not live only on hotel websites or OTA search pages. It will happen inside AI assistants, creator content, bank apps, travel platforms, maps, chat interfaces and embedded digital experiences. Hotels need to be bookable there directly.

What this means for hotels

For hotels, the goal should not be only to “rank” in AI. The goal should be to remain commercially in control when AI becomes a booking interface — keeping control over rates, availability, rules, guest data, payment flow, attribution, economics and the direct relationship.

If a guest asks an AI agent to book a hotel, the hotel should not be forced to surrender the transaction to an OTA simply because the OTA has better booking rails. The hotel should be able to transact directly, inside the interface where the guest intent already exists. That is what transaction readiness means. It does not replace the hotel website or existing channels. It extends hotel-controlled commerce into every new demand surface.

This is not anti-OTA

This is not an anti-OTA argument. OTAs are valuable. They create demand, package supply, serve travelers, invest heavily in conversion and will remain an important part of hotel distribution. The issue is not whether OTAs should exist. The issue is whether every AI-driven booking should default to OTA-controlled rails simply because hotels were not ready with their own transaction infrastructure.

Hotels need choice. If an OTA creates the demand, it should be compensated. If a creator drives the booking, that should be attributed. If a platform embeds hotel commerce, that transaction should be supported. If an AI agent recommends a hotel directly, the hotel should be able to complete that booking directly. The future should not force all demand through the same few intermediaries. It should allow hotel-controlled supply to transact wherever the guest is ready to book.

The next battle in hotel distribution is not “Will AI find my hotel?” It is “Can AI book my hotel directly?” That is what hotels should focus on.

AI Agents Will Not Book Hotels Without Commerce Infrastructure

2026. aug. 6.

Bjorn Harvold

Co-founder & CTO

The hospitality industry is right to pay attention to AI agents.

Agents will change how travelers search, compare, decide and ask for recommendations. They will become a new interface between traveler intent and hotel supply. But the industry is still at risk of focusing on the wrong part of the problem.

The hard part is not whether an AI agent can mention a hotel. The hard part is whether that agent can book the hotel — directly, accurately and under hotel-controlled rules.

A recommendation is not a reservation. Discovery creates intent. Commerce infrastructure turns that intent into a confirmed booking.

AI can find hotels. That does not mean it can book them.

AI systems are already good at interpreting intent. A traveler can ask for a quiet boutique hotel near a beach, a family property with connecting rooms, or a last-minute city stay with flexible cancellation. The agent can compare options, summarize reviews and explain trade-offs.

That is useful. But it is not yet hotel commerce.

Hotel commerce starts when the agent needs to know what is actually available, at which price, under which rules, with which policy, and whether the booking can be paid, confirmed, attributed and synced back to the hotel’s workflow. That is a different problem from discovery. It is an infrastructure problem.

The booking moment has more parts than search

A hotel booking is not a simple content answer. It requires live rates and availability. It requires room type logic, occupancy rules, taxes, fees, cancellation policy, payment handling, fraud and security controls, guest details, confirmation, servicing, attribution and operational sync.

If any of those pieces are missing, the agent may still recommend the hotel, but it cannot safely complete a direct booking.

This is why hotels should not confuse AI visibility with AI bookability. Visibility gets the hotel into the answer. Bookability gets the booking into the hotel’s commercial system.

Agents will use the rails that can complete the transaction

AI agents are not sentimental about distribution strategy. When a traveler asks an agent to book, the agent needs a reliable route to complete the task. If a direct hotel route is not structured, current and transaction-ready, the agent will look for a route that is.

That creates a familiar risk in a new interface: a hotel may win the recommendation but lose the transaction. The guest may have intended to book the hotel, but the completed transaction may still move through a platform that controls the economics, the data relationship and the post-booking experience.

This is not because the agent is hostile to hotels. It is because the hotel was not commerce-ready for the agent.

Independent hotels have the most to lose

Large brands can invest in technical infrastructure, loyalty ecosystems and direct distribution tools. Independent hotels usually have less room for complexity.

They still need to be accessible to new interfaces. They still need to serve modern traveler behavior. They still need to work with partners, creators, apps and AI agents without giving away control of the booking relationship.

The risk is that AI becomes another layer where independent hotels are visible but not directly bookable — repeating an old distribution pattern in a new format. The hotel appears in the journey. Someone else completes the booking.

What AI agents actually need

For an AI agent to book a hotel directly, it needs more than descriptive content. It needs structured supply, live availability, price and policy logic, booking rules, a secure payment route, confirmation, attribution, servicing paths and booking sync.

In other words, the agent needs hotel commerce infrastructure — readable by machines, stable enough for platforms, and controlled enough for hotels.

This is where APIs and MCP servers matter. APIs give platforms and developers structured system access. MCP servers give agents a tool-based way to understand and execute booking workflows. But the technology only matters if the underlying commercial layer is hotel-controlled.

The missing layer is commerce infrastructure

The next hotel distribution layer is not another search layer. Search is already abundant. The missing layer is the infrastructure that turns AI intent into a direct, controlled transaction.

That layer has to connect the hotel’s approved supply to the agent’s booking workflow. It has to preserve hotel rules, payment flow, attribution and operational sync. It has to make direct booking executable outside the hotel website, without turning every new interface into another uncontrolled intermediary.

This is why the conversation should move from AI discovery to AI commerce readiness. The question is not only, “Can AI find my hotel?” The question is, “Can AI book my hotel directly?”

What this means for hotels

Hotels should prepare for AI agents by making their supply transaction-ready: structured inventory, clear rules, reliable booking paths, payment readiness, confirmation logic, attribution and sync.

It also means thinking beyond the hotel website. Direct booking will increasingly happen through distributed interfaces — AI agents, partner apps, creator content, maps, chat interfaces and embedded experiences. But direct booking should still mean control: control of rates, rules, guest data, attribution, economics and the booking relationship.

Wink’s view

At Wink, our view is that AI agents will not transform hotel booking through discovery alone. They need a transaction layer.

Wink connects hotel-controlled supply to modern demand interfaces through booking, payment, attribution, sync, APIs and MCP-enabled access. That allows hotels to become bookable inside new AI and platform environments without forcing every transaction through someone else’s rails.

The goal is not to make AI another channel that hotels have to manage manually. The goal is to make hotel commerce infrastructure-ready for the interfaces where demand is moving.

The new question

The next battle in AI hotel distribution will not be visibility alone. It will be execution. For any agent, the test is whether it can:

access live hotel-controlled supply;
understand the rules;
handle payment;
confirm the booking;
attribute the demand; and
sync the reservation back to the hotel’s workflow.

If the answer is no, the agent may still recommend the hotel. But it will not book it directly. That is why AI agents will not book hotels without commerce infrastructure — and it all resolves in the hotel’s own Booking Engine.

Hotel Commerce Needs to Be Programmable and Shareable

2026. aug. 4.

Bjorn Harvold

Co-founder & CTO

The last wave of hotel distribution was about adding channels. The next wave is about making hotel commerce accessible wherever demand appears.

That does not mean giving every surface its own disconnected booking flow. It means exposing one controlled hotel commerce layer through the right access mode for each audience.

For developers, platforms and AI agents, access needs to be programmable: APIs, MCP servers, structured inventory, rules, payment, confirmation, attribution and sync. For hotels, partners and creators, access needs to be shareable: bookable links, maps, cards, embedded components and storefront-style tools that can be placed into content, campaigns and partner surfaces without engineering work.

The mistake is to treat those as separate products. They are not. They are two access modes into the same hotel-controlled transaction layer.

Controlled supply is only step one

A controlled supply layer is the foundation. It gives the hotel one trusted place for rates, availability, rules, policies, content and commercial permissions. But a supply layer only creates value if demand can reach it.

That is where the next infrastructure question begins: how should different demand surfaces access hotel-controlled supply without breaking the hotel’s control of economics, guest data, rules, attribution and operational flow?

The answer is not one interface for everyone. A developer building a travel product does not need the same access mode as a travel creator publishing a guide. An AI agent does not need the same access mode as a hotel marketer sharing a campaign link. The access mode changes. The transaction layer underneath should not.

Not every user is a developer

Hotel commerce cannot be API-only. Most of the people who can create demand for hotels are not going to build against an API.

A hotel revenue team may want to publish a package in seconds. A creator may want to turn a destination article into bookable content. A destination partner may want to share a curated route. A marketing team may want to place a map or conversion card inside a campaign page.

Those users need no-code primitives — links that can be shared anywhere online, embeddable cards, dynamic maps, and simple components that turn travel intent into a controlled booking path (this is what Studio and WinkLinks are for). The goal is not to make them learn hotel connectivity. The goal is to make hotel-controlled supply usable by the people and partners already creating demand.

Not every interface is human

At the same time, hotel commerce cannot be no-code-only. The most important new demand surfaces will increasingly be software surfaces.

Travel platforms, fintech apps, loyalty products, itinerary tools, AI agents and agentic commerce systems need structured technical access. They need to query supply, understand rules, price stays, initiate payment, create confirmation, carry attribution and sync the booking back into the hotel’s operating workflow.

This requires programmable infrastructure. APIs matter because platforms need stable system-to-system access. MCP servers matter because AI agents need a reliable way to understand and execute tool-based commerce workflows. Structured booking logic matters because a recommendation without execution is not commerce. If the technical layer is weak, AI agents and platforms will default to rails that can complete the transaction — and that is where hotels risk losing control.

Separate products create fragmented commerce

Many hotel technology stacks separate these problems. The booking engine is one system. The website widget is another. Partner links sit somewhere else. Developer APIs are treated as a technical add-on. Attribution becomes a reporting problem after the fact. Payment and settlement sit in another layer again.

That fragmentation creates a strategic issue: each demand surface may look connected, but the hotel does not get one coherent commerce system.

The future needs a different pattern. No-code primitives and programmable access should not be disconnected products. They should be different doors into the same transaction layer. That is what makes the model scalable.

Programmable supply

Programmable supply is about making hotel commerce usable by machines and software teams. A platform should be able to ask what is available, under which rules, at which price, and complete the booking through controlled infrastructure. An AI agent should be able to move from intent to transaction without sending the guest to a third-party platform simply because that platform is easier to book. A developer should be able to integrate hotel commerce into a product without rebuilding inventory, payment, confirmation and attribution logic from scratch.

That is the value of APIs and MCP servers: they make hotel-controlled supply executable.

Shareable supply

Shareable supply is about making hotel commerce usable by humans without engineering work. A hotel should be able to publish a bookable offer as a link. A creator should be able to embed a bookable map or card in a guide. A partner should be able to place hotel inventory into a relevant surface without becoming a hotel technology company.

This matters because demand is increasingly distributed. Travel inspiration happens in articles, social content, newsletters, maps, communities, bank apps, chat interfaces and niche platforms. If those surfaces can only inspire but not transact, the booking will often leak elsewhere. Shareable primitives close that gap — they turn intent into a controlled booking route.

One transaction layer underneath

The important point is that programmable and shareable access should not create two versions of the truth. There should be one hotel-controlled transaction layer underneath: the same approved supply, the same rules and policies, the same payment readiness, the same confirmation logic, the same attribution, the same booking sync.

That is what allows hotels to expand access without losing control. The surface can be a website, a creator guide, a map, a partner app, an API or an AI agent. The commerce layer remains consistent.

Why this matters for hotels

Hotels need new demand — but they should not have to choose between reach and control. A hotel should be able to work with creators without handing over the guest relationship, power partners without recreating OTA economics, serve AI agents without letting the transaction default to someone else’s platform, and give developers access without turning every integration into a bespoke project.

When hotel commerce is programmable and shareable, the hotel can be bookable across more surfaces while keeping its commercial rules, rates, attribution, payment flow, guest data and operational sync under control. The prize is not more channels for the sake of more channels. The prize is controlled distribution at internet scale.

Wink’s view

At Wink, our view is simple. Hotel commerce needs to be both programmable and shareable — programmable for developers, platforms and AI agents; shareable for hotels, partners and creators. Both connect to the same hotel-controlled booking, payment, attribution and fulfillment layer.

That is what makes Wink infrastructure rather than another isolated demand channel. Wink is not trying to replace every interface where travel demand appears. Wink is building the commerce infrastructure that lets those interfaces transact directly against hotel-controlled supply.

The next distribution question

The next question for hotels is not only, “Where should we be visible?” It is, “Can every relevant surface access our supply in the right way and complete a controlled booking?”

For some surfaces, the answer will be API access. For others, MCP-enabled agent access. For many, a link, a map, a card, an embedded component or a storefront-style experience. The same layer carries all of it — supply, rules, payment, confirmation, attribution and sync all resolving in the Booking Engine.

The winning model is not API-only. It is not no-code-only. It is one hotel-controlled transaction layer with many access modes. Programmable for machines. Shareable for humans. Bookable everywhere control matters.

The Booking Engine Is No Longer Just a Website Tool

2026. júl. 25.

Bjorn Harvold

Co-founder & CTO

For years, the hotel booking engine had a simple job. A guest arrived on the hotel website. They selected dates, chose a room, entered payment details and received a confirmation. The booking engine was the checkout sitting behind brand.com.

That role still matters. The hotel website remains one of the most important direct channels a hotel has. A strong website and a strong booking flow are not going away.

But the way travel demand forms is changing. Guests no longer discover, compare and decide in one predictable place. Travel intent now appears across AI agents, creator content, maps, bank apps, loyalty platforms, messaging interfaces, social content and embedded digital experiences.

That creates a new question for hotels: is the booking engine only a website tool, or is it the infrastructure that makes hotel-controlled transactions possible wherever intent appears?

The booking engine was built for brand.com

The traditional booking engine was designed around a clear journey. A guest searched, found the hotel, visited the website, and the booking engine converted that visitor into a reservation. The website was the commercial destination. Marketing created demand, brand.com captured it, and the booking engine completed the transaction.

This architecture made sense when most direct booking strategy was built around driving traffic back to the hotel website. It also gave hotels a clear point of control — rates, rules, room content, payment, confirmation and guest data within their own direct environment.

But that model assumes the guest always comes back to brand.com before booking. That assumption is becoming weaker.

Demand no longer lives in one place

Travel demand is becoming more distributed. A guest may ask an AI assistant to plan a weekend. They may read a creator’s city guide. They may explore a map. They may see a bookable hotel recommendation inside a bank app, a loyalty platform, a chat interface, a workplace travel tool or an embedded travel experience.

Some of these surfaces will influence discovery. Some will shape consideration. Some will become transaction points. The hotel website will still matter, but it will not be the only place where high-quality booking intent appears.

This is not a small channel change. It is a structural change in how travel commerce is distributed. Hotels need to decide whether they want these new surfaces to become referral paths into someone else’s transaction layer, or controlled routes into their own commercial infrastructure.

The website-only booking engine is too narrow

If the booking engine only works when a guest reaches the hotel website, it cannot fully serve the next generation of demand. A creator article can inspire a stay, but inspiration alone is not a booking. A map can surface the right hotel at the right moment, but visibility alone is not conversion. An AI agent can recommend a property, but recommendation is not a transaction.

If those surfaces cannot connect to hotel-controlled rates, rules, payment, confirmation and booking sync, the booking will move to whoever can execute it — an OTA, a marketplace, a super app or another platform with stronger transaction infrastructure.

The problem is not that demand starts elsewhere. That can be positive for hotels. The problem is when the transaction has to leave hotel-controlled rails in order to be completed. That is where economics, guest data, attribution and control can be lost.

The booking engine becomes the execution layer

The booking engine needs to evolve from a website checkout into a commerce execution layer. Its job is no longer only to convert a visitor on brand.com. Its job is to make hotel supply transactable.

That means the Booking Engine must support live rates and availability, hotel-controlled rules, room selection, payment, confirmation, attribution, settlement, servicing and booking sync — whether the guest starts on the hotel website, inside an AI conversation, through a creator link, in a map, in a bank app or inside an embedded partner experience.

In other words, the booking engine becomes less about where the guest clicks and more about how the transaction is executed. The channel changes. The control layer should not.

Embedded commerce needs hotel control

Embedded travel commerce will create new opportunities. Creators can turn qualified inspiration into bookable routes. Platforms can turn travel intent into bookings. Developers can add hotel commerce into existing products. AI agents can move from recommendation to execution.

But embedded commerce is only valuable for hotels if it protects control. A booking should not become indirect simply because the guest starts outside the hotel website. The important question is who controls the commercial relationship when the booking is made.

Does the hotel control the rate and the rules? Does it receive the guest data? Does the booking sync into the hotel’s operating workflow? Does attribution remain visible? Is the transaction completed without a commission-taking intermediary becoming the gatekeeper? If yes, distributed demand can strengthen direct commerce rather than weaken it. If no, embedded commerce becomes another way for hotels to lose the transaction after creating the demand.

APIs, MCP servers and no-code primitives serve the same goal

Not every demand partner wants to access hotel commerce in the same way. A developer may want APIs. An AI system may need MCP servers and agent-readable workflows. A creator may need a shareable bookable link, an embedded map or a card that can be placed inside content. A platform may need web components or a controlled booking flow that sits inside its own experience.

These are different access layers. But the goal is the same: make hotel-controlled supply bookable and payable wherever qualified intent appears.

That is why the booking engine can no longer be seen as one front-end widget. It must sit behind multiple delivery mechanisms — technical access for developers and agents, and no-code primitives for partners, creators and commercial teams. The access layer may change. The transaction infrastructure underneath must remain consistent.

Why this matters for independent hotels

Independent hotels have the most to gain from distributed demand, but also the most to lose if they are not transaction-ready. A large brand may have loyalty systems, app distribution, central reservation infrastructure and internal technology teams. An independent hotel often has less control over where demand comes from and less capacity to build new commerce infrastructure from scratch.

New demand surfaces could help independent hotels become more visible and more competitive. But visibility is not enough. If an independent hotel is discovered in an AI response, featured by a creator or surfaced inside a partner platform, but the booking is completed somewhere else, the hotel may still lose the economics, attribution and guest relationship. The opportunity is not simply to appear in more places — it is to become bookable in more places while keeping hotel control.

Wink’s view

At Wink, our view is that the booking engine is becoming infrastructure. The future booking engine will not only sit on the hotel website. It will power hotel-controlled transactions across every demand surface where qualified travel intent appears.

That requires one layer that connects hotel-controlled supply to booking, payment, attribution, confirmation, settlement and sync. It also requires different ways to access that layer: APIs, MCP servers, web components, shareable bookable links, embedded maps, booking cards and other no-code primitives.

The point is not to turn every external surface into an OTA. The point is to let hotels transact through new interfaces without giving up their commercial control. Wink is built for that shift — not as a consumer destination, not as another marketplace, not as a booking widget. As commerce infrastructure for hospitality.

The new role of the booking engine

The booking engine is no longer only the final step on the hotel website. It is becoming the infrastructure layer that allows hotel supply to be searched, selected, paid for, confirmed, attributed and synced across distributed demand.

That changes how hotels should think about direct booking. Direct booking is not only about forcing every guest back to one website. It is about protecting the hotel-controlled transaction wherever the booking happens — live rates and availability, hotel-controlled rules, payment and confirmation, attribution and settlement, and booking sync across operating workflows.

The next booking engine will not be judged only by how well it converts brand.com visitors. It will be judged by how well it makes hotel commerce executable across the new interfaces where travel demand is forming. The future booking engine will not just sit behind the website. It will sit behind the market.

Being Discoverable Is Not the Same as Being Bookable

2026. júl. 18.

Bjorn Harvold

Co-founder & CTO

The hotel industry is starting to ask an important question: will AI find my hotel? That question matters. But it is incomplete.

In the age of AI search, LLMs and agentic commerce, being discoverable is only the first step. The more important question is: can AI complete a hotel-controlled booking?

Visibility is not conversion

Hotels have spent years learning how to appear in search results — SEO, metasearch, OTA ranking, Google Hotel Ads, review optimization, content strategy, social media, influencer campaigns and brand.com performance. All of these disciplines were built around one objective: make the hotel visible when demand appears.

AI changes the interface, but not the commercial truth. A guest may no longer search through ten browser tabs. They may ask an AI assistant for a quiet boutique hotel in Paris, a family-friendly resort in Phuket, or a business hotel near a conference venue in Singapore.

The AI can summarize options, compare locations, read reviews, understand intent and recommend a property. But recommendation is not the same as booking. A hotel can be perfectly described by AI and still lose the transaction.

AI discovery will become a commodity

Over time, AI discovery will become very good. LLMs will understand hotel content better, read structured data more efficiently, interpret guest preferences with more nuance, and combine location, price, amenities, reviews, policies and context into increasingly useful recommendations.

This will help travelers. It may also help independent hotels appear in more relevant conversations. But discovery alone does not solve distribution.

If an AI assistant recommends a hotel but cannot complete a hotel-controlled booking, the guest will still be pushed somewhere else. The transaction will move to the platform that has the infrastructure to execute it — an OTA, a super app, a travel marketplace, any intermediary that can complete the booking while taking commission, owning the customer relationship or controlling the data.

The risk is simple: AI may find the hotel, but another platform may own the booking, the economics and the guest relationship.

Bookability requires infrastructure

To be bookable by AI, a hotel needs more than good content. It needs commercial infrastructure that can answer and execute in real time: live rates and availability, room types and restrictions, cancellation policies, occupancy rules, taxes and fees, secure payment, booking confirmation, attribution, settlement, PMS or booking sync, and post-booking servicing.

This is not traditional marketing. This is not just SEO for AI. This is transaction infrastructure. A hotel website can show content to a human. A booking engine can convert a brand.com visitor. But agentic commerce requires something broader: hotel supply that can be read, understood and transacted by software across many interfaces.

Human-readable is not enough

Most hotel content was built for people — photos, descriptions, amenities, reviews, packages and destination copy that help guests decide. They are important, but they are not enough for AI commerce.

AI agents need structured, machine-readable supply. They need to know not just what a hotel is, but what can be booked, under which rules, at what price, with which payment flow and with what confirmation process. A beautiful hotel profile is not the same as a bookable commercial endpoint.

This distinction matters because the next generation of travel interfaces will not always send users to a hotel website first. The booking moment may happen inside a chat interface, a travel planning assistant, a creator article, a map, a bank app, a loyalty platform or another embedded digital experience.

That does not automatically make the booking direct. A booking is direct only when the hotel keeps control of the commercial relationship — no commission-taking intermediary, hotel-controlled rules and rates, and guest data owned by the hotel. If the hotel is not transaction-ready in those environments, the booking will flow through whoever is.

Independent hotels are especially exposed

Independent hotels have a real opportunity in AI discovery. AI can surface more nuanced recommendations than traditional paid search. It can understand why a traveler may prefer an independent hotel over a large brand, matching guest intent to personality, location, design, service style and experience. That could be powerful — but only if the hotel can capture the transaction.

Otherwise, independent hotels risk becoming AI-visible but commercially dependent. They may be recommended more often, but still lose the guest relationship, payment flow, attribution, data and economics to platforms that can complete the booking. This is the same structural problem the industry has faced before: distribution shifts create opportunity, but if hotels do not control the transaction layer, the value concentrates elsewhere.

The new question for hotels

Hotels should still care about AI visibility. They should make their content accurate, structure their data, keep rates, policies and amenities clear, and ensure AI systems can understand who they are and what they offer. But that is only the beginning. The real test is whether the hotel can move from being recommended to being booked.

Can an AI agent access live inventory? Can it respect hotel-controlled rules? Can it take payment securely? Can it confirm the booking instantly? Can it attribute the source of demand? Can it settle the transaction correctly? Can the hotel keep control of the guest relationship and guest data? That is the difference between discoverability and bookability.

Wink’s view

At Wink, our view is that the future of hotel distribution will not be defined only by where guests search. It will be defined by where travel intent can be converted into a confirmed booking. That requires hotel-controlled supply to become programmable, bookable and payable across new demand interfaces.

AI agents are one of those interfaces. But they are not the only one. Creators, publishers, developers, platforms, bank apps, maps, social content and embedded digital experiences are all becoming places where travel demand can appear.

The infrastructure challenge is the same across all of them. Hotels need to expose their supply in a controlled way. Demand partners need a way to transact without becoming commission-taking intermediaries or owning the guest relationship. Guests need a smooth booking experience. Payments, confirmation, attribution and settlement need to work behind the scenes.

That is the layer Wink has built. Not a consumer destination. Not another OTA. Not only a booking engine. A transaction infrastructure layer for hotel commerce.

The future is not just search

The next era of travel distribution will not be won by visibility alone. Hotels will need to be discoverable, yes. But more importantly, they will need to be bookable wherever intent appears. That is the shift.

The question for hotels is no longer only: will AI find me? It is: when AI finds me, can the guest book in a way where the hotel keeps the economics, the rules and the guest relationship?