Channels

What a channel is

A channel is an adapter between a messaging system you don’t own and an agent that lives inside Exolvra. When someone sends your Telegram bot a message, a Telegram channel adapter receives it, turns it into an Exolvra session, routes it to the configured agent, and then posts the agent’s response back to Telegram as a reply.

Channels are entirely server-side. There’s nothing installed on users’ devices. They talk to your Exolvra gateway over whatever protocol the messaging platform uses (long polling, WebSockets, webhooks) and translate in both directions.

The four built-in channels

All four are configured from the Channels page in the dashboard. Each has its own setup flow — see Integrations → Channels for step-by-step guides.

The console channel is special: it’s the one adapter that doesn’t talk to an external system. It reads from the terminal stdin of the Exolvra gateway process and writes responses to stdout. Use it when you want to talk to an agent without opening the dashboard.

How a message flows

Same basic shape for every channel:

1. An external message arrives — a Telegram user sends a message, a Slack webhook fires, a Discord gateway event lands
2. The channel adapter converts it — the external message gets turned into a neutral internal shape (who sent it, what they said, any attachments)
3. The adapter finds or creates a session — channels maintain a mapping from external conversation (chat id, channel id, thread id) to Exolvra sessions. Returning users land in their existing session; new users get a new one
4. The agent runs — the agent configured for this channel processes the message the same way it would a message from the dashboard. Tool calls happen, memory is consulted, the agent writes a response
5. The adapter posts the response back — the agent’s reply is translated into the external system’s message format and sent back through the same adapter

Because sessions persist, a user chatting with a Telegram bot has a coherent multi-turn conversation even though the underlying HTTP requests are stateless.

Sessions and the channel mapping

Every channel adapter creates sessions keyed on the external conversation identifier:

• Telegram — one session per (bot, chat id) pair
• Discord — one session per (guild, channel, user) triple, or (guild, channel) for shared conversations
• Slack — one session per (workspace, channel, thread) triple
• Console — one session per gateway run

This is how the bot remembers what you were talking about last time. If you tell the Telegram bot “call me Alex” on Monday, then ask “what’s my name?” on Friday, the same session threads the two messages together and the agent answers correctly.

You can see every channel-created session in the dashboard under Sessions. Filter by channel to see just conversations from one source.

Agent selection

Each channel can be bound to one agent. That’s the agent every message coming through the channel is routed to. You set this on the channel configuration page.

For personal or team channels, this is usually a main assistant — a specialist with broad tool access. For public channels (a Discord server bot, a Slack app used by a whole company), it’s usually a chatbot with narrower capabilities and cloud mode hard-enforced.

You can’t currently mix specialists and chatbots on the same channel — each channel gets one agent, and that agent processes every message. If you need two different behaviours on the same channel, run them as two different bots/channels or build a router agent that delegates.

Sandboxing and security

External-channel sessions run in a sandboxed mode by default. This means the agent processing a Telegram or Discord message gets a more restricted capability set than an agent processing a message from your own dashboard chat:

• Filesystem access is limited or blocked
• Shell access is blocked
• Browser automation is blocked
• Network tools (web search, web fetch) are allowed
• Memory, data store, and inter-agent communication are allowed

The rationale: you (in the dashboard) are trusted; a random Telegram user is not. Sandboxing prevents a hostile message from triggering destructive tool calls on your host.

Allowlists add another layer. Every channel supports an allowlist — Telegram chat ids, Discord guild ids, Slack channel ids — that restricts which conversations the adapter will respond to. Anyone outside the allowlist is silently ignored. Set an allowlist for any channel that handles sensitive work.

Cloud mode, if enabled on the instance, overrides everything: it restricts all sessions (not just channel sessions) to a hard-coded safe set of capabilities. See Admin → Security for the full story.

When to use channels at all

Channels are for situations where a user wants to talk to an Exolvra agent from outside the dashboard. If everyone using the platform has a dashboard account, you don’t need channels — the dashboard chat page is enough.

Reach for channels when:

• You want an agent that personal friends or family can DM on Telegram
• You want a Discord bot that lives in your server and responds to mentions
• You want a Slack bot that fields questions in a #questions channel
• You want the console for local headless use without opening a browser

If you want an embedded chat widget on your website, that’s a different thing — see Bot widget. Widgets talk directly to the Bot API, not through a channel adapter.

Multiple channels at once

You can enable all four built-in channels simultaneously, each bound to a different agent if you want. One Exolvra instance can serve:

• A Telegram personal assistant
• A Discord community bot
• A Slack workspace bot
• A console session for local testing

All sharing the same underlying agent roster, memory store, and project workspace. An agent that learns something from a Telegram conversation can surface that memory when the same user asks a related question via Slack — assuming the same agent backs both channels.

Where to go next

• Integrations → Channels — step-by-step setup for every built-in channel
• Bots — the chatbot creator, for bots that don’t need a messaging channel at all
• Integrations → Bot widget — embed a chatbot into your own website
• Admin → Security — cloud mode and sandboxing