Telegram multi-bot groups need shared observed channel context without waking untagged bots

[majkonautic]

Summary

In a Telegram group with multiple Hermes profile bots, mention gating works for dispatch (only the tagged bot responds), but the profile bots do not share enough channel context. A later tagged bot can miss the prior user request and the previous bot's final answer, so follow-up prompts like "find best offers for these products" are answered as if no products were provided.

This should be fixed without disabling require_mention or waking every bot. The desired UX is: only tagged bots respond, but tagged bots can read recent channel context from other agents/users when needed.

Observed production case

Group: a Telegram shopping group with at least two Hermes profile bots:

• Diodak: research agent
• Sknerus: finance/shopping-offers agent

Flow:

1. User tags Diodak:
   • @...Diodak_bot research this product https://www.tiktok.com/@peterpandeveloper/video/7554015900387577110 and add this to our shopping list in our hub.
2. User tags Diodak again while it is running:
   • @...Diodak_bot when you finish - do the same with this product: https://www.tiktok.com/@thesetupking/video/7529214968462331158
3. Diodak completes and posts a final message with two Hub shopping item IDs and product names:
   • Insta360 Wave AI Conference Speakerphone
   • Govee smart floor lamp — likely Floor Lamp 2 / exact TikTok model TBD
4. User tags Sknerus:
   • @...Sknerus_bot mozesz poszukac najlepszych ofert na te produkty?
5. Sknerus replies:
   • Mogę, ale nie widzę tutaj listy produktów ani zdjęcia/linków...

Evidence from local state/logs

Diodak profile session for the shopping group contained the original product request and Diodak's final answer:

• /root/.hermes/profiles/diodak/state.db
• session: 20260612_112448_a5de9d38
• relevant rows:
  • user row with the first TikTok product URL
  • assistant row with the final answer listing both Hub IDs/products

Sknerus profile session for the same Telegram group contained only the follow-up request addressed to Sknerus:

• /root/.hermes/profiles/sknerus/state.db
• session: 20260612_113357_709b898b
• relevant rows:
  • user row: mozesz poszukac najlepszych ofert na te produkty?
  • assistant row asking the user to provide product links/names

Both profiles had observed=0 rows in their state DBs at the time of inspection, so passive channel context was not being captured.

Config snapshot for both profile bots showed Telegram mention gating enabled:

telegram:
  allowed_chats: ''
  require_mention: true
  exclusive_bot_mentions: true

This is intentional for dispatch: we still want only tagged bots to answer.

Current implementation notes

Relevant code paths observed in gateway/platforms/telegram.py and gateway/run.py:

• _should_process_message() correctly gates group processing through require_mention, reply-to-bot, bot mention, or mention patterns.
• _should_observe_unmentioned_group_message() can store skipped group chatter as observed context when observe_unmentioned_group_messages is enabled and the group is allowlisted via group_allowed_chats.
• With exclusive_bot_mentions: true, _should_observe_unmentioned_group_message() returns false for messages that explicitly mention a different bot (_explicit_bot_mentions_exclude_self()), so a bot will not even passively observe user messages addressed to sibling bots.
• _observe_unmentioned_group_message() writes observed rows to a shared chat/topic source within a single profile, and _build_gateway_agent_history() later separates observed context from ordinary replay. That part is good and should be preserved.
• Outgoing assistant messages are appended only to the responding profile's own session transcript. Other profile bots do not appear to receive those bot-authored Telegram messages as inbound updates, so relying on Telegram Bot API bot-to-bot visibility is not sufficient.

Expected behavior

For opt-in multi-profile Telegram groups:

1. A message explicitly addressed to Bot A should dispatch only to Bot A.
2. Bot B, Bot C, etc. should not respond, but should be able to passively record the message as attributed channel context if the group is allowlisted for observation.
3. Final responses produced by Bot A should be mirrored into a shared channel transcript / sibling profile observed context, because other Telegram bots may not receive bot-authored messages from the platform.
4. When the user later tags Bot B, the current turn should include bounded recent observed channel context, including:
   • prior user messages addressed to sibling bots,
   • relevant final assistant messages from sibling bots,
   • clear attribution (Bartosz, Diodak, etc.).
5. Observed context must remain context-only: it must not be treated as pending requests and must not wake untagged bots.
6. This must be opt-in/allowlist based, not ambient ingestion for every group.

Possible design direction

• Add a Telegram/multi-agent channel-context mode that separates dispatch gating from observation/mirroring.
• Keep require_mention: true and exclusive_bot_mentions: true semantics for dispatch.
• Add/adjust observation logic so messages addressed to sibling bots can be observed without dispatching.
  • This may need a new config flag instead of overloading exclusive_bot_mentions, e.g. observe_sibling_bot_mentions: true.
• Add an outbound mirror hook in gateway final delivery: when a profile bot sends a final response to an allowlisted Telegram group, append an attributed observed row into configured sibling profiles' channel-scoped sessions, or into a shared channel transcript that all profiles can read.
• Bound the observed context included in the prompt to avoid context bloat.

Acceptance criteria

• Regression test: in a group with require_mention: true, message @bot_a do X dispatches only to bot_a.
• Regression test: in the same setup, bot_b does not dispatch but can later see the attributed user message as observed context when tagged.
• Regression test: final assistant output from bot_a is available to bot_b as context on a later tagged turn.
• Regression test: observed rows are not replayed as ordinary pending user turns and do not cause untagged bots to answer.
• Config remains opt-in and requires a group/channel allowlist.

Why this matters

The current UX breaks multi-agent collaboration in Telegram channels: agents can complete work correctly, but sibling agents act memory-blind in follow-up tasks. Disabling mention gating would solve context at the cost of every bot waking up, which is explicitly not desired.