Chat in Slack

How do I let my team talk to Support helper in Slack? Connect Slack, publish the agent, then turn on Chat in Slack with a handle, selected channels, and approvers. Slack starts Live conversations. Their replies and approvals must happen in Slack.

Connect the intended workspace

Use the Support helper from Publish and share agents, or substitute your own published agent. Prepare a Slack test channel whose members expect your messages, two approvers, and an escalation tool you have tested.

In the app: open Agents → Support helper → Live → Access → Chat in Slack. If no workspace is connected, choose Connect and complete Slack authorization. Return and select the intended Slack connection.

Chat in Slack requires your active native Slack connection, registry_slack. Another Slack integration cannot substitute. The modal’s Connect authorizes that integration. To add another workspace when one is already listed, use Connections → Add Connection. See Connect your apps.

Choose where people can use it

Publish the agent first. Turn on Chat in Slack, fill in the fields, then choose Save.

• Handle: use support-helper, or another name of 2–32 characters. Use lowercase letters, digits, underscores or hyphens, starting with a lowercase letter or digit. Saving enforces uniqueness within one connection. If two enabled Slack settings on active native connections share a handle, the user gets a thread message asking for distinct handles from the owners. It appears even when the other agent is unavailable in this channel, disabled, or unpublished.
• Available in: select your test channel. If you leave it empty, the agent works in every joined channel and in direct messages. Selecting any channel blocks new DM conversations, because the picker does not offer DMs. Removing a channel affects new summons only. Existing threads remain bound.
• Who can approve requests: select your two teammates. If you leave it empty, anyone in the thread can approve or reject. When the connection identifies the Slack user who authorized it, that user can also approve or reject, even when other approvers are selected.

Slack access is separate from Controller AI sharing. Anyone who can post where the bot is available can summon the agent. Conversations charge the agent owner’s organization usage balance. Direct actions use the owner’s connected accounts. Widening access widens who can spend that balance.

Each picker stops at 2,000 eligible entries. The channel picker omits archived channels. The approver picker omits deleted users, bots, and Slackbot.

Saving takes effect immediately, without publishing. Changes to the connection, the handle, and the channels govern new summons. Existing threads keep their stored agent, workspace, connection, and channel. Approver changes apply to later approvals. Reopen the modal and verify your settings.

Start a thread and check an approval

Add Controller AI to the selected channel. Mention the Slack app followed by the handle: “@Controller AI support-helper What information do you need to escalate ticket T-104?”

The first successful summon binds the thread’s root to one agent. Another handle cannot switch that thread’s agent, so start a new thread instead.

Slack uploads give the agent a filename and type placeholder, not the file contents.

Every message in a bound thread is recorded. After the first exchange, the agent skips chatter it judges irrelevant. Phrase follow-ups as clear requests to the agent.

Check the answer against the policy you actually attached. Ask for an escalation through your prepared tool. If it requires confirmation, review the Approve/Reject card and have a selected approver respond. Verify the resulting escalation or rejection message, not just the card status. Unanswered approvals wait without a deadline and survive the agent runtime stopping. Answering later resumes the run. Explicit Stop cancels them.

The approver policy covers the buttons. It also covers a bare approve or reject reply when exactly one request is pending. Other participants can ask questions or request changes. A directed reply withdraws pending requests, so the agent can answer and request approval again if appropriate.

If your published instructions require ticket IDs and resist instruction overrides, test a request with no ID and an instruction to ignore the policy. These checks verify your instructions, not platform guarantees.

Inspect the conversation in the app, but reply and resolve approvals in Slack.

Finish testing before you republish. Publishing moves existing Live conversations to the new version and closes approvals that have not run. Stopping running answers and marking Slack cards expired happen afterwards. A cleanup failure does not undo the publication.

Why did the first conversation fail?

Compare suggested handles with the saved Handle. If Slack says the handle exists but is not published, publish the agent and retry. If no agent is available, check the workspace, the switch, the selected channel, and the agent’s enabled and published state. The native connection must still exist and have stored status ACTIVE. Check Connections or the command below, and reconnect if missing or inactive. Clearing Available in widens access, including DMs.

Check the agent before setup

