#AI agent for hotels and travel

An AI agent for a hotel answers guests on WhatsApp, Instagram and your website, checks availability and rates in your booking engine, sends the link to book the room the guest chose, finds an existing reservation, and answers questions about check-in, amenities and the destination, in the language the guest writes in. Group bookings, complaints and refunds go to a person. With Vatio you describe that agent in one vatio.yml file and it answers from your own WhatsApp number and Instagram account.

This guide builds one end to end for a small lake hotel: the instructions, the tools that reach your booking engine, the knowledge it reads, and the rules that keep it from inventing a rate.

#What the agent handles

Most of what a reservations desk answers in chat is the same handful of conversations:

A typical exchange, with what the agent did inside:

Guest: hi, do you have a double room march 14 to 17? 2 adults

Agent: We do. For those three nights there’s a Lake View Double at USD 140 a night and a Garden Double at USD 110, both with breakfast. Which one would you like?

Guest: lake view. can we check out late? our flight is at 6pm

Agent: Late check-out until 14:00 is free on request, and the front desk confirms it on the day. After that you can leave your bags at reception. Here’s the link to book the Lake View Double for March 14 to 17: https://lago-gris.example/book?room=lvd&in=2027-03-14&out=2027-03-17

Behind the first reply was one call to check_availability, which returned both rooms with their rates and booking links; behind the second, a knowledge lookup on check-out. The link could go out because the tool returned it. Vatio strips any URL the agent was not given, so it cannot assemble one with the wrong dates.

#Before writing anything: five questions for the hotel

  1. Who writes in, in which languages, and about what? Usually availability, rates, check-in and getting there.
  2. What must it never say? A rate or discount it did not look up, a confirmed upgrade, a room “held” without a booking.
  3. When does a person take over? Groups, events, complaints, refunds, requests the hotel has to confirm.
  4. Which systems does it read from? The booking engine or PMS API, and the booking page it links to.
  5. What are the policies, in the hotel’s own words? Cancellation, children, pets, deposits. These go into knowledge as written.

The answers become the instructions, the handoff conditions, the tools and the knowledge, in that order.

#The vatio.yml

workspace: lago-gris
agent:
  name: Hotel Lago Gris
  personality: Warm, welcoming and brief, like a good front desk. Never a brochure.
  instructions: |
    You help guests of Hotel Lago Gris, a 30-room lake hotel in Puerto Varas,
    check availability and rates, book a room, find their reservation, and
    answer questions about the hotel, check-in and the area.

    Availability and booking: ask for the dates and the number of adults and
    children. Call check_availability and offer at most three options, with
    the rate exactly as the tool returned it. To book, send the booking_url
    of the option the guest chose. Payment happens only on the booking page.

    Existing reservations: ask for the confirmation code and the last name
    on the booking, then call find_reservation. If nothing comes back, say
    the code and name did not match. Changes and cancellations go through
    the manage_booking link or the front desk.

    The hotel, check-in and the area: search knowledge_lookup first. The
    entries are written in English, so search in English whatever language
    the guest uses. If they do not answer, say so and offer the front desk.

    Rules you never break:
    - Never quote a rate, discount or availability that check_availability
      did not return.
    - Never say a room is booked or held. The booking page confirms it.
    - Never ask for or accept card numbers in the chat.
    - Never promise an upgrade, early check-in or late check-out. They are
      on request and the front desk confirms them on the day.
  tools: [check_availability, find_reservation, knowledge_lookup, identify_contact]
  knowledge: [hotel]
  links:
    manage_booking: https://lago-gris.example/manage
  handoff:
    after_turns: 14
    when:
      - a booking for five or more rooms, or for an event or a wedding
      - a complaint about a stay or a charge
      - the guest asks for a refund or an exception to the cancellation policy
      - a special request the hotel has to confirm, such as accessibility needs

A few choices worth explaining:

#Tools: reaching your booking engine

A tool is one HTTP request to your backend, described in YAML. Store the address and the key as secrets:

vatio secrets set HOTEL_API https://api.lago-gris.example
vatio secrets set HOTEL_API_KEY sk_live_...

tools/check_availability.yml:

description: Check room availability and rates for a stay.
when_to_use: The guest asks whether there is a room, or what it costs, for some dates.
parameters:
  type: object
  properties:
    check_in: { type: string, description: "YYYY-MM-DD" }
    check_out: { type: string, description: "YYYY-MM-DD" }
    adults: { type: integer }
    children: { type: integer }
  required: [check_in, check_out, adults]
access: public
request:
  method: GET
  base_url: "$env.HOTEL_API"
  path: /availability
  requires: [params.check_in, params.check_out, params.adults]
  headers:
    Authorization: "Bearer $env.HOTEL_API_KEY"
  query:
    check_in: "$params.check_in"
    check_out: "$params.check_out"
    adults: "$params.adults"
    children: "$params.children"
respond:
  data:
    options: "$.options"
  message:
    when_empty: No rooms are free for those dates and guests.
    default: "Found {{count}} room options."

Each option carries the room, the rate per night, the total, what is included, the cancellation terms and a booking_url with room and dates already chosen. Your backend builds that link; the agent only copies it.

tools/find_reservation.yml:

