Case study: shipping an agentic WhatsApp assistant for a real business
The end-to-end architecture of a customer-facing agent — FSM orchestration, LLM intent handling, Hinglish support, RAG, and the WhatsApp Business API — and the lessons from putting it in front of real users.
Everyone demos agents; far fewer ship one to real customers on a channel as unforgiving as WhatsApp. Here's the architecture of a customer-facing assistant I worked on — anonymised — and, more usefully, the decisions that made it reliable enough to trust with real conversations.
The channel: WhatsApp Business API
Messages arrive via webhook and you reply within a session window; proactive messages need pre-approved templates. Those constraints — plus the fact that users expect near-instant, chatty replies — shaped everything downstream, especially the latency budget.
FSM orchestration, not a free-roaming agent
The conversation was run by an explicit state machine — greet, collect details, answer, act, hand off — not a loop that let the model drive. The LLM did what it's good at inside each state; the code owned the flow (this is the least-agency principle in practice). Reliability came precisely from not giving the model the steering wheel.
LLM for intent and Hinglish
Real users type in Hinglish — Hindi and English mixed, transliterated, misspelled. That's exactly where rules fall apart and an LLM shines: it classified intent and generated replies in the user's own register, which no keyword matcher could have done. This was the part of the system that genuinely needed a model.
RAG for grounded answers
Product and policy questions were answered from a retrieval layer over the business's own documents, so replies stayed current and grounded rather than hallucinated (see the RAG posts). Retrieval was scoped so the assistant only ever pulled from the right business's content.
What actually mattered in production
- Per-state tool allowlists — the assistant could only take actions valid for its current state.
- A clean human-handoff path — when confidence was low or the user asked, it escalated rather than guessed.
- A real latency budget — chat UX dies if replies lag, so model and retrieval choices were made for speed.
- Evals on real transcripts — quality was measured against actual conversations, not a demo script.
- Injection defence — user text was treated as data, never as instructions (see the prompt-injection post).
The interesting part of a production agent isn't the model — it's the state machine, the guardrails, and the handoff around it that make it safe to hand a real customer.