AgentConnect
Connect & Automate

Integrations overview

How agents meet channels — bots, integrations, shared bots, and the commands that work in any conversation.

An integration binds one agent to one way of reaching it. The supported kinds:

PlatformThe agent responds toHow to connect
SlackChannels, threads, and DMsAdd to Slack, or connect your own Slack App
Microsoft Teams1:1 chats, group chats, and team channelsConnect with Microsoft as an administrator, or register your own bot
TelegramDMs and group messagesA bot token from @BotFather
DiscordChannels, threads, and DMsA bot token; AgentConnect builds the invite
Lark / FeishuGroup messages and one-to-one chatsOne-click app setup, or an App ID and secret
Google ChatSpace @-mentions and DMsCreate a Chat app and connect its service-account JSON key
DingTalkDMs and group @-mentionsAn internal app's Client ID and Client Secret; choose mainland China or international
QQPrivate chats and group @-mentionsAn official bot's AppID and AppSecret; self-hosted only
GitHubIssues, PRs, comments, deployments, and releasesInstall a GitHub App and authorize the agent's repositories
GitLabIssues, merge requests, comments, and releasesConnect with OAuth; AgentConnect creates each agent's service account
Azure DevOpsAzure Repos PRs and commentsConnect with Microsoft, or use your own application
Gitea / ForgejoIssues, PRs, comments, and reviewsA dedicated bot user's token, per organization
LinearDelegated issues and @-mentionsAuthorize the workspace in Linear
WebhooksJSON events from external systemsCreate a webhook and send requests to its generated endpoint

Add one from the agent page (Integrations → Add integration) or from the Agents list.

Add integration and choose a platform

Bots are identities, integrations are bindings

For the chat platforms, the thing that lives in your Slack workspace, Telegram group, Discord server, or Lark / Feishu tenant is a bot — a durable identity with its own tokens. An integration binds that bot to one agent.

  • Deleting an integration frees the bot rather than destroying it — reuse it for another agent from the Use an existing bot picker.
  • Bots are managed org-wide under Integrations → Messaging apps: see Bots.

Platform tiles depend on the agent's daemon capabilities and deployment settings. QQ is self-hosted only. Each platform guide covers its prerequisites and self-hosting setup.

Binding channels

There's no channel picker: invite the bot to a channel and it appears in AgentConnect. On the agent's Integrations card, open a channel's settings and choose its Session mode first.

Session mode

Session mode decides how the agent organizes work in this conversation:

  • Auto — a coordinator reads root messages and messages in threads not owned by a task. It hands a request to a task already working on that topic, opens a new task in the message's thread, answers a quick question itself, or stays quiet. A message that @-mentions the agent must be handled; if the coordinator fails to handle it, a task opens for it. People then talk directly to the task in its thread. While the coordinator decides, platforms with reactions show 🤔.
  • Per thread — each admitted root message starts its own session, and replies in its thread continue it.
  • Single session — every admitted message in the conversation, at the root or in a thread, joins one long session. Send !new to start a fresh one.

With Auto, no further response trigger is needed: the coordinator decides what needs a reply, so Respond to is hidden; Off remains available at the bottom. Auto can't be combined with By decision or a shared bot's Or pick by decision; switch the row to Per thread first.

In a task's thread, !new restarts that task and !stop stops it until someone mentions the agent there. At the conversation's root, !new starts a new coordinator, which keeps the open tasks, and !stop stops the coordinator's current turn. Open the coordinator's session in Sessions to see its tasks, each with the summary it keeps of its own progress, on the Tasks tab.

A self-hosted daemon runs Auto unless its config.json sets "features": { "autoSessionMode": false }; such a daemon answers an Auto conversation as Per thread.

Respond to: Per thread and Single session

After choosing Per thread or Single session, use Respond to to choose which messages activate the agent. The available choices depend on the platform:

  • @-mentions — respond when mentioned; unmentioned follow-ups continue in a thread the agent already joined.
  • All messages — run the channel's agent for every message.

Use the row's separate + Decision control to judge messages with a Decision and respond only when its answer matches your rules. An existing gate is shown as By decision; remove it with its × control to return to ordinary channel settings.

Linear has the same shape with a different roster: its conversations are the workspace's teams, listed for you the moment you connect it, and a team row takes only @-mention, By decision, or Off — every Linear event is addressed to the app already.

Turn off a conversation

Off is separate at the bottom of the menu. It stops responses in that channel, including to mentions, existing thread affinity, control commands, or shared-bot fallback. The closed button reads Auto, Per thread · @-mentions, or the other selected settings; when disabled, it reads Off. Picking a session mode turns an Off conversation back on.

Off keeps the bot in the channel, preserves past sessions, and only mutes inbound activation. A schedule or another agent's deliberate handoff can still post there. Manage the bot's actual channel or server membership on the chat platform.

New channel defaults

At the bottom of the agent's Integrations card, New channels start on sets the initial behavior for newly discovered channels and group conversations:

  • Auto — the default where the platform and the agent's daemon support it; otherwise the conversation starts on Per thread with @-mentions.
  • @-mentions · Per thread — start with a separate session per thread, activated by mentions.
  • Off — wait for an editor to enable the conversation.

Changing this default leaves existing conversations and one-to-one DMs unchanged. Restricted agents and conversations the platform identifies as external still start Off. In assistant mode, supported places use a fixed coordinator session where Auto is available, otherwise a fixed Single session. This overrides their ordinary session-mode choice while preserving Off.