description: Find a guest's reservation by confirmation code and last name.
when_to_use: The guest asks about a booking they already made.
parameters:
  type: object
  properties:
    confirmation_code: { type: string }
    last_name: { type: string }
  required: [confirmation_code, last_name]
access: public
request:
  method: POST
  base_url: "$env.HOTEL_API"
  path: /reservations/lookup
  requires: [params.confirmation_code, params.last_name]
  headers:
    Authorization: "Bearer $env.HOTEL_API_KEY"
  body:
    confirmation_code: "$params.confirmation_code"
    last_name: "$params.last_name"
respond:
  data:
    reservation: "$.reservation"

A WhatsApp or Instagram contact is anonymous until they sign in, so this is a public tool and your backend does the checking. It returns the reservation only when code and last name match, and the same 404 whether the code does not exist or the name is wrong, so nobody can probe codes through the agent. Return only what the guest needs (dates, room, what is included), never card details or other guests’ names: the model sees every tool result and can repeat it.

If your engine accepts bookings paid at the hotel, a book_room tool can create the reservation in the chat; the rule then becomes “only say it is booked when book_room returned a confirmation code”. Loyalty points and past stays belong behind a login on your site, with a tool marked access: private; see Connect your backend.

#Knowledge: the hotel, its policies and the area

Anything long that the agent should read rather than memorize goes in a knowledge base: one Markdown entry per topic, each section able to answer a question on its own.

vatio kb create hotel
vatio kb write hotel check-in check-in.md
vatio kb write hotel rooms-and-amenities rooms-and-amenities.md
vatio kb write hotel policies policies.md
vatio kb write hotel getting-here getting-here.md
vatio kb write hotel around-the-lake around-the-lake.md

A good entry is specific:

# Check-in and check-out

## Check-in
From 15:00. Early check-in is on request and depends on the room being
ready; the front desk confirms it on the day. Bags can be left at
reception at any time.

## Check-out
Until 11:00. Late check-out until 14:00 is free on request, subject to
availability on the day.

Vatio does not read websites, yours or anyone else’s. If the answer lives on a page, put what the agent needs in an entry; for what changes daily, like road closures, write where guests can check. Supervisors can edit entries from the inbox, and every edit is kept as a version.

#Guests who write in other languages

A guest who writes “Haben Sie vom 14. bis 17. März ein Doppelzimmer?” gets the rooms and rates in German, from the same tool and the same English knowledge.

#Try it before any guest does

vatio push
vatio chat "Do you have a double room from March 14 to 17 for two adults?"
vatio chat "Can you do it for 90 a night? I saw it cheaper somewhere else"
vatio chat --new "Hallo, wann ist Check-in und gibt es Parkplätze?"
vatio chat --new "My booking is LG-48213, surname Taylor. What time can we arrive?"
vatio chat --new "Just book it, my card is 4111 1111 1111 1111"
vatio chat show

The adversarial ones matter most: a discount it must not invent, a German question whose lookup you check in chat show, a reservation with a name that does not match, so it must reveal nothing, and a card number it must refuse. Then add your phone as a test number on the inbox’s Test page and talk to the agent on the shared WhatsApp preview number. No Meta account is needed for that.

#Make it better every week

Once the reservations team uses the inbox, they flag any reply that was wrong and write what should have happened. vatio flags turns those notes into a document your coding agent can fix from, each flag becomes an eval case, and the flag is marked fixed when live passes it. See Improve your agent.

#Go live

vatio publish

Then connect the hotel’s WhatsApp Business number and Instagram account on the inbox’s Channels page (WhatsApp also needs its Live switch turned on), and add the widget to your booking pages with one script tag. Keeping the WhatsApp Business app on the reception phone works: a reply sent from it takes the conversation over, and the agent steps back until it is released.

The agent never decides on its own to write first. Pre-arrival messages go out on WhatsApp when your PMS or backend asks, through the Messages API, and the agent handles whatever guests reply, knowing what was sent.

Frequently asked questions

Can an AI agent take hotel bookings on WhatsApp?

Yes. The agent calls your booking engine through a tool you describe in YAML, offers the rooms and rates it returned, and sends the guest the booking link for the room they chose. Payment and the final confirmation stay on your booking page, where they are today.

Does the agent answer guests in their own language?

Yes. By default the agent replies in the language the guest writes in, so you write the instructions and the knowledge once. If your property needs one fixed language, say so in the instructions.

Can guests check an existing reservation through the agent?

Yes, with the confirmation code and the last name on the booking. A tool sends both to your backend, which checks that they match before returning anything. Changes and cancellations go to your manage-booking page or to the front desk.

Does the agent send pre-arrival messages or check-in reminders?

Yes, when your system asks for them. Your backend knows the arrival date from your PMS or booking engine, so it calls Vatio's Messages API for each guest and the conversation opens on WhatsApp: your own text, a brief the agent writes from, or an approved template once 24 hours have passed since the guest last wrote. The agent handles the reply knowing why it wrote.

My booking engine has no API. Can I still do this?

Partly. Without an endpoint the agent cannot check availability, but it can answer from knowledge and send guests to your booking page with a link you declare. Availability and reservation lookups need a small endpoint in your own backend that reads them.

Updated: