An AI assistant recommends a hotel.
The traveller likes it and asks to book.
Now the system needs to move from describing an attractive option to confirming a specific transaction. It needs dates, occupancy, a valid price, current availability, cancellation conditions, and a booking outcome.
That transition is where I would focus an agentic-commerce audit for a travel marketplace.
Olaf Kopp uses Agentic Commerce Optimization to describe work that makes individual offers understandable and actionable for agents. Applied to travel, I find it useful as a framework for examining the distance between a recommendation and a confirmed reservation. Kopp’s ACO article.
Separate discovery, selection, and confirmation
These stages require different evidence.
Discovery asks whether the option is relevant enough to consider.
Selection asks whether the exact offer satisfies the traveller’s requirements.
Confirmation establishes whether the supplier has accepted the booking.
A well-written hotel page can support discovery. It cannot, by itself, establish that a particular room is still available for a particular stay.
I would keep these stages separate in both the architecture and the reporting. A mention in an answer and a successful reservation are different outcomes.
Travel inventory is conditional
“Available from $150” is not a complete booking offer.
The price may depend on the dates, length of stay, number and ages of guests, room configuration, currency, and selected conditions.
Google’s hotel documentation reflects this distinction through room bundles that combine room information with packages and prices for particular itineraries. Google’s room-bundle documentation.
Tours introduce similar conditions: departure time, party size, language, pickup location, and whether a booking needs supplier confirmation.
I would require an assistant to preserve those conditions as it moves between systems.
Three layers need to agree
For a travel marketplace, I would examine three connected layers:
| Layer | Its job |
|---|---|
| Descriptive content | Explain the experience, property, and suitability |
| Structured inventory | Identify exact options and their attributes |
| Booking interface | Validate current terms and create the reservation |
The implementation depends on the distribution partner. A hotel pricing integration, a tour supplier connection, and a retail product feed are not interchangeable.
Adding schema does not automatically establish checkout support in an AI platform.
Revalidate before asking for commitment
Suppose a traveller selects a refundable room for two adults. During the conversation, they add a child.
The original offer should not silently carry forward.
I would want the system to recheck eligibility and price, present any changed conditions, and obtain the traveller’s approval before creating the booking.
Booking.com’s documented order flow includes a preview step that validates the selected order and returns current pricing and booking conditions before creation. That is a useful concrete example of separating selection from confirmation. Booking.com’s order creation documentation.
Design for uncertain outcomes
The difficult scenario is not always “sold out.”
Sometimes a request times out after the supplier may have created the reservation. Retrying blindly could create a duplicate.
I would ask the engineering team how it handles duplicate requests, how it retrieves booking status, and what it tells the traveller while the outcome is uncertain.
The interface should distinguish a submitted request, a pending reservation, and a confirmed booking. A successful payment step alone should not be used as a substitute for the supplier’s booking status.
A worked offer check for a private tour
Imagine a family choosing a Christmas city tour. This is an illustrative requirements exercise, not a live offer or an implemented agent integration.
Before presenting a bookable option, I would need the date, local departure time, party size and relevant child ages. The system would identify the actual departure or request option, rather than rely on the general tour's name.
The offer would need a total price and currency, with mandatory charges and payment timing explained. “From” pricing is useful during discovery but cannot stand in for the total applicable to this party.
I would then check the conditions that can invalidate the match: age rules, physical demands, transport inclusion, pickup coverage and cancellation cutoff. The cutoff needs a date, time and time zone where applicable. A translated summary must preserve the meaning of the original terms.
Finally, I would establish the confirmation model. Is the departure instantly confirmable, or does a supplier need to accept a request? If it is a request, the interface should say that clearly before the traveller commits.
A product page may explain these fields. A current offer response must establish which values apply now. Neither layer should quietly borrow a condition from another departure, variant or rate.
Booking readiness needs an information contract
For an integration proposal, I would ask product, engineering and supplier operations to agree on what a valid offer contains.
The record should identify the provider, product, option, date, party, price, applicable terms, availability state and last validation time. It should also distinguish a value that is unavailable from one that is genuinely not applicable.
If a pickup field is empty, the agent should not infer that pickup is included. If walking conditions have not been verified, it should not convert missing detail into an accessibility claim.
I would document which changes invalidate the current offer. A different date, guest allocation or selected option may require revalidation. The selected identifiers need to remain attached to the conditions the traveller approved.
This is the travel-specific work behind being machine-selectable and machine-orderable. It is not completed by adding a Product record or a generic FAQ.
The campaign concept illustrates discovery, not a finished integration
My Christmas travel campaign concept connects destination discovery, a practical three-day plan and relevant tour choices. I proposed the campaign to my manager, but it was not implemented.
It is useful here as a journey-design example. Someone might first explore a destination, request a planner, then compare experiences that suit the plan. The landing-page concepts make those transitions visible.
They do not demonstrate working live inventory, an agent checkout or measured booking performance. To make that journey actionable for an agent, I would still need the current-data contract, the booking interface and the failure-handling tests described here.
Keeping that boundary explicit lets the concept support a portfolio discussion without being presented as a deployed commerce system.
Match the interface to what the platform actually supports
The retail feed, schema and checkout ecosystem does not map automatically onto hotel or tour inventory. I would verify the supported service type, partner requirements and transaction flow for the specific integration before recommending it.
For example, Booking.com's documented order flow separates preview from order creation. Preview validates a selection and returns conditions; it does not itself establish a reservation. That is an implementation example from its documented services, not a statement that the same endpoint supports every tour supplier.
Google's hotel room bundles similarly distinguish room features, rate conditions and itinerary-specific pricing. Those distinctions help define a hotel integration; they are not a universal tour-feed specification.
The consulting recommendation should name what can be implemented now, what requires a partner integration and what remains a proposed capability. Otherwise, “agent ready” becomes a label without an operational test.
Audit the whole journey
My initial test set would include a price change, unavailable inventory, an occupancy change, a pending confirmation, and an interrupted response.
For each case, I would check whether the traveller understands what happened and what action is safe to take next.
Agentic commerce makes the quality of the underlying booking operation more visible. Clear content starts the conversation; reliable inventory and confirmation handling make it possible to finish it.
