AI inside Slack that summarizes channels and threads, recaps what you missed, and answers questions from your workspace history.
Last updated
Slack AI is search and summarization built into Slack: thread and channel summaries, recaps of what you missed, and a search layer you can ask questions in plain language rather than guessing keywords. Unlike Otter.ai or Zoom AI Companion, none of it involves audio. It works on the written backlog, the channels and threads that pile up whether or not anyone reads them. The pitch is time saved. The variable that actually decides the outcome is something no vendor page asks about: whether your workspace's accumulated conversation is an archive worth querying or noise with timestamps. Two companies with identical headcount and identical seat counts land on opposite sides of that line.
An archive is where the reasoning behind decisions ended up. A backlog is volume that was never worth reading in the first place, and summarizing noise produces shorter noise. The distinction is testable before you spend anything. Pick three decisions your team made last quarter and try to reconstruct why each one went the way it did, using Slack search by hand. If the reasoning is in there and finding it is merely tedious, Slack AI turns a tedious retrieval into a cheap one, which is a real and repeatable gain. If the reasoning is not in there because it happened in a call, a DM, or someone's head, no model retrieves what was never written down. That test takes twenty minutes and predicts the outcome better than any trial.
Any AI layer over your history inherits whatever your workspace keeps. If retention deletes messages after a few months, model quality is irrelevant to a question about last year, and short retention is usually deliberate rather than accidental, set by legal for exactly the reason that makes it inconvenient here. Free workspaces have historically limited how far back history is visible at all, which is a second, separate ceiling.
The inverse is the part teams miss. Extending retention to make the AI more useful also extends what is discoverable in litigation and what is exposed if the workspace is ever breached. That is a legal decision wearing a product costume, and it should be made by the people who own the retention policy rather than by whoever is running the AI pilot. Find out what your workspace actually retains, and who set it, before the evaluation rather than after.
If your organization records decisions in Notion, tracks work in Jira or Linear, and writes specs in Coda, then Slack holds the coordination around decisions rather than the decisions themselves. It knows the team is shipping Thursday. It rarely knows why Thursday. Slack has been extending search across connected tools, so this boundary is moving and you should verify what your plan actually connects today rather than assuming either the narrow version or the expansive one. The underlying judgment holds either way: an assistant answers well about the surface it can see, and a strongly documented organization may get more from the AI inside its documentation tool than from the AI inside its chat tool.
A summary compresses a conversation into its apparent consensus, and the losses are predictable enough to plan around. The objection raised once and never repeated tends to disappear. A decision reversed in the last few messages can be reported as the original decision. The difference between someone committing to do a thing and someone agreeing the thing should happen collapses into one sentence. Tone goes first of all, so a joke or a sarcastic aside can be read back as a plain statement of intent.
For catching up, none of that matters much. For anything consequential, open the thread. The summary is excellent at telling you which thread to open, and that is most of the value on offer here.
Results stay scoped to what you can already see: the channels you belong to and your own conversations. It does not surface private channels you were never in. This is worth stating plainly in your rollout note, because the first reaction from employees is that the company has started reading Slack with a machine, and the accurate answer is that the feature does not widen anyone's access. It is also worth being honest about the corollary: because scope is per-user, an administrator and a new hire asking the same question can get different answers, and neither is wrong.
Whether your content is used to train models is a separate question and a fair one to raise in review. Slack's stated position has been that customer content is not used to train generative models and that the models serving these features operate within Slack-controlled infrastructure. If that matters to your legal or security team, take the current commitment from Slack's own documentation and put it in writing before the question arrives in an all-hands, rather than relying on any secondhand summary including this one.
Who it fits: a mid-size or large workspace with genuine volume, a long-lived history, and a culture that argues in channels rather than in DMs. For everyone else, the honest recommendation is to fix where decisions get written before paying to search where they did not.
Someone returning from a week away, or covering for a colleague across time zones, reads channel recaps and thread summaries instead of scrolling days of unread messages. This is the use case that survives contact with reality most reliably, because it depends only on volume existing rather than on the content being well organized. The value scales with how much you actually missed, which is why the same feature feels essential in a busy workspace and pointless in a quiet one.
When a settled question resurfaces months later, asking in plain language across accumulated history beats guessing which channel it happened in. The honest precondition, and the reason this list is short: it only works if the reasoning was written in a channel the asker can access and is still inside your retention window. Where teams debate in threads and then post the outcome, this is the strongest argument for the product. Where they debate on calls and post only the conclusion, it returns the conclusion you already had.
Slack AI is a capability layered on paid Slack rather than a standalone product, and its commercial packaging has moved over time: it has been sold as a per-seat add-on on top of an existing paid plan, and it has also been positioned as part of paid plans, with more advanced search and agent capabilities licensed separately. Because packaging is exactly the kind of thing that changes between renewals, price it from Slack's current plan documentation or your account team rather than from any third-party description. What holds regardless of the current arrangement: it is not something a free workspace gets, cost tracks seats rather than message volume, and it rides on top of what you already pay for Slack. So the number to compare against a dedicated alternative is the incremental cost per seat, not the whole Slack bill.
Check your own plan rather than a description of it. Slack has packaged these features as a paid per-seat add-on and has also bundled them into paid tiers, with more advanced capability licensed separately, and that arrangement has changed more than once. The only durable answer is that it requires a paid Slack plan and that cost scales per seat.
No. Summaries and answers stay inside the permissions you already have, so the feature does not widen anyone's access to content. One consequence worth communicating during rollout is that scope is per-user, which means an administrator and a new hire can ask the same question and get legitimately different answers.
Much less useful, and this is the single most underrated constraint. Retention sets a hard ceiling on what any AI layer can retrieve, and the historical questions people most want answered are the ones a short window has already deleted. Extending retention to compensate is a legal decision about discoverability, not a product setting, so raise it with whoever owns the policy.
Slack's stated position has been that customer content is not used to train generative models and that the models behind these features run within Slack-controlled infrastructure. If your security or legal team needs that as a commitment rather than a summary, get the current terms from Slack directly, since this is precisely the kind of language vendors revise.
They solve unrelated problems and the choice depends on where your information is stranded. If people are losing decisions inside long written threads, this is the right category. If they are losing them inside calls nobody took notes on, you want transcription instead, and teams frequently end up running both because the two failures are independent.
Full review coming soon.