I Built a WhatsApp Booking Agent — The Hard Part Wasn't AI
I spent the last stretch building GraceSoft Sentinel Concierge. It’s a WhatsApp-first concierge agent that handles customer enquiries, FAQs and bookings, and hands conversations over to the business, all without users needing to download another app.
What started as “a simple WhatsApp assistant” quickly turned into a full production exercise. It covered systems design, operational resilience and the kind of edge cases that only show up once real users start sending messy messages.
This is the dev log of what I built, what broke and what I learned.
What Sentinel Concierge is
Sentinel Concierge is a WhatsApp concierge agent for service businesses. Its job is simple:
- answer FAQs
- detect when someone wants to book
- suggest available slots
- create bookings
- escalate to a human when confidence drops
- avoid sounding robotic while doing all of the above
Under the hood, it’s doing much more. It became less of a chatbot project and more of a stateful booking orchestration system, with WhatsApp as the UI.
Stack
I kept the stack intentionally lean:
- Node.js + Express: the webhook and API layer
- TypeScript: typed flows and safer service boundaries
- Prisma: schema and database access
- MySQL: persistent booking and business data
- Redis: short-lived booking state, session memory, dedupe and rate limiting
- Google Calendar API: slot availability and booking sync
- Docker: consistency between local and deployed environments
- Railway: deployment and runtime hosting
This let me move fast without over-engineering too early.
What I built
Over a few intense iterations, Sentinel Concierge grew from a webhook listener into a proper booking system.
Phase 1: Foundation. WhatsApp webhook handling, environment validation, Prisma and MySQL setup, session state in Redis, basic FAQ routing, and structured logging with PII redaction.
Phase 2: Intent and handover. Matching messages to FAQs, detecting booking intent, handling low-confidence fallbacks, escalating to the business, and routing a manual help command.
Phase 3: Booking engine. Pulling dates and times out of natural messages, generating booking slots, ordering them by preferred time, rejecting invalid dates, formatting slots safely across timezones, and syncing bookings to Google Calendar.
Phase 4: Ops hardening. Webhook dedupe, Redis reconnect resilience, startup health probes, deployment readiness checks, traceable logs, protection against prompt injection, and rate limiting.
Phase 5: Business logic hardening. Awareness of public holidays, “day in lieu” logic, mapping of weekday and flexi hours, legal pages, booking cancellation TODOs, and booking references people can read.
At that point it stopped being “just a bot” and became a production system.
The hard parts (and what broke)
The code was rarely the hardest part. The hard part was making the system behave correctly under real-world ambiguity. That’s where most of the engineering time went, and it’s also where most “AI agent” demos quietly fall apart.
1. WhatsApp is not a clean interface
Users don’t send clean, structured input. They send things like:
- “tmr 3ish can?”
- “this sat after lunch”
- “book for next week maybe”
- “actually nvm can cancel”
Booking through natural language sounds easy until you have to turn vague intent into definite business actions. Understanding the language wasn’t the challenge. Deciding when not to act was. That meant building ambiguity thresholds, safe fallbacks, clarification loops and escalation rules.
The hardest part of conversational systems is rarely parsing text. It’s preventing bad automation.
2. Booking logic is mostly edge cases
Booking systems sound simple until you hit reality: timezone drift, invalid dates, public holidays, day-in-lieu holidays, flexi business hours, conflicting calendar events, duplicate booking attempts and partial confirmations.
Most of the complexity came from one goal: making sure the system never confidently books the wrong thing. That meant spending more time on slot filtering, booking validation, idempotency and confirmation states people can read than on the chatbot itself.
3. Webhooks are messy in production
Webhook systems are noisy. Retries happen, duplicate events happen, and events arrive out of order. A clean local demo doesn’t prepare you for how webhooks behave in production.
I had to add dedupe protection, handling that’s safe to replay, startup resilience, recovery when Redis reconnects, and safer initialisation for Prisma. This was one of the biggest shifts in the project: moving from “it works locally” to “it survives production.”
4. The real product was state
The biggest architectural shift was realising the product wasn’t the WhatsApp layer. The product was state management. WhatsApp is just the interface. The real system tracks:
- what the user already said
- what step they’re on
- whether they’re asking or confirming
- whether the system is waiting for clarification
- whether escalation already happened
- whether the booking should still count as active
That changed how I designed everything. Redis stopped being a nice-to-have cache and became the backbone of the conversation flow.
5. “AI” was the least interesting part
The intelligence wasn’t in the model. It was in the routing, safeguards, confidence thresholds, fallback rules, operational boundaries and business logic that always behaves the same way. The LLM helped with interpretation, and the system did the real work.
That distinction matters. A lot of “AI product” demos are really just prompt wrappers. This project only became useful once the operational logic was stronger than the prompt.
What I learned
- The happy path is a lie. The happy path is the demo. The product is everything outside it.
- Operational resilience matters more than clever prompts. Prompt quality matters, but retries, dedupe, health checks and state recovery matter more.
- Most AI systems fail at boundaries, not generation. The system has to know when to ask, when to wait, when to escalate and when to stop. That’s the real product.
- Booking systems are trust systems. Users forgive slow replies. They don’t forgive wrong bookings. Reliability matters more than speed.
What’s next
- Cancellation flow
- Rescheduling flow
- Admin controls
- Booking audit history
- A dashboard for businesses
- Analytics on drop-off, escalation and booking completion
- Support for multiple businesses
The WhatsApp layer works. Now the real product work begins.
Final thought
Sentinel Concierge started as a WhatsApp AI assistant. It turned into a lesson in production systems, conversational state, and the uncomfortable truth that most of the work in “AI products” has very little to do with AI. That turned out to be the most useful part of building it.
Originally published on DEV.