AI Agents for Travel Booking and Customer Service Automation

tpconnects · Other · 2025 · source Agentic: yes · promotional bias: high · source-backed · extracted with prompt 0.5.2 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Travel booking and servicing

TPConnects needed to expose legacy travel APIs through conversational agents while handling large flight-offer payloads, IATA terminology, and customer-service flows.

Constraints:

2000+ offers
latency
JSON consistency
API orchestration

Architecture

TPConnects’ Trip Captain runs on Amazon Bedrock as a supervised multi-agent travel orchestration engine. A supervisor receives user input, prompt/session history, and travel-domain knowledge, then routes to specialized booking, shopping, order-management, reshop/cancel/service, and order-retrieval agents. Function/action calls invoke travel APIs, MySQL-backed text-to-SQL order lookup, and chunked/paginated API responses. Claude 3.5 Sonnet handles conversational responses, while knowledge bases encode IATA/airport/airline codes and WhatsApp Business extends the agent into disruption handling and upsell.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  user-travel-request["user-travel-request"]
  prompt-and-session-store["prompt-and-session-store"]
  supervised-agent["supervised-agent"]
  shopping-agent["shopping-agent"]
  order-agent["order-agent"]
  service-agents["service-agents"]
  mysql-text-to-sql["mysql-text-to-sql"]
  knowledge-base["knowledge-base"]
  action-groups["action-groups"]
  travel-api-layer["travel-api-layer"]
  whatsapp-business-api["whatsapp-business-api"]
  user-travel-request --> supervised-agent
  prompt-and-session-store --> supervised-agent
  supervised-agent --> shopping-agent
  shopping-agent --> order-agent
  order-agent --> travel-api-layer
  supervised-agent --> service-agents
  service-agents --> mysql-text-to-sql
  supervised-agent --> knowledge-base
  supervised-agent --> action-groups
  action-groups --> travel-api-layer
  service-agents --> whatsapp-business-api

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`user-travel-request`	Traveler conversation containing destination, dates, preferences, and service intent.	`supervised-agent`
`prompt-and-session-store`	Stores agent prompts, chat history, session history, and previous conversation context.	`supervised-agent`
`supervised-agent`	Primary Bedrock agent that recognizes intent and routes work to specialized sub-agents.	`user-travel-request`, `prompt-and-session-store`, `shopping-agent`, `order-agent`, `service-agents`, `knowledge-base`, `action-groups`
`shopping-agent`	Handles flight shopping and offer retrieval.	`supervised-agent`, `travel-api-layer`, `order-agent`
`order-agent`	Converts selected shopping results into orders/bookings.	`shopping-agent`, `travel-api-layer`
`service-agents`	Handle reshop, cancel, order retrieval, and post-booking service flows.	`supervised-agent`, `mysql-text-to-sql`, `whatsapp-business-api`
`mysql-text-to-sql`	Backend order retrieval path connected to MySQL through text-to-SQL.	`service-agents`
`knowledge-base`	Travel domain knowledge for airport/airline/IATA codes and acronyms.	`supervised-agent`
`action-groups`	Bedrock action/function interface for invoking APIs and returning control.	`supervised-agent`, `travel-api-layer`
`travel-api-layer`	Legacy travel APIs for shopping, order create, servicing, and offer retrieval.	`shopping-agent`, `order-agent`, `action-groups`
`whatsapp-business-api`	Channel for disruption notifications, alternate offers, upgrades, and cross-sell.	`service-agents`

Data flow

A traveler enters a request. Prompt storage, conversation history, and instructions feed the supervisor/chain-of-thought layer until required trip parameters are collected. The supervisor routes to shopping, booking, order, reshop, or retrieval agents; functional calls invoke travel APIs or MySQL text-to-SQL; large offer responses are chunked/paginated before being sent to the LLM; the user gets rich travel options in chat or WhatsApp, including disruption alternatives and upsell offers.

4 supporting quotes

“the supervised agent take control of the input from the uh user and based on the input it recognize and directs the user to the multiple agents which is connected to the supervised agent.”transcript, stated

“the chain of thought actually interact with the customer and get all the required input before it process it with to the API or the LLMs.”transcript, stated

“the functional calls is responsible for making an API call behind and then parse the response and then uh the response is feed back into uh the LLM”transcript, stated

“So it just pushed the offer when there is a disruption happens and the customer can actually choose from the WhatsApp”transcript, stated

Why this architecture

