hermes - 💡(How to fix) Fix Slack: bot-to-bot messages in shared threads silently dropped even with allow_bots=all

Summary

When a bot/app user (e.g. another agent in the same Slack workspace) posts in a thread where the Hermes bot is also participating, Hermes silently drops their messages — even with slack.allow_bots: all configured. The result: Hermes-bot-to-other-bot conversations in shared threads are impossible without manual paste-bridging.

Reproduction

1. Two Slack apps installed in the same workspace: Hermes (this agent) + a second bot (in my case, "Liatrio Brain" at U0AKB7YLP1V)
2. Human invites both into a thread by @-mentioning each in turn
3. Hermes responds to the human's @-mentions ✓
4. The other bot @-mentions Hermes in the same thread
5. Expected: Hermes receives the bot's message, processes it as thread context, responds
6. Actual: Hermes never sees the bot's message. Subsequent thread-context injection (via Slack Web API history fetch) surfaces the bot's identity prefix but with empty body content.

What I've already verified

Two filter layers needed to be opened for this to work at all:

1. gateway/platforms/slack.py:1778-1793 — bot-subtype filter

   • Default SLACK_ALLOW_BOTS=none silently drops every event.get("bot_id") or subtype == "bot_message" event.
   • Setting slack.allow_bots: all in ~/.hermes/config.yaml flows through to the env var via gateway/config.py:894 and lets bot events past this gate.

2. gateway/run.py::_is_user_authorized — per-user allowlist

   • The bot's Slack user ID must be in SLACK_ALLOWED_USERS (or GATEWAY_ALLOW_ALL_USERS=true), otherwise the message is dropped with WARNING: Dropping message from unauthorized user in active session.
   • I added the other bot's ID to SLACK_ALLOWED_USERS.

After both fixes, gateway logs show zero inbound message: platform=slack user=<bot_id> lines when the other bot posts in the shared thread. Either Socket Mode isn't delivering bot-subtype events to the app at all, or there's a third filter upstream of the inbound message log line that's silently dropping them.

Suspected root causes (need investigation)

• Socket Mode subscription scope — Slack apps subscribe to specific event types. If the app subscribes only to app_mention and message.channels / message.im, bot messages may not be delivered at all. The fix may be configuration-side (Slack app manifest) rather than code-side, but Hermes should surface this clearly.
• Pre-_handle_message filter — there may be a synchronous filter in the slack-bolt middleware or in slack.py's event registration that drops bot events before the logged path.
• The [Liatrio Brain] empty-body artifact — confirms that Hermes' thread-context fetch (via conversations.replies Web API) sees the message in Slack's history but the live event subscription doesn't surface it. Strongly suggests it's a Socket Mode / event-subscription gap, not a Hermes filter.

Proposed remediation

• Add DEBUG logging at the very top of slack.py's message handler — before any filtering — so it's visible whether bot events arrive at all.
• Document the Slack app manifest requirements for bot-to-bot interop (which event types must be subscribed).
• When allow_bots != "none" is configured but the underlying event subscription doesn't include bot events, emit a startup warning so users don't silently lose messages.
• Consider a generic "bot interop mode" that bundles the config flips + manifest checks together.

Why this matters

Multi-agent Slack workflows are increasingly common (e.g. an org has a "knowledge brain" bot and a personal-agent bot, both running in shared threads). Today Hermes' Slack adapter is single-bot-centric — it assumes the only other participants are humans. As agent ecosystems mature, this is a real blocker.

Workaround until fixed

Human user manually pastes the other bot's replies into the thread so Hermes can see them. Functional but tedious.

Environment

• macOS 26.1, Hermes Agent (current main)
• Slack workspace with two bots installed
• Socket Mode, multi-workspace token configuration

Filed from a real bot-to-bot interop session where this blocked direct dialog between a "Brain" agent and a personal "Trio" agent.