Summary

Add optional WhatsApp service-conversation support to Hermes so an agent can contact providers like Movistar, receive replies in the same thread, and continue the conversation under explicit safeguards.

This is not meant to become generic WhatsApp outreach automation. The feature should be conservative by default and narrowly shaped for support/provider conversations.

Why

Current Hermes WhatsApp support already has the transport pieces for outbound messaging, but not the policy and discovery pieces needed for safe real provider conversations.

Verified current behavior:

• scripts/whatsapp-bridge/bridge.js
  • POST /send already sends arbitrary { chatId, message }
  • POST /send-media already sends native media to arbitrary chatId
  • GET /chat/:id resolves a known chat ID
• gateway/platforms/whatsapp.py
  • send(chat_id, content, ...) already calls the bridge /send

The actual blockers are:

1. inbound replies from third parties are filtered out unless the sender matches the static allowlist
2. there is no recent-chat discovery UX for selecting provider threads safely
3. there is no explicit service-chat policy layer (draft-first, approved chats, revoke/pause, etc.)

Use case

• user asks Nagatha/Skippy/Hermes to contact a provider over WhatsApp
• first contact is drafted and approved by default
• provider replies in the same WhatsApp thread
• Hermes receives the reply and continues in the same session/thread
• user can pause/revoke the service conversation at any time

Product constraints

This feature should be:

• optional
• off by default
• conservative in defaults
• explicit per-chat or per-policy
• auditable
• bounded with smart controls / rate limits

This feature should not rely on global wildcard allowlists like WHATSAPP_ALLOWED_USERS=*.

Safeguards required

Safe defaults

• feature disabled by default
• unknown inbound chats stay blocked by default
• no automatic promotion of random chats into autonomous conversations

Explicit chat-level policy

Suggested config shape:

whatsapp:
  service_conversations:
    enabled: false
    default_mode: draft_first
    approved_chats: []
    approved_patterns: []
    allow_agent_initiated_service_chats: false
    auto_promote_replied_to_chats: false
    max_new_service_chats_per_day: 3
    require_explicit_approval_for_first_contact: true
    allow_media: true

First-contact restrictions

• first outbound to an external provider should be draft-first by default
• autonomous follow-up should only happen in explicitly approved service chats

Auditability

Log service-conversation state changes such as:

• first contact approved/sent
• chat promoted to approved service chat
• policy changed to draft-only / autonomous / paused
• service chat revoked

Blast-radius limits

At minimum:

• max new service chats per day
• optional max auto-sends per chat per hour
• easy revoke/pause path

Proposed phased implementation

Phase 1 — safe foundation

• add bridge GET /chats recent-chat discovery
• add WhatsApp target normalization / discovery for send_message
• add config scaffolding for service conversations
• keep default inbound safety posture conservative

Phase 2 — controlled service-chat policy

• allow inbound replies for explicitly approved service chats
• support draft-first first contact
• support optional promotion after approved first contact / reply
• add audit logging and rate controls
• ensure thread/session continuity

Likely files

• scripts/whatsapp-bridge/bridge.js
• scripts/whatsapp-bridge/allowlist.js if needed
• gateway/platforms/whatsapp.py
• tools/send_message_tool.py
• gateway/channel_directory.py
• gateway/config.py
• tests covering discovery, target resolution, policy gating, and session continuity

Acceptance criteria

1. Hermes can list recent WhatsApp chats safely
2. Hermes can target a provider chat by phone/JID/recent-chat name
3. Unknown inbound external chats remain blocked by default
4. Approved service chats can receive replies into Hermes
5. First contact requires approval by default
6. Provider replies attach to the same Hermes conversation thread
7. Service-chat approval can be revoked cleanly

Notes

I have a fuller local design/implementation plan and intend to send it to Codex for review before the Claude two-phase build-out. This issue is the product/spec anchor first.