The WhatsApp broadcast that started talking to itself: Eliminating auto-responder loops

The Absence of `Auto-Submitted` Headers on WhatsApp

In conventional messaging protocols, machine-generated traffic carries explicit structural headers:

• SMTP Email: RFC 3834 Auto-Submitted: auto-replied, Precedence: bulk.
• Slack API: bot_id parameter present on message payload.
• Telegram Bot API: User.is_bot: true.

The Meta WhatsApp Cloud API provides no such header. An inbound webhook payload delivers identical fields (from, wa_id, text) whether written by a human typing on a keyboard or generated by an Android out-of-office auto-reply app:

{
  "object": "whatsapp_business_account",
  "entry": [{
    "changes": [{
      "value": {
        "messaging_product": "whatsapp",
        "contacts": [{ "profile": { "name": "Customer" }, "wa_id": "34600000001" }],
        "messages": [{
          "from": "34600000001",
          "id": "wamid.HBgL...",
          "timestamp": "1717584000",
          "text": { "body": "Thank you for reaching out! We are currently unavailable." },
          "type": "text"
        }]
      }
    }]
  }]
}

// One signal, never a verdict. Courtesy a person uses ("shukriya", "gracias por tu mensaje")
// was on an earlier version of this list and classified real customers as bots.
const AUTOREPLY_PATTERNS = [
  /unknown\s+input\s+type\s+received/i,
  /kindly\s+reply\s+with\s+a\s+valid/i,
  /thank\s+you\s+for\s+(reaching\s+out|contacting|messaging)\b/i,
  /gracias\s+por\s+(escribirnos|contactarnos)/i,
  /we\s*(?:['’]\s*re|\s+are)\s+(?:currently\s+)?(?:unavailable|away|closed)/i,
  /out\s+of\s+(?:the\s+)?office/i,
  /fuera\s+de\s+(?:la\s+)?oficina/i,
  /\bauto[-\s]?reply\b|automated\s+(?:response|message|reply)|mensaje\s+autom[áa]tico/i,
  /\b(?:office|business|working)\s+(?:hours|timings?)\b/i,
  /horario\s+de\s+atenci[óo]n/i,
];

// In classifyCorrespondent: the phrase counts only on a reply to a campaign send, and
// only two independent signals (phrase, timing, exact repeat) make a verdict.
if (signals.length >= 2) return { kind: CORRESPONDENT.AUTOMATED, /* ... */ };

Broadcast Attribution & Interactive Immunity

The broadcast context is read from our most recent outbound message only: whether the campaign ledger (outbound_messages) holds a campaign for it. An earlier version read the conversation’s origin_campaign_id, which is set once and never cleared, so a conversation that a campaign opened months ago kept being treated as a fresh broadcast reply.

Crucially, interactive button taps and WhatsApp Flow completions take unconditional priority (isInteractive = true). No matter how fast an interactive payload arrives, a button press is treated as HUMAN 100% of the time.

Generative LLM Prompt Refusal Guards

Even if an automated text bypasses regex matching, generative AI models must be restrained from entering conversational loops. Klaros adds an explicit AUTO-RESPONDER GUARD to the model’s instructions (src/services/ai-auto-reply.mjs):

AUTO-RESPONDER GUARD: If the incoming message is plainly another business’s automatic reply to a
template message we sent (an out-of-office or away notice, "unknown input type received", a canned
receipt naming THEIR business) AND it asks us nothing, do not reply: return
{"canAnswer": false, "reply": "", "action": "handoff"}. A person being polite ("thank you",
"shukriya", "thanks for reaching out") or asking anything at all is NOT an automatic reply: answer them.

Empirical Verification & Test Proofs

The behaviour described here is covered by tests that run against a real SQLite database built from the production migrations:

# The classifier, with negative controls (people who must never read as machines)
node --test test/uni-cloud-broadcast-autoresponder.test.mjs

# The classifier as the inbound handler actually calls it
node --test test/uni-cloud-correspondent-self-match.test.mjs