Building a Production WhatsApp AI Agent: Architecture That Actually Works

Everyone demos a WhatsApp chatbot. Few run one in production with real customers sending real messages 24/7. After 18 months of running SARA — an open-source WhatsApp AI agent serving businesses across 20 industries — here's what we learned about architecture that survives contact with reality. Why WhatsApp? The numbers are simple: 2B+ monthly active users 60% of SMB customers prefer messaging over calling 98% open rate (vs 20% for email) But WhatsApp is NOT just another chat channel. It has unique constraints that break naive implementations. Architecture Overview WhatsApp (WAHA) → Bridge (:3008) → SARA API (:3006) → AI Provider Chain → Tool Dispatcher ↓ Groq → Cerebras → SambaNova → Mistral The Provider Fallback Chain Single-provider AI is a production risk. We use a 4-provider chain: Primary: Groq (fastest, free tier) ↓ fail Fallback 1: Cerebras ↓ fail Fallback 2: SambaNova ↓ fail Fallback 3: Mistral (paid, always works) Each provider gets 2 retries with exponential backoff before failover. Result: 99.7% uptime over 6 months with $0 inference cost (free tiers). Tool Calling: Not Just Chat SARA doesn't just answer questions. She executes actions: create_reservation — books a table with date normalization ("domani alle 8" → 2026-08-10T20:00) check_inventory — queries stock levels generate_invoice — creates a PDF from database records schedule_appointment — manages calendar slots The dispatcher maps 30+ tools to handlers with an autonomy gate: User message → Intent classification → Risk assessment → Tool execution ↓ Low risk: execute immediately Medium: execute + notify owner High: ask for confirmation first You do NOT want your AI agent booking a catering order for 500 people without human approval. PII Handling Messages contain names, phone numbers, addresses. Our pipeline: Anonymize before sending to LLM (replace "Mario Rossi" → "[PERSON_1]") Process with anonymized data De-anonymize tool calls only (the reservation needs the real name) Never log PII in plain text Session Management WhatsApp doesn't have "sessions" — it's just a stream of messages. We manage context with: Sliding window: last 20 messages as context Business context injection: CRM data, menu, pricing injected per-tenant Cross-conversation memory: the agent remembers "last time you ordered the risotto" Self-Hosting vs Cloud SARA runs on a single VPS (4 vCPU, 8GB RAM): Component Resource WAHA (WhatsApp Web) ~500MB RAM Bridge service ~50MB SARA API ~200MB PostgreSQL + pgvector ~2GB Total ~3GB No GPU needed — inference is offloaded to cloud providers (Groq, etc.). The Hardest Bugs WhatsApp session contention — running two instances with the same number = instant logout for both. We learned this the hard way. Date parsing across languages — "dopodomani" (Italian for "day after tomorrow") + timezone handling + business hours awareness. This alone took weeks. Message ordering — WhatsApp doesn't guarantee delivery order. Our bridge queues and re-orders by timestamp. Open Source SARA is AGPL-3.0 on GitHub: github.com/Alessandro114/sara Self-host it, extend it, build your own vertical agent on top. Cloud-only features (multi-tenant, white-label, analytics) stay in the commercial version. The 20 industry-specific agent definitions are also open source: scala-agent-definitions (Apache-2.0). What's Next Proactive agents — don't wait for messages, reach out when something needs attention ("Your reservation for tonight has a conflict") Cross-agent events — when DineOS agent sees a large booking, TravelOS agent checks nearby hotel availability Voice — WhatsApp voice messages → STT → agent → TTS → voice reply Running AI in production is 10% model quality and 90% engineering. Follow for more war stories.