Channels
8 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
Scope
Direction
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
Group or room
No interlocutor
Groups can require a mention before the agent replies. This lets it be present in a busy room without intervening in every message.
Who can write and whom the agent replies to
Through an internal channel the agent works with all its tools, so only what comes from your team should reach it. Each channel has its own list on its page:
| Channel | List | What it filters |
|---|---|---|
| Telegram, Discord, Slack, WhatsApp | Allowed IDs | The chats and people the agent serves. With none, the channel accepts no messages. |
| Email, Calendar, Drive | Allowed senders | Who sends the email, who organises the event or who last changed the file. Accepts single addresses or a whole domain, such as *@yourcompany.com. Empty, it lets anyone through. |
Email channels also have Allowed recipients: if you fill it in, whatever the agent writes to any other address is left in drafts for someone to review.
A yellow icon next to the section title warns you when an internal channel accepts messages from anyone or when the agent can write to any address.
These lists, like the rest of the card, are changed with Edit: you add or remove entries, set the mention rule for each group or who receives alerts, and nothing is applied until you press Save. Cancel discards every change. Outside editing, the card shows how the channel is configured; Test and turning the channel on or off from its menu still work without entering edit mode.
A calendar invitation only needs your address to arrive: Google adds it on its own. If the agent watches a calendar, limit the senders to your domain.
A GitHub channel receives everything that happens in its repositories, whoever writes it. It is not recommended for public repositories: anyone could send the agent instructions through an issue, a comment or a pull request.
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
The conversation is resolved
The agent works in isolation
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.
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.
A channel's default model
Each channel can have its own Default model, in the General section of its page or when you create it. The channel list shows each one's. That channel's conversations that don't have a model of their own answer with it instead of the agent's. For example, a channel that only receives calendar events can use a lighter model while the agent keeps a more capable one everywhere else.
The order is: the conversation's own model, if it has one; otherwise the channel's; and if the channel is set to Inherited, the agent's.
You can pick a model from another provider than the agent's, just like for a conversation: the picker groups models by connection, and the channel answers with the connection you choose or, if you choose none, with that provider's default one. Choosing a channel's connection requires the View permission on Model providers. If the model is from the agent's provider and you move the agent to another provider, the channel goes back to Inherited; one with its own connection keeps it. The change applies from each conversation's next reply and, like any model change, clears its context cache.
Notification destination
Channels that only receive events —a webhook, GitHub, Calendar or Drive— have nobody to talk to. When an event needs a person, to notify you, ask you something or request an approval, the agent writes to the channel's Notification destination: an internal conversation you choose on its card. It can be your chat with the agent, a dedicated thread or an internal group, but never a customer conversation. From an event, the agent can't write to a customer or through an external channel either: only to your team, through its internal channels, or to another agent.
The picker groups the agent's conversations by channel, most recent first, and lets you search them by title, contact or reference, the one shown in the chat. You can only choose conversations you can see: your own and the internal threads that belong to nobody.
- If the chosen conversation is archived, the notice reopens it: it always reaches that one, not another.
- If the conversation is deleted, the channel is left without a destination. The agent can no longer write there and can only notify through the bell. When you delete it, Kujira tells you which channels use it as their destination.
- If the conversation is the session of someone who loses access to the agent or leaves the organization, the channel treats it as without a destination until access returns. When they leave the organization, the destination is cleared.
- If the destination is someone else's private session, the card shows it as Private session with its owner's name, without the title.
Without a destination, the channel's notices only reach the panel's bell.
Check a channel
In the header of the channel's card, next to Edit, 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. |
| 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, team members, channels, and conversations.