Channels

4 min read

A channel is the point through which an agent communicates with a person, group, or system. It can also receive events with no person on the other side. Every communication entering or leaving an agent is processed through a channel: it identifies the origin, applies its configuration, and determines where it can reply.

One agent can have several channels. For example, it can assist customers through Telegram, receive issues from GitHub, and keep private team chats in Kujira without making them the same workspace.

What a channel contains

Transport

The technical medium: internal chat, Telegram, Discord, Slack, WhatsApp, IMAP/SMTP, GitHub, webhooks, or Google services.

Scope

Defines whether the channel is used with people in the organization or external contacts. The same transport can serve either case.

Direction

States whether the channel only receives, only sends, or allows both. This distinguishes an outbound alert from a conversation.

The specific configuration depends on the transport: an account, bot, installation, email address, or webhook URL. See Integrations to connect each service.

Types by direction

Type	What it allows	Typical example
Receive only	The agent processes incoming events or messages without replying through that channel.	A GitHub repository creating issues to review.
Send only	The agent publishes notifications or results, but receives no messages from that destination.	A URL notified with an automation result.
Receive and reply	The agent handles messages and replies through the same medium.	A Telegram or Slack chat, or internal chat.

Direction does not depend on whether the transport is a chat. A webhook, for example, can only deliver events or also accept an agent response when an outbound URL is configured.

Who is on the other side

A channel does not have to be a one-to-one conversation. The same integration can serve different communication forms:

One-to-one

A person writes directly to the agent. Their identity in that channel—a user, phone, or address—keeps its own conversation thread.

Group or room

Several people share a space, such as a Telegram group or Discord channel. The agent receives the group's shared context and replies there.

No interlocutor

A system delivers an event—a webhook, GitHub issue, or calendar change—or receives a notification. No person needs to be conversing.

Groups can require a mention before the agent replies. This lets it be present in a busy room without intervening in every message.

One thread for each context

When the first message or event arrives through a channel, Kujira opens a conversation for that contact, group, or system context in that channel. Later inputs reuse the thread while it remains active.

A message arrives

Kujira identifies the channel and origin: a Telegram user, email address, Discord group, or system event.

The conversation is resolved

If an open thread already exists for that contact, group, or event in that channel, it continues. Otherwise, a new one is created.

The agent works in isolation

Each conversation keeps its own session, history, and context. One customer's conversation never mixes work with another customer's or another channel's.

This also separates one person when they write through different media: internal chat and Telegram remain independent threads. The agent can consult other contexts only when its permissions allow it; history is not automatically carried from one channel to another.

When it needs to retrieve something discussed long ago, the agent can consult conversation history, a long-term conversational memory that searches across a contact's linked channels. The history window depends on the organization plan.

Email

With IMAP/SMTP, each email thread remains an independent conversation. Two different subjects from the same address do not share response context or data.

The channel defines the frame, not behaviour

A channel establishes where the agent communicates and which messages or events it can receive. It can also include instructions specific to that origin, such as how to handle repository issues or when to mention someone in a group.

Configure the agent's general behaviour, capabilities, and limits separately. Use the channel to bound communication context and the agent configuration to decide what it can do within it.

Check a channel

On the channel's card, under its name, the Test button tells you whether it is still connected, without waiting for an agent to try writing. What it checks depends on the transport:

Transport	What it checks
Telegram, Discord, Slack	That the bot answers with the stored token, and which account it is.
IMAP/SMTP	That the mail account authenticates, both to receive and to send.
WhatsApp	That the linked device is still active.
Webhook	That your outbound address accepts a delivery.

A webhook test sends a real message

It is the only transport whose test is visible on the other side: Kujira delivers a message to the outbound address you configured, signed like any other. The text says it is a test and requires no action, and Kujira warns you before sending it.

The internal chat is not checked, because it never leaves Kujira. Neither are channels that run on a Google or GitHub connector: their credential belongs to the connector, not to the channel.

You need the same permissions as to edit the channel, and every check is recorded in the Activity log. If you test twice in a row, the button tells you how many seconds are left.

View channels and their threads

In each agent's Channels tab, you can create, activate, pause, and edit channels. There you also review their direction, linked credentials or accounts, and integration-specific rules.

To supervise contacts and conversations arriving through external channels, use Agent Desk. The Graph helps visualize relationships among agents, channels, contacts, and conversations.