Direct messages

A direct message appears after someone writes to the bot, and each agent controls its own direct conversations. One-to-one DMs use On / Off for responding. Slack also offers Per thread and Single session; in assistant mode, a Slack DM uses its coordinator where Auto is supported. Telegram, Discord and Lark / Feishu already keep one continuous session for a one-to-one DM. Group conversations use the session modes their platform supports, including all three for Slack group DMs. Conversations for a restricted agent start Off until an allowed editor enables them.

Shared bots

Normally one bot ↔ one agent. A shared Slack bot can serve multiple agents through a single identity, and a connected Linear workspace always does — every agent you enable on it works through the deployment's one Linear app. Under Integrations → Messaging apps, expand the bot and pick the Default dispatch agent for each channel: one "@Assistant" in Slack, with different specialists behind it by channel. Or pick by decision chooses the specialist per conversation instead, with a Decision.

The channel trigger applies to the shared bot. Switching it Off stops routing through that bot in the channel.

Restricted agents

When an agent's team visibility is Selected, its chat conversations are gated too. Newly discovered channels and direct messages start Off until an allowed editor enables each one from the integration card. Every agent can also choose Off later as an explicit mute. See Team visibility.

Reading and posting in other conversations

When someone asks an agent to read or post in a conversation other than the one it is answering in, the agent does it for that person and never goes further than they could. The conversation it is answering in is always open to it.

It reads another conversation's messages, threads, reactions or bookmarks only where the person asking can see that conversation:

  • a public channel, if they are a full member of that workspace rather than a guest;
  • a private channel or group DM they are a member of;
  • their own direct message with the agent. Someone else's direct message is never readable.

It posts, reacts, schedules a message, starts a conversation, or changes bookmarks, canvases or lists only where the person asking could post themselves. What it posts is their call. Three cases have their own rule:

  • A direct message goes only to a member of your organization: on Slack, a full member of the workspace, not a guest.
  • A conversation shared with another organization, such as a Slack Connect channel, takes a post from another conversation only as a draft. A member of your organization, usually the person who asked, gets it as a card in a Slack direct message and chooses Approve or Discard. A draft nobody answers expires after 24 hours.
  • A run no person is behind, such as a webhook, a GitHub event or another agent's request, reads only public channels and its own conversation, and posts only in its own conversation. A schedule acts for the person who last edited it, or else the person who created it.

When the agent uses something from a private conversation, it says where it came from. When a request is refused, it says it can't share that or can't post there, without saying whether the conversation exists.

Slack and Lark / Feishu can tell who is in a conversation. Telegram and Discord cannot, so there only a group or channel the platform shows as public counts: a Telegram group with a public @username, or a Discord channel everyone in the server can view.

Cross-platform handoffs

Connect the same agent to more than one chat platform and it can send a deliberate handoff from one conversation to another. Use this only between two messaging workspaces you trust and have approved to exchange information. The destination starts its own linked session rather than merging both platform transcripts.

On another platform, or through another of the agent's bots, AgentConnect must first recognize the person asking as a member of your organization, by the chat account they linked under Your profile → Sign-in methods. The agent then judges them by the chat account they linked for the destination's workspace: a public channel needs them to be a full member, and a private channel or group DM needs them to be a member. Where they have linked no account for that workspace, the agent reads or posts only in conversations whose sessions they can open under Sessions. Telegram and Discord accounts can't be linked, so that is always the rule there. On AgentConnect Cloud the account to link is a Slack account, so a handoff works from Slack into a Telegram, Discord or Lark / Feishu conversation where the agent already has a session they can open. It does not work from Telegram or Discord into Slack or Lark / Feishu: AgentConnect cannot tell who someone there is, so they reach other channels and groups only on that same bot. A self-hosted deployment can also link Lark and Feishu accounts. See Hand off conversations between trusted workspaces.

In-conversation commands

Use these commands to control the current conversation without asking the model to do it. Slack uses ! because Slack reserves / commands for apps.

ActionOther platformsSlack
Stop and mute/stop!stop
Cancel the current turn/cancel!cancel
Resume/resume!resume
Queue a message/queue <message>!queue <message>
Show session status/status!status
Change model, effort, or permission/models, /effort, /permissionThe same commands with !
Toggle fast mode/fast on, /fast off!fast on, !fast off

In Per thread and an Auto task's thread, Stop also mutes that thread until someone mentions the agent again or uses resume. In Single session and at an Auto conversation's root, Stop interrupts the current turn without muting the conversation; use Off to silence it. Cancel interrupts only the current turn.

The runtime-setting commands (/models, /effort, /permission, /fast) work only when the agent's What people can do in chat is Talk, approve and change settings. On Slack with Follow Slack access on, they work only for the agent's editors, and anyone else is told privately who can change them. On Telegram and Discord these commands appear in the native command menu, where the registered name is /models rather than /model (both are accepted when typed).

When a tool call needs approval, Slack, Telegram, Discord, Lark / Feishu and Google Chat post an approval card in the conversation, unless the agent is set to Talk to the agent. The same setting decides who may answer it; see When a run asks for permission.

How chatty should an agent be?

The agent's Output mode controls what reaches the platform: Minimal keeps one live-updating reply, Low posts replies, Medium adds tools and plans, High also includes reasoning and tool output, and None keeps the run in the web session only. The complete transcript is always in Sessions.

How is this guide?

On this page

How is this guide?