Feature Request: Cross-agent message delivery in shared-bot multi-agent setups
Problem
When running multiple agents in a single spacebot instance, all agents share one Discord bot user. This means the Discord message handler filters all messages from that bot user ID — including messages sent by one agent to another agent's channel via send_message_to_another_channel.
The result: Agent A posts to Agent B's channel → Agent B's handler drops it as "self-message" → cross-agent communication through Discord channels is impossible.
This is a fundamental limitation for multi-agent workflows where agents coordinate via shared Discord channels.
Related
Proposed Solution
We implemented a self-contained approach using Discord embed footers as a signal:
Sending side (send_message_to_another_channel)
When the target is a Discord channel, wrap the outbound message in a RichMessage with a Card containing:
footer: "cross-agent:{source_agent_display_name}"
Receiving side (Handler::message() in discord.rs)
Before the self-message filter:
- Check if the message has embeds with a footer starting with
"cross-agent:"
- If found, set
is_cross_agent = true
- Modify the self-message filter:
&& !is_cross_agent
- Extract source agent name and add to metadata as
cross_agent_source
Why embed footers?
- No shared state between sender and receiver — the footer is self-contained in the message
- No trait signature changes —
broadcast still returns Result<()>
- No infinite loops — only
send_message_to_another_channel adds the footer; regular agent replies don't, so they're still filtered
- Observable — footer text is visible to Discord users (small embed text), which is actually useful for transparency
Example flow
- Overseer posts to Liaison's
#observatory channel via send_message_to_another_channel
- Message arrives with embed footer
"cross-agent:Overseer"
- Liaison's handler sees the footer, allows the message through, adds
cross_agent_source: "Overseer" to metadata
- Liaison processes and replies normally — its own reply lacks the footer, so it gets filtered (no loop)
Impact
- Unblocks multi-agent coordination through Discord channels
- Zero impact on single-agent setups (no footer = existing behavior)
- No database migrations or config changes
- Footer visibility provides transparency to human observers
Implementation Notes
We've been running this on v0.3.3 in a multi-agent BIM experiment setup. The approach is deliberately minimal — no new tables, no shared state, no protocol changes. Happy to submit a PR, though I'd appreciate feedback on the embed-footer approach vs. alternatives (e.g., a dedicated agent-to-agent message bus bypassing Discord entirely).
Feature Request: Cross-agent message delivery in shared-bot multi-agent setups
Problem
When running multiple agents in a single spacebot instance, all agents share one Discord bot user. This means the Discord message handler filters all messages from that bot user ID — including messages sent by one agent to another agent's channel via
send_message_to_another_channel.The result: Agent A posts to Agent B's channel → Agent B's handler drops it as "self-message" → cross-agent communication through Discord channels is impossible.
This is a fundamental limitation for multi-agent workflows where agents coordinate via shared Discord channels.
Related
send_message_to_another_channeltool already provides the sending side; this addresses the receiving sideProposed Solution
We implemented a self-contained approach using Discord embed footers as a signal:
Sending side (
send_message_to_another_channel)When the target is a Discord channel, wrap the outbound message in a
RichMessagewith aCardcontaining:Receiving side (
Handler::message()indiscord.rs)Before the self-message filter:
"cross-agent:"is_cross_agent = true&& !is_cross_agentcross_agent_sourceWhy embed footers?
broadcaststill returnsResult<()>send_message_to_another_channeladds the footer; regular agent replies don't, so they're still filteredExample flow
#observatorychannel viasend_message_to_another_channel"cross-agent:Overseer"cross_agent_source: "Overseer"to metadataImpact
Implementation Notes
We've been running this on v0.3.3 in a multi-agent BIM experiment setup. The approach is deliberately minimal — no new tables, no shared state, no protocol changes. Happy to submit a PR, though I'd appreciate feedback on the embed-footer approach vs. alternatives (e.g., a dedicated agent-to-agent message bus bypassing Discord entirely).