Building GraceSoft Sentinel Concierge: From WhatsApp Bot to Production Booking Agent
I spent the last stretch building GraceSoft Sentinel Concierge — a WhatsApp-first concierge agent designed to handle customer enquiries, FAQs, bookings, and business handover without requiring users to download another app.
What started as “a simple WhatsApp assistant” quickly turned into a full production exercise in systems design, operational resilience, and the kind of edge-case engineering that only shows up when real users start sending messy messages.
This is the dev log of what I built, what broke, and what I learned.
What GraceSoft Sentinel Concierge Is
GraceSoft Sentinel Concierge is a WhatsApp concierge agent for service businesses.
Its job is simple:
- answer FAQs
- detect booking intent
- 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 than that.
This 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 — webhook and API layer
- TypeScript — typed flows and safer service boundaries
- Prisma — schema and database access
- MySQL — persistent booking and business data
- Redis — ephemeral booking state, session memory, dedupe, rate limiting
- Google Calendar API — slot availability + booking sync
- Docker — local + deployment consistency
- Railway — deployment and runtime hosting
This stack gave me the flexibility to move fast without overengineering 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 + MySQL setup
- Redis-backed session state
- basic FAQ routing
- structured logging with PII redaction
Phase 2: Intent + Handover
- FAQ intent matching
- booking intent detection
- fallback confidence handling
- business handover escalation
- manual help command routing
Phase 3: Booking Engine
- date/time extraction from natural messages
- booking slot generation
- preferred-time ordering
- invalid date rejection
- timezone-safe slot formatting
- Google Calendar booking sync
Phase 4: Ops Hardening
- webhook dedupe
- Redis reconnect resilience
- startup health probes
- deployment readiness checks
- traceable logs
- prompt injection safety
- rate limiting
Phase 5: Business Logic Hardening
- public holiday awareness
- “day in lieu” logic
- weekday/flexi-hours mapping
- legal pages
- booking cancellation TODOs
- human-readable booking references
At this point, it stopped being “just a bot.”
It became a production system.
The Hard Parts (and What Broke)
This was the real work.
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 — which is also where most “AI agent” demos quietly fall apart. (DEV Community)
1. WhatsApp Is Not a Clean Interface
Users do not send clean structured input.
They send:
- “tmr 3ish can?”
- “this sat after lunch”
- “book for next week maybe”
- “actually nvm can cancel”
Natural language booking sounds easy until you have to convert vague intent into deterministic business actions.
The challenge wasn’t understanding language.
The challenge was deciding when not to act.
That meant building:
- ambiguity thresholds
- safe fallbacks
- clarification loops
- 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
- partial confirmations
Most of the complexity in Sentinel Concierge came from one thing:
making sure the system never confidently books the wrong thing.
This meant spending more time on:
- slot filtering
- booking validation
- idempotency
- human-readable confirmation states
…than on the chatbot itself.
3. Webhooks Are Messy in Production
Webhook systems are noisy.
Retries happen.
Duplicate events happen.
Out-of-order events happen.
A clean local demo does not prepare you for production webhook behaviour.
I had to add:
- dedupe protection
- replay-safe handling
- startup resilience
- Redis reconnect recovery
- safer initialization 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 was not the WhatsApp layer.
The product was state management.
WhatsApp is just the interface.
The real system is:
- what the user already said
- what step they’re in
- whether they’re asking or confirming
- whether the system is waiting for clarification
- whether escalation already happened
- whether the booking should still be considered active
That changed how I designed everything.
Redis stopped being “nice to have” caching.
It became the operational backbone of the conversation flow.
5. “AI” Was the Least Interesting Part
The most useful lesson from building this:
the intelligence was not in the model.
It was in:
- routing
- safeguards
- confidence thresholds
- fallback rules
- operational boundaries
- deterministic business logic
The LLM helped with interpretation.
The system did the real work.
That distinction matters.
A lot of “AI product” demos are really just prompt wrappers.
This project became useful only when the operational logic became stronger than the prompt.
What I Learned
A few things became very clear while building this.
1. The happy path is a lie
The happy path is the demo.
The product is everything outside it.
2. Operational resilience matters more than clever prompts
Prompt quality matters.
But retries, dedupe, health checks, and state recovery matter more.
3. Most AI systems fail at boundaries
Not generation.
Boundaries.
When to ask.
When to wait.
When to escalate.
When to stop.
That’s the real product.
4. Booking systems are trust systems
Users forgive slow replies.
They do not forgive wrong bookings.
Reliability matters more than speed.
What’s Next
Next up for Sentinel Concierge:
- booking cancellation flow
- rescheduling flow
- admin controls
- booking audit history
- business-facing dashboard
- analytics on drop-off / escalation / booking completion
- multi-business tenancy
The WhatsApp layer works.
Now the real product work begins.
Final Thought
GraceSoft 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.
And honestly?
That was the most useful part of building it.