Support multiple Telegram bots connecting to the same agent (same gateway, different sessions) using the same Telegram account.

[shaohq]

Feature Description

Support multiple Telegram bots connecting to the same agent (same gateway, different sessions) using the same Telegram account.

Motivation

When working on complex tasks, users often need the same agent to work on multiple things in parallel. Currently the only option is /background, which has these limitations:

1. Complex task delivery is cumbersome — passing detailed, multi-step instructions to /background is awkward and error-prone
2. No mid-task interaction — once a background job starts, you cannot intervene, ask questions, or provide feedback until it completes
3. Single-threaded queue — multiple background jobs still run sequentially, not in parallel

Multiple parallel sessions (via multiple bots) would allow the agent to simultaneously work on unrelated tasks, each with full interactive feedback capability.

Proposed Solution

Allow multiple Telegram bots under the same account to connect to the same gateway and agent, each with its own independent session. From the user's perspective, they would talk to "Bot A" for Task 1 and "Bot B" for Task 2, while both are powered by the same underlying agent with shared context (optional — could also be isolated per bot).

Potential implementation approaches:

• Session key = (user_id, bot_token) instead of just user_id, allowing the same user to have multiple concurrent sessions per bot
• Gateway routing based on bot token to dispatch to the correct session
• Optional shared memory/context between sessions for collaborative tasks

Alternatives Considered

• /background with job queue — only sequential, no mid-task interactivity
• Multiple separate agents — each is isolated, no shared context, harder to manage
• Threaded conversations in a single bot — adds significant UI and state complexity

Scope / Effort Estimate

Medium — primarily affects the gateway's session routing layer and the Telegram platform adapter. Session isolation is already partially implemented.

Additional Context

This is somewhat analogous to how IRC bouncers or modern Slack apps handle multi-channel concurrency, but simpler since sessions are stateless per-message.

[nihatdemir79]

Excellent idea. This is what i though today and search in google and found this tread. This will be game changer multiple ways. In business perspective, I can talk to my DEPARTMENTS agents which are linked to multipl telegram bots. Marketing, Sales, Operation, Accounting, Customer support departments have their own bot.

[coldfire-x]

@nihatdemir79 what's the progress now? this feature is a must-to-have one, i want to add multiple agents, and want to bind separated tg bot, pls

[Robbie-Cook]

I'd be stoked with this - I recommend recommended workaround would be ideal as well if possible 🙏

[Hotragn]

Claiming this — I'd like to build it to the acceptance architecture teknium1 laid out in the #10455 review last week ("the underlying gap remains on current main, but this patch needs architectural rework"):

1. Account-aware adapter registry. Replace the Platform → adapter maps (gateway/run.py:3048/3054 and every consumer) with (Platform, account_id) → adapter semantics behind a compatibility shim, updating delivery, reconnect, status, and lifecycle consumers together — including cron/home-channel delivery targets and reconnect routing per account, per the review's checklist.
2. Bot identity in session construction. Extend build_session_key (gateway/session.py:900-964) with an account component using the same backward-compatible namespacing pattern profiles already use — single-account gateways keep byte-identical keys, so existing routing state is untouched. Includes the review's required isolation test: same chat across two bots → two sessions, plus delivery-egress tests per account.
3. Config surface, policy-clean: bot tokens (secrets) as TELEGRAM_BOT_TOKEN_<ACCOUNT> in .env (the shape feat(gateway): add multi-account telegram routing #10455 sketched, unobjected); everything behavioral (per-account allowlists, display names, home channels) under telegram.accounts.<name> in config.yaml; wired into hermes gateway setup so it integrates with the existing setup UX rather than bolting on raw env vars.
4. Credit: I'll build on feat(gateway): add multi-account telegram routing #10455's commits wherever they survive the rework (cherry-pick, authorship preserved — the salvage convention), fresh implementation where the registry redesign supersedes them.

This also lays the rails #10143 (topic→profile routing) and #21587 (guest bots) need — account identity in the session key is the prerequisite both share.

If any part of the #10455 review spec has evolved since — especially whether the registry should generalize beyond Telegram in the same PR or stay Telegram-scoped with the interface ready — happy to adjust before the PR lands. Otherwise I'll get started.

[Hotragn]

Delivered: #67455 — built to the #10455 review's acceptance architecture item by item (account-aware registry with all consumers updated together, account identity in session construction with byte-identical single-bot keys, the same-chat-two-bots isolation test, cron/home-channel/reconnect routing per account), 46 tests across five files, Telegram-scoped with the registry layers platform-agnostic. Details and deliberate limits in the PR body.