Support multiple Telegram bot tokens in a single instance

[bchewy]

Problem

Currently, Spacebot only supports a single Telegram bot token per instance. When running multiple agents that each need their own Telegram bot identity (separate BotFather tokens), the only option is to run multiple Spacebot processes — one per bot.

This adds unnecessary operational overhead (separate containers, separate configs, separate data dirs) for what should be a single multi-agent deployment.

Current Architecture (blockers)

1. Config model — MessagingConfig.telegram is Option<TelegramConfig>, not a Vec or map. [messaging.telegram] can only appear once in TOML.

2. Adapter name collision — TelegramAdapter::name() returns the hardcoded string "telegram". The MessagingManager stores adapters in a HashMap<String, ...> keyed by this name, so registering a second adapter overwrites the first.

3. Source-based response routing — Inbound messages are tagged with source: "telegram". Outbound responses are routed by looking up message.source in the adapter map. No way to distinguish which bot received the message.

Proposed Solution

Allow named Telegram adapter instances, similar to how you might configure multiple of any service:

[messaging.telegram.community]
enabled = true
token = "env:TELEGRAM_TOKEN_COMMUNITY"

[messaging.telegram.personal]
enabled = true
token = "env:TELEGRAM_TOKEN_PERSONAL"

With bindings referencing the specific instance:

[[bindings]]
agent_id = "community-bot"
channel = "telegram.community"

[[bindings]]
agent_id = "personal-bot"
channel = "telegram.personal"

Changes needed

• config.rs: Change telegram: Option<TelegramConfig> to telegram: HashMap<String, TelegramConfig> (or BTreeMap), add backward compat for the unnamed single-token form
• telegram.rs: Accept a name/id parameter in new(), use it in name() (e.g. "telegram.community") and as the source field on inbound messages
• main.rs: Loop over Telegram configs and register each as a separate adapter
• Bindings: channel field matches the qualified adapter name
• TelegramPermissions: Per-adapter rather than shared

Use Case

Running two Telegram bots (each with distinct bot identities/usernames) bound to different agents in the same Spacebot instance. Currently requires two separate containers as a workaround.

[sookochoff]

I'd love to see this solution implemented across all adaptors currently offered (Discord, Slack, etc). Because Spacebot is native-multi-agent, it's crucial that more than one agent can be added to a given community.

Where it could get messy though is if the multiple agents are added to the same channel within a given Discord server, for example. So perhaps the solution is multiple agents per server, but one agent per channel. (I gather Telegram wouldn't have this issue as the agents would be separated by default).

[Marenz]

Running two Telegram bots (each with distinct bot identities/usernames) bound to different agents in the same Spacebot instance. Currently requires two separate containers as a workaround.

I still fail to see the use-case. What advantages would you have with both in one instance?
Just seems to increase the risk of cross-channel/bot data leaking, e.g. your private stuff into the telegram channel.

Right now its one big shared memory, mind you.

[sookochoff]

I see your question wasn't specifically directed at my comment @Marenz but I thought I'd build on my own use case I described above so it's captured here (and I don't forget!).

Because there's another piece to this: If I run a company and I have one agent for development, one for support, one for sales, and one for hr ( each with different personalities, tool access, memories etc), it would be nice for them to share some instituational knowledge. Like company history, staff bios, SOPs, etc.

The support agent would do much better job if he knew what dev agent was up to. And dev might do better if he knew what convos sales was having. In human orgs, it’s this isolation and lack of knowledge sharing that really makes them unproductive and holds them back.

And so having one agent in its own channel (#support, for example) but in the same Discord/Slack instance would be very useful for overall company communication - and 10x useful if they shared select knowledge from the Spacebot instance.

Someone might say just use one agent for everyone, allow workers behind the scenes to do the heavy lifting, and then you’ve got the ultimate company knowledge graph. And I dunno, this might be the way. But depending on how big your org is and how human-involved it is, there seems to be value in having an HR agent that’s tuned very differently (different models, different soul) than a dev agent. Like could you ever imagine one of your human developers running your HR department lol