[Bug]: Slack mention triggers a run but mention context is stripped before the agent response decision

[BeMeGroupLimited]

Version

Hermes Agent 0.19.0, Slack Socket Mode gateway.

Summary

A human explicitly @mentioned Hermes in a Slack thread. Slack showed the bot entering its “thinking/summarizing” state, confirming that the mention triggered a run. However, the user turn delivered to the agent no longer contained the @hermes mention or any equivalent “directed at this bot” marker.

The agent therefore treated the message as an unaddressed channel comment, returned the intentional-silence sentinel NO_REPLY, and the gateway suppressed the response.

User impact

People can visibly mention Hermes and see it start processing, but receive no response. This makes the bot appear to stop or crash and makes mention-only response policies unreliable.

Reproduction

1. Run Hermes in a Slack channel where channel messages can reach the gateway, while the agent policy responds only when explicitly addressed.
2. In an existing thread, have a human explicitly mention @hermes and ask a short follow-up question.
3. Observe Slack show Hermes as thinking/summarizing.
4. Inspect the normalized user turn given to the agent.

Actual behavior

• The mention triggers a gateway run.
• The normalized agent input contains the sender and question, but no @hermes mention and no equivalent mention metadata.
• The agent concludes the message is not directed at it and returns NO_REPLY.
• The gateway intentionally suppresses that sentinel, so Slack receives no answer.

In the observed production case, this happened twice for the same human-authored thread follow-up. Gateway logs showed both inbound runs followed by intentional-silence suppression; there was no crash or timeout.

Expected behavior

When Slack routing determines that an explicit mention should trigger Hermes, the agent must also be able to tell that the message was explicitly directed at it. Either:

• preserve a human-readable @hermes marker in the normalized user turn, or
• add explicit trusted metadata such as directed_to_bot: true / was_explicitly_mentioned: true to the agent context.

Mention detection used for routing and mention context used for response policy should not disagree.

Acceptance criteria

• A human @hermes mention in a channel thread remains observable to the agent after Slack event normalization.
• The agent can distinguish an explicit mention from ambient thread traffic without parsing untrusted prose.
• A directly mentioned short follow-up does not become NO_REPLY solely because the adapter removed the mention text.
• Existing mention-gating and intentional-silence behavior remains intact for genuinely unaddressed channel messages.
• Regression coverage exercises the full path: Slack event → mention routing → normalized agent input → outbound response decision.
• Diagnostic logs clearly distinguish “not mentioned,” “mention routed,” and “agent intentionally chose silence.”

Related but different

• [Bug]: Slack mention detection (allow_bots=mentions, is_mentioned, require_mention) only inspects flat top-level text, so @mentions present only in Block Kit blocks are silently dropped #52387 covers mentions present only in Block Kit fields being missed by mention detection. In this report, the human mention did trigger the run; the problem is that the mention context was lost before the agent decided whether to respond.
• Slack gateway should treat explicit no-reply sentinels as intentional silence #30644 covers suppression of exact NO_REPLY responses. That suppression worked as designed here; the incorrect part was the agent being given insufficient mention context and therefore choosing silence.

Attribution

• Original Slack follow-up author: U0AQ6S3JTRD
• Ticket requested by: U0AQY5NGF7E

[JonthanaHanh]

Submitted a fix: #78127

The fix prepends (directed at you) to the normalised user text when the bot is explicitly @mentioned, giving the model a clear textual signal that the message was addressed to it. This supplements the existing identity prompt in channel_prompt which models may not reliably follow.