An AI assistant in a Slack Connect channel is an app. Your workspace installs it, it joins the shared channel, and it answers through the same surfaces a person uses.
What the AI can read
Slack’s conversations.history docs say a bot can read “Any conversation the relevant bot is a member of.” Membership is the boundary. The assistant reads the shared channels it has joined and nothing in the customer’s own workspace, including their internal channels and their direct messages with colleagues.
Threads need their own fetch. The conversations.history page says “To retrieve a message from a thread, check out conversations.replies.” So when a new question lands in a thread, the assistant fetches that thread with conversations.replies, not the channel history. Both methods sit in the same rate-limit tier, covered below. The method pages do not say whether the two draw on one shared budget, so measure it on your own app before you plan around either.
Mentions are a separate path. Slack’s app_mention page says “If your app is mentioned but not part of a conversation (and not invited to join), you won’t receive an event.” It also says “You’ll need to monitor your app’s channel membership separately from this event.” Direct messages are not dispatched through app_mention at all, so subscribe to message events if you take DMs.
Answers should come from a source you control: your help center or an approved macro library. Slack content alone is not a knowledge base. Write the rule down. If the answer is not in the approved source, the assistant hands off.
How replies are labeled
Slack’s Slack Connect help says “People in the channel can see messages from bots and apps.” It adds that people “can also exchange messages with an app’s bot user if it’s been added to the channel.” Everyone on the customer side sees the assistant’s replies, including the wrong ones. Plan the labels around that.
The help article describes the icon for apps added by another organization: “Apps added by another organization will include that organization’s Slack icon next to the app name.” Your assistant is added by your organization, a case the article does not show. Check in a test channel what the customer sees next to the name. The name alone should not be the only marker.
Disclose the automation in the first reply of each new thread. This wording is our draft, not a Slack requirement:
“I’m Acme’s automated assistant. I answer from our help docs. A person on our team reads this thread and will reply if I can’t answer.”
When the assistant is wrong, correct it in the same thread and say which part was wrong. Do not edit the old message and hope nobody noticed. Our draft:
“Correction to my earlier reply: the export limit is 30 days, not 60. Sorry for the mix-up. Dana on our team will confirm.”
Setup checks before the first customer message
Run these in a test shared channel with an external account. Your own team is not a valid test, because the customer side sees different icons and different permissions.
| Check | How to test | Pass condition |
|---|---|---|
| Membership | Add the app to the shared channel, then post from the external account | The app receives the message event |
| Scopes | Compare the app’s scopes to the events you subscribe to | The conversations.replies page lists channels:history for public channels and groups:history for private channels |
| Mention path | @mention the assistant from the external account | It answers in the thread, or hands off as your rule says |
| Name and icon | View the reply from the external account | The name and icon match what you intend |
| Guest rule | Test with a Slack Connect external account | The reply appears. Slack’s help says guests can’t use AI apps or agents, and does not mention Slack Connect |
| Edits and deletions | Edit one question and delete another in the test channel, then log what the app receives | You have a written record of which changes arrive before you build on them |
Plans and approval are not settled by the docs. Slack’s Slack Connect help says “each organization must be using a paid Slack plan” to work together in channels. It does not say whether that applies to apps, and it does not describe an approval step before an app joins a shared channel. Settle both with your own admin and the customer’s before rollout.
Removal follows the adding organization. The help article says “Only people from the organization that added an app can remove it from a channel.” If the customer’s organization adds your assistant, removal sits with their people. Decide who adds the assistant before rollout.
Rate limits: subscribe, don’t poll
The conversations.history and conversations.replies method pages both list “Tier 3: 50+ per minute” as of 2026-11-11. Slack’s changelog dated May 29, 2025 changes that for one class of app. It says the rate limits for both methods are “changing from Tier 3 to Tier 1 for commercially distributed apps that are not approved for the Slack Marketplace.” The new limits “will be updated to allow 1 request per minute and will return a maximum of 15 objects per request.” It also says “This change will not impact Marketplace apps,” and “Internal customer-built applications are not impacted by these changes.”
The start date depends on when the app was created. As read on 2026-11-11, the changelog says the updated terms are “effective immediately for applications created on or after May 29, 2025,” and that apps created before May 29, 2025 “will go into effect on June 30, 2025.” New installations of existing non-Marketplace apps are subject to the updated limits from May 29, 2025. The changelog also says the new limits “will not be applied to existing installations of unlisted, distributed applications,” and that existing installations of apps distributed outside the Marketplace, excluding internal customer-built apps, “will not be impacted.” So an install that already existed before the change is a different case from a workspace you add the app to now.
Suppose your assistant polls 40 shared channels for new questions, one call each per sweep. At 1 request per minute, one sweep takes about 40 minutes, and the customers in the last channels wait longest.
Suppose a customer pastes 60 messages into a thread and the assistant needs all of them. At 15 objects per request, that is 4 calls. At 1 request per minute, the fourth call goes out about 3 minutes after the first, so the assistant has nothing posted for roughly 3 minutes. Each later reply that refetches the whole thread costs the same again.
Neither method page says whether the two share one budget, so a thread fetch may or may not spend the channel-history allowance. Check the counts in your own logs.
The decision rule: if the assistant is an internal customer-built app, the changelog says the change does not affect it. If it is a commercially distributed app outside the Marketplace, plan for 1 request per minute on both methods for new installations, and for any app created on or after May 29, 2025. An app created before that date went into effect on June 30, 2025. Check the changelog’s existing-installation exception before you assume your current workspaces are covered either way. The changelog says existing installations of distributed apps are not impacted, so a workspace where the app was installed before the change is not moved to the new limit by those terms, while each new workspace you add it to gets the new one. The conversations.replies page lists Tier 3 too, so the method page alone does not settle your limit. In every case, subscribe to message events for new questions, fetch only the thread being answered, and keep the last few messages of each thread in a local cache.
When the AI should hand off
The rules below are our own starting choices, not Slack settings. Tune each one on your own transcripts.
If a customer tags a named person on your team, the assistant stops replying in that thread, assigns the thread to that person, and posts one line, for example:
“I’ve passed this to Dana. She’ll reply in this thread.”
Do not promise a time unless your published response-time target covers it.
If the message contains a term from your handoff list, hand off. Start the list with refunds, cancellations, outages and security questions, then add what your team actually escalates. Write each term as a phrase, and test the list against last month’s escalations before launch.
If the answer is not in the approved source, or the match falls below your confidence threshold, hand off with:
“I don’t have a verified answer for this. Dana on our team will reply here.”
Our starting threshold is 0.8. Measure it against a week of transcripts. If wrong answers reach customers, raise it. If answerable questions go to a person, lower it.
If a person has replied in the thread in the last 15 minutes, the assistant posts nothing. That window is our starting choice, not a Slack setting. Keep it, and have the assistant re-read the thread immediately before it posts, so it does not reply against a stale view.
Whether an AI reply stops your first-response clock is a rule you write, not a Slack rule. Decide it before launch, and check it against the Slack Connect first response time guide.
Data, kill switch and measurement
Before launch, write down three things. Which customer messages the assistant stores and for how long. Whether message text goes to a model provider, and on what terms. How personal data such as emails and phone numbers is removed from logs. If your vendor cannot answer these in writing, do not connect it to a shared channel.
Name one switch that stops the assistant posting in every shared channel, and one role allowed to flip it during an incident. Test it in the test channel: flip it, post from the external account, and time how long until the assistant stops. Our target is one minute. If the switch is slower than the time your team needs to notice a wave of wrong answers, it is too slow.
Each week, read 20 AI-answered threads picked at random and score each reply against the approved source as right, wrong or unsupported. Track the handoff rate, the threads where a person had to correct the assistant, the threads where the customer came back with the same question within a day, and CSAT against human-answered threads. When the sample shows a problem, fix the source article before you change the threshold.
Failure modes and fixes
The assistant is silent. The usual cause is membership. Run a membership check on a schedule and alert when a shared channel lacks the app. Slack’s app_mention page suggests subscribing to member_joined_channel, so you see the join when it happens rather than finding the gap later.
The assistant and a person both answer. Apply the 15-minute check above and the re-read before posting. A reply written against a stale thread is the usual source of contradictions.
The assistant answers the wrong thread. Key every reply to the thread the customer wrote in, not to the newest message in the channel. Test with two customers writing in the same channel in the same minute.
The customer edits a question after the assistant has answered. The answer may now be wrong. Re-read the thread. If the edit changes the answer, post a correction in the same thread, in the wording above. Do not silently edit the old reply.
The question depends on a file or screenshot. Test in the test channel whether your app can read the attachment. If it cannot, hand off every question that depends on one. An unreadable attachment is a handoff, never a guess.
An emoji or canned acknowledgement counts as a response. An emoji or a canned “we’ve got this” does not answer the request. If your response-time target counts it, change the rule, and see the SLA guide linked above.
The customer’s whole team saw a wrong answer. Correct it in the same thread, then log the miss so the source article or the handoff list gets updated.
If you want one shared queue for these threads, Weft (weft.day) is live for Slack Connect: every customer message in a shared channel becomes a thread in one queue, and replies post back under the replying person’s own name. Its AI drafting agent is planned, not live.