Naveen Rao, VP of AI at Databricks, put it bluntly at a conference last year: "A lot of the stuff people are delivering is a chatbot. That is sh!t. It's the worst f*cking interface I've ever seen for most applications." He wasn't attacking large language models. He was attacking the habit of wrapping every AI capability in a text box and calling it a product.
That habit has reached Slack. The default move, when teams add AI to their workspace, is to open a DM with a bot and start typing prompts. Sometimes that's right. Most of the time it isn't-and understanding why matters before you decide how AI should actually work in your team's day.
Why chat became the default (and where it earns it)
The chatbox became the default AI interface because it was the cheapest to ship and the right thing to ship at the time. It works when the user does not yet know what they want. It fails when the user knows exactly what they want, and the blank text box becomes a tax on every interaction.
That framing matters. Chat earned its position. A mediocre model with great UX beats a great model with terrible UX every time. ChatGPT didn't win because GPT-4 was the best model when it launched-it won because the chat interface was dead simple. Type, get answer, move on. The blank box removed every configuration decision that had previously sat between a user and a useful output.
But ChatGPT is a general-purpose assistant. Its whole job is open-ended conversation. The chat interface pattern gets cargo-culted because ChatGPT did it and ChatGPT is successful. But ChatGPT's whole thing IS chat. It's a general-purpose assistant. Most AI products aren't general-purpose-they're doing specific things for specific workflows. A focused tool should have a focused UI.
Slack is not a general-purpose assistant. It is a place where specific, recurring, high-stakes work happens: incident triage, standup summaries, support escalations, launch comms, onboarding questions. Those jobs have known shapes. They don't need the user to invent the question from scratch every time.
The structural problem with chat as the only shape
Chat is a pull model. The user initiates. The AI reacts. For exploration and drafting, that's fine. For the majority of valuable AI work inside a team channel, it's the wrong architecture entirely.
Consider what "pull" requires in practice. Someone in #incidents has to remember to open a bot DM, describe the current alert, ask for a summary, copy the result back into the channel, and tag the right people-all under pressure. The moment they're heads-down dealing with the actual incident, the bot sits idle, waiting for a prompt that won't come.
Chat interfaces impose a specific architecture on your AI features: every action begins with a human prompt, every session is ephemeral, and the system waits idle between exchanges. Most AI features get built as chat interfaces-but chat is the wrong abstraction for a large fraction of valuable AI work.
The alternative isn't more powerful chat. It's a different shape altogether: event-driven AI that runs when something happens in the channel, drafts something relevant, and waits for a human nod before it posts.
What ambient AI looks like when it works
UI design for AI agents is the practice of building interfaces where autonomous software systems take actions on behalf of users. Gartner projects that 40% of enterprise applications will integrate task-specific AI agents by end of 2026, up from under 5% in 2025. Most of those implementations won't be chatbots. Most of those agents are not chatbots. They are event-driven processes that run in the background, surface recommendations, and escalate when they hit the edges of their authority.
In Slack terms, that means AI that watches for specific triggers-a new Zendesk ticket tagged urgent, a PR merged to main, a question in #general that matches a pattern your docs can answer-and then acts without being asked. The user's job shifts from prompting to approving. That's a meaningful reduction in cognitive load, especially at scale.
Here's a quick map of which interface shape fits which job:
| Job type | Chat fits? | Better shape |
|---|---|---|
| Exploratory research, drafting | Yes | Chat |
| Answering recurring team questions | Weakly | Triggered response with source link |
| Incident summaries | No | Event-driven, ambient |
| Standup compilation | No | Scheduled, structured pull from linked tools |
| New-hire onboarding questions | Weakly | Channel-aware suggestion, not DM bot |
| Strategic one-off analysis | Yes | Chat |
2026 is already being described as the year of AI fatigue. For product leaders, this creates a new challenge: we need to define ways to approach UX for AI without making AI-powered products exhausting, inconvenient, risky, and unsustainable. Adding a chat bot to every Slack channel is not a solution to that problem. It's an instance of it.
The case for chat anyway (the steelman)
There is a real argument for chat-first that deserves a fair hearing. Open-ended prompting is genuinely more flexible than any pre-baked trigger you can design today. The trigger you build covers the situations you anticipated. Chat handles the ones you didn't. For teams that are still learning which AI jobs matter most, a chat interface is honest about its own incompleteness-it admits that the human is still figuring out the right questions.
The chatbox was the right thing to ship at the time. It works when the user does not yet know what they want. There's a version of every team's AI journey where the chat box is the right first tool: a low-commitment way to run experiments and discover which questions actually recur before you invest in structured automation for any of them.
The error isn't starting with chat. It's staying there after you know what the recurring jobs are. Once you can name the five questions your team asks an AI bot most often, those five should be triggers, not prompts.
The 233% growth number is telling. The fastest-adopted AI features in Slack aren't the ones that require users to type prompts. They're channel summaries, message recaps, and search-features that surface value without demanding a blank-page prompt from the user. That pattern points toward where the interface should go, not where it started.
The right question isn't "should we add AI to Slack?" It's "should this AI job start with a human prompt, or should it start with an event?" Most of the time, for most teams, the answer is the event.
AI chat interface in Slack: common questions
When is a chat interface actually the right choice for AI in Slack?
Chat works when the user genuinely does not know what they want in advance-exploratory research, drafting novel content, debugging an unusual problem. It also works for general-purpose assistants where the whole point is open-ended flexibility. For recurring, well-defined jobs like incident summaries or standup rollups, a triggered, event-driven approach reduces friction and produces more consistent output.
What is an ambient AI agent in Slack?
An ambient AI agent watches for specific events-a message pattern, an incoming alert, a status change in a linked tool-and acts without being prompted. It drafts a response or summary, then waits for human approval before posting. The user's role shifts from initiating to approving, which is faster and requires less context-switching than opening a separate bot conversation.
Does draft-and-approve actually keep humans in control?
Yes, structurally. The agent does the retrieval and drafting work; no output reaches the channel without a human reviewing and approving it. This matters both for accuracy (a fast human review catches model errors before they're visible to the team) and for trust-colleagues know a person stood behind every message, even if AI helped write it.
Why do most AI products in Slack default to chat if it's suboptimal?
Because chat is the cheapest interface to ship. One text input, one response pane, and you have a functional demo. Ambient and event-driven AI requires deciding upfront which events matter, what response looks like, and how to handle edge cases-design decisions that take more time but produce better adoption once they're made.
How do I know when to switch from chat to event-driven AI in my Slack workspace?
Track which questions your team's AI bot gets asked most often. If the same five requests appear repeatedly-status checks, thread summaries, doc lookups-those are candidates for triggers. When a job is predictable and recurring, designing a trigger is worth the upfront cost. Keep chat for everything genuinely novel or exploratory.