Ayoub Taoufik

Case 02

AI booking assistant for trip planning

Plan a trip, get support and build a priced trip pack in one chat. The site’s existing checkout handles payment.

Live · since Sep 2026

Owner and lead engineer

I own and lead the AI booking assistant for the travel-commerce platform in case 01. Travellers can ask questions in their own language, plan a trip and build a customised, priced pack in one conversation. Live systems provide prices and availability, the server sets the pack price, and the site’s existing checkout handles payment.

The problem
Travellers searched, compared options and added extras in separate flows. The assistant connects trip planning and support in one chat, with live prices and availability and booking access tied to sign-in.
What I built
I built a streaming chat that lets travellers plan trips, get support and assemble a priced trip pack for the existing checkout. It uses more than 20 typed tools connected to live systems.
What changed
Travellers can search, plan trips, get support and prepare a handoff for review in one conversation. Search is public; booking lookups and pack changes require sign-in. Live systems supply prices and availability.
Fig. 02.1Travellers had to search, compare and add extras in separate places.Now one chat plans the trip, answers questions and builds one priced trip pack that ends at the site’s checkout.

The traveller asks in one chat, which answers a question and builds a priced trip pack. Example prices appear beside hotel, pickup, eSIM, and activity lines. The final pay link opens the site’s existing checkout.

One messageLisbon, 3 nights, airport pickup, eSIM.Is breakfast included?Yes, at this hotel.

The traveller asks in their own words, and can ask questions along the way.

Under the hood: 20+ typed tools · 12 steps, 60 s a turn
One priced trip
  • Hotel, 3 nights€342
  • Airport pickup€28
  • eSIM, 10 GB€12
  • Old-town walking tour€19
Total€401

Each line is priced from the live booking systems.

Server-held trip pack
Pay at checkout

Payment happens on the site’s existing checkout, not in the chat.

Pay link · no payment in the chat

Prices and availability come from live systems.

Fig. 02.2 · Film · 0:10
One traveller message becomes a priced trip: hotel, airport pickup, eSIM and a tour fill in line by line, and the trip ends at the site’s checkout.
Transcript

This is an illustrative flow, not a recording: a traveller sends one message asking for Lisbon, three nights, an airport pickup and an eSIM. The trip pack fills in line by line with hotel, pickup, eSIM and a walking tour, each priced, then a €401 total and a Pay at checkout button for the site’s own checkout. The trip and its prices are examples.

Plan and prepare a trip in one chat

Travellers can ask in their own language, plan a trip, search hotels and places, read travel guidance and ask support questions. After they choose, the assistant can add transfers, an eSIM or activities to a customised trip pack. Multi-component packages go through the site’s existing package builder.

More than 20 typed tools connect the assistant to live systems. Those systems provide prices and availability, and the server checks the price before saving a pack.

The server prices and saves the trip pack, then returns a link to the site’s existing checkout. The chat does not open a payment session. Checkout uses the platform’s existing per-item fulfilment flow.

Typed tools, offered by context

The assistant uses more than 20 typed tools for search, booking lookups, transfers, eSIM, activities, draft packs, packages, places and handoff. Available tools depend on sign-in and configuration. Place tools appear only when place search is configured; visitors who are not signed in cannot look up bookings or change a pack.

The server uses the signed-in session to identify a traveller. Anyone can search and read guidance. Booking lookups and changes to a pack or draft require sign-in.

  1. Search

    Open to every visitor

    Hotel and place search and travel guidance work without an account.

  2. Owned data

    Behind sign-in

    Booking lookup and pack or draft changes are offered only to a signed-in traveller, scoped by the server-side session.

  3. Handoff

    Consent first, then a draft

    With the traveller’s consent, the handoff tool prepares a draft for a person to review. It never claims that a message was sent.

Limits for each request and turn

Each caller can make 20 requests per minute. If the limit cannot be enforced, the server refuses chat requests because they call a metered model.

A turn allows up to 12 steps and 60 seconds. A read tool stops waiting after 30 seconds and reports that the lookup timed out, not that it found no results. The underlying query may continue in the background.

Five write tools are exempt from the timeout because ending the wait would not stop a write, and a timeout message could prompt a traveller to repeat a pack change. Before saving, the server checks the price and returns the saved total. The model writes the conversation; the server sets the price.

Designed before implementation

Written designs preceded implementation. An early design ended with a payment-provider link for one hotel booking. A later revision made the trip pack the checkout handoff, so add-ons can be paid for through the site’s existing checkout.

The assistant has more than 15 service test files, including tests for system prompt rules and language behaviour. These tests cover rules and tools, not model quality.

Scope

What I built

Built

01
  • Assistant architecture, typed tools and delivery.
  • Request, step and time limits, including the five write-tool exemptions.
  • Sign-in requirements for booking lookups and pack changes.
  • Priced trip packs linked to the existing checkout.
  • Written designs, including the change to trip-pack checkout.
  • Assistant service tests for prompt rules and language behaviour.

Stack

  • TypeScript
  • Next.js
  • AI SDK
  • tRPC
  • Zod
  • Redis
  • Sentry