Stop Building Chatbots. Start Building Message-Driven Systems.

Most teams building on WhatsApp are building chatbots. Multi-turn conversations, intent trees, fallback loops — the whole nine yards.

But here's the thing: most of them don't actually need a chatbot.

They need a system that turns incoming messages into backend actions.

The Chatbot Trap

A hotel guest sends:

"Can I get extra towels in room 312?"

The typical chatbot approach:

Bot: Hi! How can I help you?
Guest: I need towels
Bot: Which room?
Guest: 312
Bot: How many towels?
Guest: ...just some towels
Bot: I didn't understand. How many towels would you like?

3 round-trips to extract 2 fields. The guest is annoyed. The developer is maintaining a conversation state machine. Everyone loses.

Messages Are Not Conversations

Here's the insight: most inbound messages already contain everything you need. You don't need to ask follow-up questions — you need to extract what's already there.

The shift is simple:

Message
  ↓
Analysis (single LLM call)
  ↓
Structured payload
  ↓
Backend action

One message in, one structured payload out. No conversation state. No dialog trees. No "I didn't understand."

What This Looks Like in Practice

The same message — "Can I get extra towels in room 312?" — processed as a message-driven system:

{
  "intent": "room_service_request",
  "confidence": 0.97,
  "actions": [
    {
      "type": "housekeeping.task.create",
      "payload": {
        "room": "312",
        "item": "extra towels"
      }
    }
  ],
  "suggested_reply": "Of course! Extra towels are on the way to room 312."
}

Your backend receives this via webhook. You create the task in your PMS. You send the reply. Done.

One message. One payload. One action.

The Architecture

Here's the full flow — from WhatsApp message to backend action:

WhatsApp (inbound message)
  ↓
Pre-filter (spam, noise — no LLM cost)
  ↓
Router (classify + route to the right agent)
  ↓
Agent (LLM call → structured output)
  ↓
Webhook (HMAC-signed payload to your app)
  ↓
Your backend (create task, update booking, send reply)

Each step is deterministic. The LLM is used once, for extraction — not for conversation. The output is a structured JSON payload your backend can trust.

Code, Not Config

Here's what triggering an agent looks like with the Ruby SDK:

require "whatsrb"

client = WhatsRB::Client.new(api_key: "wrb_live_xxx")

run = client.agents.run(
  agent_id: "agt_abc123",
  input: "Cancel booking #BK-4521"
)

puts run.output
# => { "intent" => "cancel_booking", "actions" => [...] }

Or with a simple curl:

curl -X POST "https://api.whatsrb.com/v1/agents/agt_abc123/runs" \
  -H "Authorization: Bearer wrb_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{"input":"Cancel booking #BK-4521"}'

You get back a structured payload. Every time. No conversation state to manage.

When Chatbots Make Sense (And When They Don't)

If the message already contains the intent and the data — you don't need a chatbot. You need a message-to-action pipeline.

Real Results

With this approach:

• No conversation state to maintain
• Single LLM call per message (~1-2s latency)
• Deterministic outputs your backend can trust
• 90%+ accuracy on intent + field extraction out of the box

This Is What We're Building

WhatsRB Cloud is a platform that turns WhatsApp messages into structured, actionable webhooks. No chatbot framework. No dialog trees. Just messages in, actions out.

Get early access →

Check out the API docs to see how it works under the hood.

Built with Ruby, Rails, and a healthy distrust of chatbots.