Most "AI in hospitality" articles talk about guest experience. Fewer talk about what's actually happening under the hood when a guest messages a hotel on WhatsApp at 2am and gets a real, useful answer in three seconds. As a dev, that's the more interesting question — so let's break down the actual architecture behind an AI concierge system, using HuemanAI as a working example.
The problem isn't the LLM
If you've built anything with an LLM in the last two years, you already know prompting a model to sound helpful is the easy 20%. The hard 80% is everything around it:
Routing a message from five different channels (voice, WhatsApp, SMS, email, web chat) into one consistent conversation state
Grounding the model's answers in live data — actual room availability, not a stale cache
Writing back to a hotel's PMS (property management system) without creating double bookings
Knowing when not to answer, and escalating to a human instead
None of that is prompt engineering. It's integration engineering, and it's where most "AI concierge" demos fall apart the moment they leave the sandbox.
A typical request flow
Here's roughly what happens when a guest sends "can I get a late checkout tomorrow, flight's not till 6pm":
Guest message (WhatsApp/SMS/Voice/Web/Email)
│
▼
Channel adapter → normalizes to a common message schema
│
▼
Intent + entity extraction (LLM call, function-calling style)
│
▼
Live PMS query (check room status, existing checkout time, availability)
│
▼
Decision: auto-approve / needs staff approval / decline with explanation
│
▼
Write-back to PMS + confirmation sent to guest
│
▼
Logged to staff dashboard for visibility
The interesting engineering problem is that steps 3 and 4 have to happen before the model is allowed to promise anything to the guest. A naive implementation lets the LLM generate a confident "Sure, that's all sorted!" without ever checking whether the room is actually available for a late checkout — which is how you get angry guests and worse reviews than if you'd never automated anything at all. Function-calling patterns (tool use, structured outputs, whatever your framework calls it) exist specifically to prevent this class of bug.
Why multi-channel is harder than it sounds
Each channel has its own quirks that leak into your architecture whether you want them to or not:
Voice needs low-latency streaming responses (nobody wants three seconds of dead air), plus speech-to-text/text-to-speech in the loop, which adds its own failure modes.
WhatsApp has strict messaging-window policies (24-hour session rules, template approval) that constrain when you can proactively message a guest.
Email is asynchronous by nature, so your state machine needs to tolerate replies arriving hours later, out of order, sometimes to old threads.
A system like HuemanAI's AI Concierge has to normalize all of that into one guest profile and one source of truth, so a guest who starts a conversation on the website chat and follows up by phone isn't treated as two different people with two different contexts. That identity resolution problem — matching a phone number, an email, and a chat session to the same guest — is a surprisingly large chunk of the actual engineering effort.
The escalation logic matters more than the automation
The part that's easy to underrate: deciding when the AI should not handle something. A well-built system needs confidence scoring on intent classification, plus hard-coded guardrails for categories that always route to a human — medical concerns, complaints, anything involving a refund above a threshold. Getting this wrong in either direction is costly: escalate too much and you haven't saved anyone time; escalate too little and you get a bot confidently mishandling a guest emergency.
What this means if you're building something similar
If you're a dev working on a similar vertical AI agent — hospitality, healthcare scheduling, field service — a few lessons generalize well:
Treat the LLM as a component, not the whole system. The model handles language; your business logic handles correctness.
Never let the model write to a source of truth without a validation layer in between. Confirm availability before generating the confirmation message, not after.
Design your data model around identity resolution early. Retrofitting "which guest is this, across which channels" onto an existing system is painful.
Build escalation paths as a first-class feature, not an afterthought. It's the difference between guests trusting the system and guests trying to route around it.
If you want to see a production example of this stack applied specifically to hotels, HuemanAI has a public write-up of their approach at huemanai.co.uk worth a look — it's a decent case study in what "AI in production" looks like once you get past the demo.
Top comments (0)