Skip to main content

AI Spam Gatekeeper

A tenant-defined, AI-classified spam filter for inbound WhatsApp conversations. The tenant defines what spam means to their business (pre-built categories + a free-text definition); the AI Agent classifies each new inbound conversation against that definition; high-confidence spam is silently resolved and the contact is blocked so every future message from that sender costs nothing — before any billable AI reply is ever sent.

The motivating event: from 1 October 2026, Meta charges per WhatsApp service message, including replies produced by Qontak's AI Agent, with no volume discount (Bifrost squad, meta-whatsapp-pricing-oct-2026, Epic BIF-8755 — ~14–15B IDR/month newly billable across Qontak's client base). Every spam conversation the AI politely answers today becomes pure negative margin once that billing starts. Qontak has no tenant-facing spam product today — the only existing mechanism (spam_protection in chatbot BE) is a dormant heuristic feature with zero UI.

Master index (ANCHOR)​

  • ai-spam-gatekeeper-anchor.md — the ANCHOR PRD: the initiative master index (identity, Phase Index, north-star metrics, initiative-level decisions). It carries no acceptance criteria of its own (those live in the phase PRDs), so it sits at the initiative root rather than under prds/.

Phases​

PhaseScopeStatusEpic
Phase 1 — Silent Classification & BlockClassify new inbound conversations against a tenant-defined spam policy at the shared inbound hook; silently resolve + block high-confidence spam; tag ambiguous cases (fail-open); supervisor alert on every auto-block; channel-level settings UIPRD draftTBD
Phase 2 — Interrogation & Meta Blocking≤3-turn AI clarifying interrogation for ambiguous cases (AI Agent tenants only); human review queue; tenant-definition feedback loop; Meta Block Users API integrationPlannedTBD

Cross-repo & dependencies​

  • chatbot (Rails BE) — inbound-hook classification (reusing Repositories::Gpt::Completion, no DSAI dependency), RESOLVE_AI_SPAM closed_reason, channel-level spam_policy config, "suspected spam" tagging. Primary surface for Phase 1.
  • hub-core / hub-chat (Omnichannel) — the core ContactBlock/GenericContactBlock system and the inbound billing short-circuit (wa_cloud/interactors/customer_send_message.rb) are reused as-is. But the block-provenance layer is NOT pure reuse (corrected via ground-prd, 2026-07-14): source is a real column on contact_blocks but is silently dropped by Repositories::Contacts::Block::Create#build_params and absent from Entities::ContactBlock entirely, and hub-chat's block/unblock modals fetch zero attribution data today. Persisting + exposing source (and chatbot passing it through Hub::ChatService::Contacts#block, which today sends { room_id } only) is confirmed net-new, cross-squad, blocking work — see the Phase 1 PRD's Section 13 for the full breakdown.
  • chatbot-fe / qontak-designer — net-new "Spam filter" settings surface (Chatbot settings → AI configuration). Zero existing spam/moderation UI or design pattern exists in either repo today — captured as a blocking P0 design dependency on Design (Wulan's team) for a change-request spec.
  • notification-service (Go, Broadcast squad) — reuses the ai_agent_alert category being built for the AI Agent Live Monitoring initiative. Grounding correction: that initiative is still PRD-draft with a minted Epic (BOT-4569) but zero code exists yet in either chatbot or notification-service — tracked as a blocking dependency (not "non-blocking reuse" as earlier phrasing implied), since the Phase 1 supervisor-alert story is a Must Have.

Scope Changes​

  • Backend — chatbot: inbound-hook classifier call, RESOLVE_AI_SPAM closed_reason, channel-level spam policy config, suspected-spam tagging, supervisor-alert trigger, plus new source/reason fields on the existing block-call payload; hub-core: net-new — persist source in the block repository and expose it via Entities::ContactBlock (confirmed via grounding, not pure reuse).
  • Frontend — chatbot-fe: new "Spam filter" section in Chatbot settings; hub-chat: net-new — the block/unblock modals need a new attribution field wired through before they can relabel for the "Bukan spam" undo flow (confirmed via grounding, not a pure copy relabel).
  • Data — spam-classification and auto-block events feed reporting for the initiative's success metrics (messages avoided, false-positive rate, tag precision).

QA Lane​

Not yet assessed — run qa-lane-advisor after Phase 1 PRD reaches READY. Likely signals: this initiative auto-blocks contacts (an irreversible-by-default, unattended action against real customer data) and interacts with the same real-time supervisor-alert plumbing that put AI Agent Live Monitoring in Lane B — expect the same classification pending the formal assessment.

Contents​

  • prds/ — phase PRDs (each with its own ACs → Jira Epic) land here.
  • rfcs/ — technical design proposals. Phase 1 BE RFC drafted 2026-07-14 (backend scope: classifier + gate + verdict worker + cross-repo provenance contract; FE settings-UI RFC deferred until the design dependency lands).
  • tests/ — E2E / acceptance test specs.