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.
Top comments (0)