The system uses supervised routing because travel booking is a multi-phase journey with distinct APIs and service intents. Bedrock/Claude handles conversational reasoning, while action groups and return-of-control keep API execution explicit. Knowledge bases address travel-domain acronyms and codes; chunking/pagination addresses huge offer payloads; WhatsApp extends the same agent orchestration into proactive service moments instead of only reactive chat.

4 supporting quotes

“we have used cloud center 3.5. So that's one of the stable model in giving a reasonable textual uh response based upon the user input”transcript, stated

“we had to feed in all the required airport codes and the airline codes to make the knowledge base uh thicker”transcript, stated

“So how do you actually push all the messages into uh LLM? So it can't be possible. So you have to convert that into multiple chunks and the multiple chunks into a pagenated responses.”transcript, stated

“we use uh boto 3 and then the return of control a function which takes the response from the API”transcript, stated

Models used: Claude 3.5 Sonnet · Amazon Bedrock

Scale

A Dubai-to-London shopping request can return more than 2,000 flight offers, creating LLM latency/payload pressure.
“when you shop between Dubai to London you might be getting quite a lot of offers response like a 2,000 plus offers from the different airline fly in between.”transcript, stated
The productization work addressed several APIs for even a simple order create pipeline.
“there are several APIs as to be performed in for a simple order create uh behind the screen.”transcript, stated
The broader implementation reportedly took 3-4 months with AWS support.
“The system took 3-4 months to develop with AWS support and represents a shift from manual UI interactions to conversational AI-driven travel experiences.”summary, stated
The WhatsApp integration supports disruption alternatives, cancellations, upgrades, and cross-sell before departure.
“not just there prior to departure we also use uh pushing an offer for upgrade and pushing an offer for an cross-ell for if they're looking for another travel component not just the air.”transcript, stated

Alternatives considered (roads not taken)

A single chat engine over travel APIs

Rejected because: TPConnects needed a full interactive travel UI and specialized agents for shopping, order, servicing, and backend order retrieval.

“This is not just an another chat engine. It is a so interactive user interface that we built on top of the chat. So it's not just a text.”transcript, stated

Push full travel offer payloads directly into the LLM

Rejected because: Large offer responses created latency and token limits, so responses had to be chunked/paginated.

Patterns

`multi-agent-orchestration` (travel)

A supervised agent coordinates specialized travel-domain sub-agents through the booking and service journey.

“The system employs a primary supervised agent that controls multiple specialized sub-agents beneath it.”summary, stated

`rag-retrieval` (domain-knowledge)

Knowledge bases and prompt engineering provide travel terminology and domain context for API use.

“The solution uses Claude 3.5 Sonnet as the primary model, incorporates prompt engineering and knowledge bases for travel domain expertise, and extends beyond traditional chat to WhatsApp Business API integration for proactive disruption management and upselling.”summary, stated

Tradeoffs

How to handle high-volume flight-offer responses in a conversational agent.

Chose Chunk and paginate API responses before passing them through the LLM. over Sending thousands of flight offers directly into model context..

Rationale: The transcript names latency as the core productization issue and says 2,000+ offers cannot simply be pushed into the LLM.

3 supporting quotes

“fundamentally is the main issue that we faced is the latency. You all know that the travel industry when you shop between Dubai to London you might be getting quite a lot of offers response”transcript, stated

“you might be getting quite a lot of offers response like a 2,000 plus offers from the different airline fly in between.”transcript, stated

“you have to convert that into multiple chunks and the multiple chunks into a pagenated responses.”transcript, stated

Gotchas (what bit them)

Travel APIs create large, latency-sensitive payloads that are hard for agents to handle naively.

Root cause: Flight shopping can return thousands of offers and requires strict orchestration across multiple APIs.

Resolution: Use supervised orchestration, domain prompts, and API-specific sub-agents rather than one general chat flow.

“Key challenges included managing latency with large API responses (2000+ flight offers), orchestrating multiple APIs in a pipeline, handling industry-specific IATA codes, and ensuring JSON formatting consistency.”summary, stated

Evaluation

The source reports development duration and deployment posture rather than public accuracy metrics.

Metrics: 3-4 month development · production deployment · latency optimization

“The system took 3-4 months to develop with AWS support and represents a shift from manual UI interactions to conversational AI-driven travel experiences.”summary, stated

Outcomes

TPConnects shifted legacy UI/API workflows toward conversational travel experiences.

Vendor/AWS presentation; outcomes are qualitative in the available transcript summary.