hermes - 💡(How to fix) Fix [WhatsApp] group_sessions_per_user splits agent's view of group context — bot can't see other participants' messages [1 participants]

Problem

When group_sessions_per_user: true (the default), the gateway builds a session key that includes the sender's user_id for group messages (see gateway/session.py:491 build_session_key). This isolates each participant's conversation with the agent — good for privacy, but it has a side effect: the agent's session for user A in group G has no access to user B's messages in the same group.

For multi-participant chats this means:

1. The bot can't answer questions like "who's in this group?" — its session only contains the asker (+ itself).
2. The bot can't summarize earlier discussion if other participants spoke.
3. The bot can't reference cross-participant context ("as Bob said earlier…").
4. Skills that try to enumerate participants get a degenerate view.

Repro (WhatsApp)

1. Three-person group: bot + user A + user B.
2. User B sends two banter messages, untagged.
3. User A sends @bot who's in this group?
4. Bot replies with only itself + user A. User B's name + messages are absent from the session entirely.

(Same shape applies to other group platforms — Slack mpim, Telegram groups, Discord — anywhere group_sessions_per_user is honored.)

Why it matters

The split makes per-user privacy easy but makes the bot useless for group-context tasks (summarization, attribution, participant awareness). Users who want a "helpful group bot" experience have to flip group_sessions_per_user: false, which then merges all participants' DMs-with-the-bot into one shared session — over-shares in the other direction.

Possible directions

A few we've thought about — would appreciate maintainer guidance on which is the right primitive:

1. Expose group membership via a context attachment the agent can opt into reading. Bridge already knows the participant list (it's available in data.get(\"participants\") — see whatsapp.py:906); surface it as a structured field on the session source rather than burying it in raw event data, and let skills query it.
2. Read-shared / write-isolated mode: keep per-user write sessions (privacy preserved) but give the agent a read-only "group view" of recent messages from other participants, scoped to the same chat_id. Mirrors how Discord/Slack human users see the channel: shared read, per-user direct messages.
3. A new policy value (e.g. group_sessions_per_user: shared_context) that opts into option 2.

Option 1 is the smallest change and unblocks the participant-enumeration case. Option 2/3 is the bigger architectural ask but addresses summarization too.

Workaround currently in use

Setting group_sessions_per_user: false works for small trusted groups where cross-user context is acceptable, but it's not a real fix for groups with mixed trust.

References

• gateway/session.py:491 — build_session_key (where the user_id append happens)
• gateway/platforms/whatsapp.py:906 — bridge already receives participant list
• gateway/platforms/whatsapp.py:1063-1075 — sender-prefix patch (user-side workaround that I'm running locally to make per-user sessions at least disambiguate the sender's name; not a fix for the missing-other-participants problem)