Multi-Connector: Run Multiple Bots of the Same Type in One Daemon

PR #146 ships first-class multi-connector support. You can now run as many instances of the same connector type as you need — three Slack bots, two Telegram bots — each with independent credentials, bindings, and persona identity. One daemon, one config file, no external orchestration.

How it works

Channels have always been keyed by name, not type. That meant the config already allowed multiple entries of the same type — the daemon just wasn’t robust enough to handle them correctly. This PR fills that gap: bot-self filtering, sibling identity awareness, and clean channel routing all work across N connectors of the same type.

Add multiple entries under channels: with unique names and bind each to a persona:

channels:
  - name: slack-pm
    type: slack
    config:
      botToken: ${SLACK_PM_BOT_TOKEN}
      appToken: ${SLACK_PM_APP_TOKEN}
      signingSecret: ${SLACK_PM_SIGNING_SECRET}

  - name: slack-dev
    type: slack
    config:
      botToken: ${SLACK_DEV_BOT_TOKEN}
      appToken: ${SLACK_DEV_APP_TOKEN}
      signingSecret: ${SLACK_DEV_SIGNING_SECRET}

bindings:
  - persona: product-manager
    channel: slack-pm
    isDefault: true
  - persona: developer
    channel: slack-dev
    isDefault: true

That’s the entire config. Both bots start, both respond in character, and neither one sees the other’s messages.

Bot-self filtering

The trickiest part of multi-connector is preventing feedback loops when bots share a workspace or group. Each connector type already had some form of self-filtering, but Telegram was the gap — it previously relied on a simple is_bot check that wasn’t robust enough for multi-bot groups.

This release adds identity resolution on startup: each Telegram connector calls getMe to learn its own bot ID, then filters both is_bot messages and any messages from sibling Talon bot IDs in the same daemon. Sibling IDs are distributed automatically across all Telegram instances after startup and again on hot-reload — no extra config, no manual ID lists.

Connector	Filtering
Slack	Drops all bot_id messages
Discord	Drops all author.bot messages
Telegram	Resolves own identity via getMe, drops is_bot and known sibling IDs
WhatsApp Baileys	JID-based self-detection

The virtual team pattern

The use case that motivated this work is the virtual team: multiple AI personas running as individual bots in the same Slack workspace or Telegram group, each with a distinct role and system prompt. The PM bot handles roadmap questions. The Dev bot handles technical queries. A Content bot handles marketing copy. They can even delegate to each other via the A2A protocol while presenting completely separate identities to the humans in the channel.

That pattern is now fully supported out of the box.

What’s next

Multi-connector support is the foundation for a richer virtual team experience. The activity feed split (tracking which bot said what across a shared workspace) is coming in a follow-up.

For the full configuration reference, see the Channels guide.