Conversational AI booking agent for inbound voice via Amazon Connect

A voice agent that handles the entire booking from start to finish.

We added a conversational AI agent as a new path inside the company’s existing Amazon Connect setup. Callers speak naturally. Amazon Lex transcribes what they say and catches the basic intent. Then the smart part begins: Claude Haiku quickly classifies the request, while Claude Sonnet manages the deeper reasoning and coordinates the steps.

The agent searches live inventory, talks through the options with the caller, adjusts based on their preferences, and completes the booking end-to-end. It sends a secure payment link by text, confirms the reservation through the company’s Payment API, and triggers the confirmation email — all while the caller stays on the phone. No new accounts. No awkward handoffs. No repeating information.

The system remembers the full conversation in DynamoDB and pulls in policies and rules from a Bedrock Knowledge Base. It gets smarter with every call.

ORCHESTRATION
Moving from LangChain to AWS Strands and Agent Core.

We started with LangChain because it handled tool calling and context well. When AWS introduced Agent Core as part of the Strands framework, we switched. The built-in memory management simplified session handling, and the tighter integration with Connect, Lambda, and DynamoDB reduced what we had to maintain ourselves. For a client that needed everything on AWS, keeping the orchestration inside their ecosystem was the cleaner choice.

LATENCY
Keeping response times to 2–3 seconds with a practical workaround.

Transcription and text-to-speech already take 1–2 seconds before the model even sees the input. That left little room for the AI to respond. True streaming wasn’t ready yet, so we built a simple workaround: the model streams its replies into DynamoDB, and Lex checks for complete sentences every few hundred milliseconds so the caller hears natural speech instead of silence. It’s not true streaming, but it solved the biggest pain point on voice calls.

MODEL SELECTION
Haiku for speed and Sonnet for deeper reasoning.

We tested newer AWS models hoping for faster performance and better integration, but they didn’t meet the quality needed for complex, multi-step booking logic. We stayed with Haiku for quick classification and Sonnet for selecting options and running the APIs. We continue to adopt newer versions as they become available.

SECURITY AND PAYMENTS
The AI only creates the link. It never touches payment data.

Customer identity is verified through the company’s own lookup system. Strict prompt guardrails prevent the model from storing or repeating sensitive details beyond the current call. Payment stays fully outside the AI layer using the company’s existing secure payment API.

Every booking that reaches a human agent carries the full cost of that interaction: salary, training, infrastructure, queue time. For a high-volume travel operation, routine bookings represent a significant share of that load, and most of them follow predictable patterns. A caller who knows what they want shouldn't need a person to complete it.

This system shifts that equation. When the agent handles the full transaction, human agents are freed for the calls that actually need them: itinerary disputes, irregular operations, customers in distress. That's not just an efficiency argument. It's a better allocation of skilled people.

The broader signal is architectural. Voice AI built on top of existing contact center infrastructure, without replacing it, means the path from prototype to production is shorter than most teams expect. Amazon Connect stays in place. Existing APIs stay in place. The AI layer fits in between. That lowers the barrier for any travel or hospitality operator sitting on legacy IVR infrastructure and wondering if a change like this is within reach.

Conversational AI for routine bookings is no longer experimental. The infrastructure exists, the models are capable, and the integration path is proven.