Summary

Please add a first-class WhatsApp listen-only / hooks-only mode for inbound messages.

The goal is to receive WhatsApp messages and emit message_received plugin hooks for archival/ETL plugins, without creating agent runs, calling an LLM, or producing any outbound WhatsApp activity.

Use case

Supplier price collection / archival.

A business may need to listen to hundreds of WhatsApp supplier groups and direct chats, archive price lists, parse attachments/text, and update internal systems. These messages should be processed by a plugin/hook pipeline, not by the conversational agent.

Routing every inbound WhatsApp message through the agent is both risky and expensive:

• unnecessary token usage;
• accidental agent sessions for noisy supplier groups;
• risk of unintended replies or reactions;
• hard-to-debug interaction between groupPolicy, dmPolicy, and plugin hooks.

Desired behavior

For selected WhatsApp accounts and/or routes:

• receive inbound WhatsApp group and direct messages;
• emit message_received plugin hooks;
• do not create agent sessions/runs;
• do not call any LLM/model;
• do not send replies;
• do not send typing indicators;
• do not send reactions/ack reactions;
• do not send read receipts;
• do not send pairing messages;
• allow group messages to reach hooks even when normal conversational group processing is disabled.

Suggested config shape

One possible shape:

{
  "channels": {
    "whatsapp": {
      "accounts": {
        "supplier_prices": {
          "enabled": true,
          "mode": "listenOnly",
          "emitMessageReceivedHooks": true,
          "agentPipeline": false,
          "sendReadReceipts": false,
          "reactionLevel": "off",
          "groupPolicy": "listenOnly",
          "dmPolicy": "listenOnly"
        }
      }
    }
  }
}

Or equivalent explicit fields:

• emitMessageReceivedHooks: true
• processWithAgent: false
• allowGroupsForHooksOnly: true
• allowDirectsForHooksOnly: true
• sendReadReceipts: false
• sendTyping: false
• sendReactions: false

Current workaround / pain points

Today this requires local runtime patching or fragile configuration:

1. Group messages may be blocked by access control (groupPolicy: disabled) before message_received hooks can see them.
2. Direct messages need to reach hooks but must return before the agent/reply pipeline.
3. Hook opt-in boundaries are not obvious: plugin config vs channel/account config can be confusing.
4. It is hard to guarantee "no tokens, no replies, hooks only" as a supported invariant.

Acceptance criteria

• Incoming WhatsApp group messages can reach plugin hooks while normal group replies remain disabled.
• Incoming WhatsApp direct messages can reach plugin hooks while normal DM replies remain disabled.
• No agent run/session is created for listen-only messages.
• No LLM/model call happens.
• No outbound WhatsApp activity happens: no replies, read receipts, typing, reactions, polls, pairing messages.
• Status/health clearly shows listen-only accounts as connected and hook-capable.
• Config validation and docs explain where hook opt-in belongs.

Why this matters

This would make WhatsApp useful as a safe ingestion channel, not only as a conversational channel. It would also remove the need for downstream users to patch runtime internals to build read-only archival workflows.