hermes - 💡(How to fix) Fix Discord long bot-to-bot handoffs can drop unmentioned continuation chunks [1 pull requests]

Problem

In multi-agent Discord setups, a Hermes bot may send a long message addressed to another mention-gated bot. Discord's 2000-character content limit causes Hermes/the Discord send path to split the outgoing message into multiple messages.

Today, the first split part normally contains the target bot mention, but continuation parts often do not. Example:

<@target-bot> Long handoff text... (1/4)
Continuation text... (2/4)
Continuation text... (3/4)
Continuation text... (4/4)

For a receiving Hermes bot configured with DISCORD_ALLOW_BOTS=mentions / mention-gated behavior, only part 1 triggers ingestion. Parts 2-4 are ignored because they do not mention the bot. The receiving agent may then act on an incomplete handoff or wait for missing parts that it never reads.

This is especially painful for bot-to-bot orchestration patterns such as one Hermes instance planning/reviewing and another implementing.

Why existing improvements only partially help

Recent Discord history-backfill behavior is useful for recovering missed channel context on a later mention, but it does not fully solve this case:

• the receiving bot starts processing immediately after part 1;
• continuation parts may arrive while the receiving bot is already processing;
• those continuation parts are unmentioned, so they are not normal trigger messages;
• history backfill is documented as not capturing messages that arrive while the bot is processing.

So this remains a delivery/triggering issue, not just a context-recovery issue.

Expected behavior

Hermes should provide a reliable way to deliver long bot-to-bot handoffs without losing continuation chunks.

Possible acceptable behaviors:

1. Bot-recipient split mode: when sending a long message that begins with a target bot mention, repeat that raw mention in every required split part.
2. Attachment fallback: for bot-targeted messages above Discord's content limit, send one short mentioned trigger message plus a markdown/text attachment containing the full body.
3. Embed fallback: use one mentioned content message plus embeds for the body where size allows, with the trigger mention kept in normal message content.
4. Configurable policy: expose a Discord config option for long-message behavior, e.g. discord.long_bot_handoff_mode: repeat_mention | attachment | embed | default.

Suggested design considerations

• For human recipients, mention-only-first-part is usually desirable to avoid notification spam.
• For bot recipients, mention-only-first-part is unsafe if continuation parts are semantically required.
• Mentions inside embeds or attachments do not trigger mention-gated bots, so any trigger mention must remain in normal message content.
• If repeating mentions in every split part, consider allowed_mentions carefully to avoid unwanted extra human notifications while still allowing bot ingestion.
• The splitter likely belongs in the gateway/send path rather than in agent instructions, because agents cannot reliably predict final rendered Discord chunking.
• Part markers such as (1/4) / (2/4) are useful, but not sufficient unless the receiver actually ingests every part.

Reproduction sketch

1. Run two Hermes Discord bots in the same Discord channel/thread.
2. Configure the receiving bot to accept bot messages only when mentioned, e.g. DISCORD_ALLOW_BOTS=mentions.
3. Have the sending bot send a long handoff to the receiving bot that exceeds Discord's 2000-character message limit.
4. Observe that only the first chunk includes the target bot mention.
5. Observe that the receiving bot processes only the first chunk and misses/ignores later chunks.

Desired outcome for discussion

I am raising this to get feedback on the preferred product behavior and implementation approach. The main question is whether Hermes should:

• repeat the target bot mention on every split part for bot-to-bot handoffs;
• prefer attachments/embeds for long handoffs;
• add a configurable Discord policy; or
• improve receiver-side chunk aggregation/history handling instead.