hermes - 💡(How to fix) Fix Slack shared-thread self-mention can target the wrong user when current author ID is not exposed to the agent [1 participants]

Summary

In shared Slack threads, Hermes can know the sender identity at the gateway/platform layer, but the model-facing session context only guarantees [sender name] prefixes, not a verifiable current-author Slack user ID. That makes requests like "@ me again" / "mention me again" unsafe: the agent may guess or reuse an unrelated historical <@U...> instead of binding the mention target to the current speaker.

Downstream tracking issue with fuller internal context: https://github.com/asdigitos/hermes-agent/issues/2

Problem

We hit a real failure mode in a multi-user Slack thread:

• a user asked Hermes to mention them again
• Hermes produced the wrong Slack mention target
• the correct target was the current speaker, but the model had no verifiable author ID in its visible context

Today the gateway/platform code can extract Slack user_id from events, but the model prompt for shared multi-user sessions intentionally only says messages are prefixed with [sender name]. That means:

• display names are visible to the model
• a mention-safe <@U...> target is not guaranteed to be visible to the model
• self-referential requests like "mention me" are under-specified at generation time

This is especially risky in shared threads because a guessed historical ID can look plausible while being wrong.

Expected Behavior

When the current speaker asks for a self-mention in Slack (for example "mention me", "@ me again", "re-mention me"), Hermes should do one of the following:

1. deterministically bind the target to the current Slack author ID for that turn, or
2. refuse to generate a Slack mention if a verifiable current-author ID is unavailable.

It should never guess a <@U...> from memory, prior conversation frequency, or name similarity.

Proposed Design

Minimum safety fix

• Add a gateway/session-level invariant for Slack shared-thread turns:
  • if the model requests a self-mention target, the target must equal the current turn author's Slack ID
  • otherwise block/strip the mention and tell the user the ID could not be verified

Better platform-context fix

Expose structured per-turn author metadata to the agent for platforms with native mention syntax, e.g. something like:

• current_author_user_id
• current_author_mention
• current_platform = slack

This can stay outside the human-readable transcript if prompt-cache constraints matter; the key point is that the agent should have a verifiable mention target for the active turn.

Prompt/behavior fallback

If the above metadata is intentionally unavailable, explicitly instruct the model:

• in shared Slack threads, do not synthesize <@U...> targets from names/history
• if the user says "mention me" and no author ID is exposed, reply without a mention or ask for an explicit <@...>

Why this matters

This is not just a wording problem. It's a correctness/safety issue:

• a wrong mention pings the wrong person
• the output still looks valid to humans (<@U...> is syntactically correct)
• the bug is more likely in multi-user threads where multiple historical IDs are in scope socially, even if not visible in the immediate turn

Code locations touched (relative paths + line numbers)

• gateway/platforms/slack.py:994-1021
  • Slack already knows how to resolve a user_id to a display name via users.info
• gateway/platforms/slack.py:1282-1318
  • Slack assistant/thread metadata extraction already pulls user_id, channel_id, and thread_ts from incoming event payloads
• gateway/session.py:286-296
  • Shared multi-user session prompt text explicitly says only [sender name] is prefixed onto each user message, which explains why the model lacks a verifiable mention target

Open questions

1. Should Slack current-author metadata be exposed directly to the model, or handled as a gateway-side mention-rewrite guardrail?
2. Should this safety rule apply only to Slack, or to any platform with a native mention syntax tied to opaque user IDs?
3. Is there already an internal concept of per-turn structured metadata that can carry current_author_user_id without affecting prompt caching too much?