The incident is closed. In the Slack thread, two colleagues wrap up: “eu cluster is back up, right?” — “yes, failover finished at 09:12” — “thanks, closing the ticket.” And your bot posts: ⚠️ the model returned only a silence marker and no reply.

It is technically correct. It did decide not to speak. But for the three humans in that thread, the sentence is pure noise.

What that warning is for

Hermes has a guard: when the model answers an obviously answerable message with nothing but a silence marker such as [SILENT], the gateway does not let the silence stand — it posts a notice instead. The logic is deliberately conservative: better one extra line than a real question that nobody answers.

On Slack, the judgement for thread replies is soft. Once the bot has taken part in a channel thread, later replies in that thread are treated as “might be for the bot”, so the gateway records the reply as neither expected nor unexpected. When the model then decides “this is not for me” and produces a bare silence marker, the marker is rejected and the warning card appears.

The mismatch is with how threads actually behave: in a warm thread, human-to-human chatter vastly outnumbers human-to-bot messages.

What the switch does

thread_followup_silence is opt-in and off by default. When it is on, an unaddressed reply in a non-DM thread is judged as not expecting a reply, so a bare silence marker stands and nothing is posted.

# config.yaml — top-level slack: block, or platforms.slack.extra (extra wins if both set)
slack:
  thread_followup_silence: true

Or via environment:

export SLACK_THREAD_FOLLOWUP_SILENCE=true

The comparison:

Message	Default (off)	Switch on
unaddressed reply in a channel thread	silence replaced by the notice	silence stands, nothing posted
an @mention of the bot	normal answer	normal answer
1:1 DM	normal answer	normal answer
group DM (multi-person)	shared-surface rules	unchanged
commands and reaction triggers	handled as usual	handled as usual
flat channel (reply_in_thread: false)	keeps the notice	keeps the notice

So it narrows one specific hole: channel threads, no mention of the bot, not a DM.

Why the default stays off

Because the old default solves a real problem. If someone asks the bot something in a thread without mentioning it, and the bot goes silent with no trace, the question simply evaporates — and nobody knows it was skipped.

The switch is for workspaces where the bot-engaged threads are mostly humans talking to each other, and the warning is the noise. Everyone else changes nothing; the default path is byte-for-byte the same.

There is also a narrower tool in the same area: ignore_other_user_mentions. It skips only messages that open by mentioning someone else, while plain follow-ups still get answers. If the annoyance is “stop butting in when colleagues address each other by name”, that is the closer fit. If it is “the whole thread is chatting and the bot files a silence report every time”, this switch is the one.

Checking that it took effect

Pick a thread the bot has participated in and send a reply without an @mention:

• If the model decides to stay out: nothing should appear — no warning card.
• Mention the bot in the same thread: it should answer normally. If it also stays quiet there, something else is gating it (channel-level mention policy), not this flag.

For the underlying judgement, watch the gateway log for that reply’s expected-reply field: with the flag on, it moves from “undetermined” to “no”.

Can you use it today?

Yes — this shipped in v0.22.7 on November 3, so it is a real config key in a released version. Set it after hermes update.

If you want the other side of the same coin — how the silence decision is scoped per room in multi-agent setups — the per-room silence post walks through it. The full Slack option list lives in the Slack section of the command reference, and if the real problem is that important events never reach you, the attention and notifications guide covers the receiving end.