Every WhatsApp chatbot framework is broken. Here's what I built instead.

I've evaluated every open-source WhatsApp bot framework on GitHub. They all share the same fatal flaw. The Problem Nobody Talks About Most WhatsApp bot frameworks are glorified API wrappers. They handle message transport — receiving a text, routing it somewhere, sending a reply — and that's it. The "intelligence" layer is left entirely to you. You get a pipe. You get a webhook. You get some session management. And then you're on your own. The frameworks that do add AI make a different mistake: they duct-tape GPT onto the messaging pipe and call it "AI-powered." The pattern is always the same: receive message → append to conversation history → call openai.chat.completions.create() → send reply. It's generic. It's stateless in any meaningful business sense. It doesn't know what industry it's serving, what data it has access to, or what actions it's actually allowed to take. Here's the part that breaks me: none of these frameworks understand that a restaurant needs different tools than a law firm. A restaurant needs to check table availability, query allergens, create reservations, and handle cancellations. A law firm needs to schedule consultations, check document status, route inquiries by practice area. These are not the same problem. Treating them as "just chat" is the core architectural failure of every framework I've seen. And then there's the "enterprise" tier: Twilio Flex, Intercom, Freshchat. These charge $500–$2,000/month for what is fundamentally a prompt and a webhook wrapped in a dashboard. They're selling you infrastructure and calling it intelligence. The underlying model doesn't know your business. It can't execute actions in your systems. It's an expensive illusion. What's Actually Needed The shift that matters isn't from "no AI" to "has AI." It's from generic chat to domain-specific function calling. This is not a subtle distinction. Here's what a properly architected tool dispatcher looks like versus what everyone else ships: // Each vertical gets domain-specific tools const DINEOS_TOOLS = [ { name: 'check_availability', handler: checkTableAvailability }, { name: 'check_allergens', handler: checkMenuAllergens }, { name: 'book_table', handler: createReservation }, { name: 'cancel_reservation', handler: cancelWithPolicy }, { name: 'get_menu', handler: fetchLiveMenu }, ]; const LEGALOS_TOOLS = [ { name: 'schedule_consultation', handler: bookLawyerSlot }, { name: 'check_case_status', handler: queryCaseDB }, { name: 'route_inquiry', handler: classifyAndRoute }, ]; // vs the generic approach everyone else uses: const GENERIC_APPROACH = [ { name: 'chat', handler: askGPT }, // useless ]; When the model has access to real, domain-specific tools, it stops being a chatbot and starts being an agent. It can actually do things: query live inventory, write to your reservations database, check against your allergen tables, trigger workflows in your backend. That's the difference between a wrapper and a platform. Two other things that almost no framework handles correctly: PII protection and multi-provider failover. You are routing customer names, phone numbers, order histories, and medical information through third-party LLM APIs. That's a GDPR liability waiting to happen. And when OpenAI has an outage — which they do, routinely — your entire customer-facing AI goes dark. These aren't edge cases. They're production requirements. What I Built I got tired of the same conversation and built SARA — an open-source WhatsApp AI agent platform with 20 vertical-specific agent profiles, each with its own tool set, knowledge base, and autonomy configuration. The provider chain runs Groq → Cerebras → SambaNova → Mistral in sequence. If Groq is down or rate-limited, the system fails over to Cerebras automatically. All four providers have generous free tiers, which means the inference cost for most deployments is literally zero. No OpenAI dependency. No single point of failure. Each tenant gets their own RAG instance — a pgvector knowledge base populated with their menus, policies, product catalogs, or legal documents. The model isn't hallucinating from its training data; it's retrieving from the business's actual content. Every query is scoped to that tenant's data. The piece I'm most proud of is the autonomy gate: // Autonomy levels — not every action should be automatic enum AutonomyLevel { OFF, // AI suggests, human decides OBSERVE, // AI drafts, human approves SEMI_AUTO, // AI acts on low-risk, asks on high-risk FULL_AUTO // AI handles everything } // Risk classification before every action const classifyRisk = (tool: string, args: ToolArgs): RiskLevel => { if (tool === 'book_table') return RiskLevel.LOW; // reversible if (tool === 'process_refund') return RiskLevel.HIGH; // money moved if (tool === 'cancel_reservation') return RiskLevel.MEDIUM; return RiskLevel.LOW; }; // Gate checks: if action risk > autonomy level → ask human const autonomyGate = (tool: string, args: ToolArgs, level: AutonomyLevel) => { const risk = classifyRisk(tool, args); if (risk === RiskLevel.HIGH && level < AutonomyLevel.FULL_AUTO) { return { blocked: true, reason: 'requires_approval' }; } return { blocked: false }; }; Before every LLM call, PII is anonymized — names replaced with tokens, phone numbers stripped, emails masked. The model never sees raw customer data. After the response is generated, the PII is re-injected for the actual reply. This is not optional if you're handling real customer data at scale. The result: 20 vertical agents (DineOS for restaurants, LegalOS for law firms, ClinicOS for healthcare, RetailOS for e-commerce, and 16 more), each with 3–6 domain-specific tools, running on a zero-cost inference stack, with PII protection baked in at the transport layer. Stop Wrapping APIs and Calling It AI The entire WhatsApp bot ecosystem has optimized for the wrong thing: ease of connection, not quality of intelligence. Getting a message in and a message out is a solved problem. The unsolved problem is making the agent actually useful for a specific business context. Stop wrapping APIs and calling it AI. Build agents that actually understand the domain. SARA is open source under AGPL-3.0. Code, architecture docs, and agent definitions are at github.com/Alessandro114/sara.