With an assistant: Chat in Slack settings are app-only. Set per-tool Slack approval routes in the tool editor, the CLI or MCP. The reads below need no workflow selection. Start by finding the agent.

cai agent list --search "Support helper" --ownership mine --json

MCP uses agent_list with search: "Support helper" and ownership: "mine".

Take the one exact displayName match, because substring search can return several rows. If ambiguous, have the owner choose the ID. Use that row’s data.agents[].id as <agentId>.

Now read the agent to see its publication state and Slack settings.

cai agent get <agentId> --json

MCP uses agent_get with agentId as a string.

Check CLI data.liveAgentVersionId (MCP: liveAgentVersionId) for publication and CLI data.slack for basic settings. The CLI omits approvers and connection status, so verify approvers in Live → Access → Chat in Slack. MCP’s schema types slack as null, so read Slack state with the CLI or the app, including when MCP returns OUTPUT_SCHEMA_MISMATCH.

Then list the Slack connections behind those settings.

cai connection list --integration registry_slack --json

MCP uses connection_list with integration: "registry_slack".

Match CLI data.items[].id to data.slack.connectionId from the agent read. It must show status: "ACTIVE". That status is stored eligibility, not a live provider check.

Post approval requests to Slack from any conversation

A tool that requires approval can also post its requests to a Slack channel. The route applies to conversations started in the app, by the CLI or MCP, and by scheduled workflows. A conversation started in Slack keeps using its own thread.

In the app: add or edit the tool and choose Require approval. Under that choice, use Slack approvals. If you have several Slack connections, select Slack workspace, then Channel. With one connection, select Channel. With no connection, the Connect card opens Slack authorization without leaving the editor. Choose Not posted to Slack to clear the route. Who can approve lists the Slack users who may answer in that channel. Leave it empty to let anyone in the channel answer.

With an assistant: use the tool ID from cai agent tools <agentId> and set both routing flags on a tool that requires approval:

cai agent update-tool <agentId> --tool <toolId> --require-confirmation --slack-connection <connectionId> --slack-channel <channelId> --slack-approver <slackUserId> --json
cai agent tools <agentId>

MCP uses agent_tool_update with requireConfirmation: true and slackRoute: { connectionId: <connectionId>, targetType: "channel", channelId: "<channelId>", approvers: ["<slackUserId>"] }. The route also accepts optional channelName and enabled fields. Use slackRoute: null to remove it.

cai agent add-workflow and cai agent add-action accept the same routing flags. --slack-approver is optional and repeats for up to eight Slack user IDs; without it anyone in the channel can answer. Add optional --slack-channel-name <name> to any of these commands. cai agent update-tool also accepts --no-slack to remove the route. MCP agent_tool_workflow_add and agent_tool_action_add accept the same slackRoute. The tool list shows a slackApprovals column, or raw slackRoute with --json.

The route is a draft tool setting, like the approval requirement. Test conversations use the draft. Live conversations use the published version. A route change stays unpublished until you publish the agent.

Cards post in one thread per conversation and channel. The app’s approval card keeps working. The first answer wins. When the route’s Who can approve list or the agent’s Chat in Slack → Who can approve requests list names anyone, only those users and the Slack user who authorized the connection can approve, reject, or reply in that thread, and other members’ replies are ignored. With neither list set, anyone in the channel can answer. The approver list is published with the agent and fixed for each thread when it opens.

Reject opens a modal with an optional reason. The reason reaches the agent as the denial message and appears on the card. Chat in Slack approvals use the same modal.

If a card cannot be posted, transient Slack errors get five delivery attempts within about an hour. Permanent errors stop delivery immediately: the channel is gone or archived, the bot is not allowed, or the workspace is disconnected. The tool editor shows the last failed delivery and its reason. A delivery failure never runs the tool. The request stays answerable in the app.

Turn off Slack access

Return to Live → Access → Chat in Slack and turn off the switch. The change saves immediately. Check that Access → Chat in Slack reads Off.

Off stops new summons and pauses new bound-thread replies. It does not cancel running answers, unbind threads, or reopen app replies and approvals. Replies received while off stay buffered and can run after you re-enable it.