Give your AI agent a seat in Slack
The first time you let an agent post to Slack on its own, you hold your breath. Reading messages is one thing. Writing them — into a channel your whole team watches, under a name that looks official — is the moment the demo becomes production. Get the connection right and Slack turns into the place your agents actually do work: triaging incidents, answering routine questions, posting the digest nobody wants to write. Get it wrong and you have a bot with too many keys and no memory of what it did.
This is a practical guide to wiring Slack to an AI agent: what "connect" really means, the two paths to get there, the tokens and scopes involved, and the guardrails that let you sleep.
What "connect Slack" actually means
"Connect Slack to an agent" collapses four different capabilities that carry very different risk. Reading is the tame one: pulling channel history, threads, and user names so the agent has context. Searching is close behind — querying across the workspace to find the relevant thread. Posting is where it gets real: sending a message, replying in a thread, or DMing a person. And reacting — adding an emoji, updating a message — is the small stuff that makes an agent feel like a teammate instead of a webhook.
Most teams want all four eventually. The mistake is granting all four on day one. Read access can be broad; write access should start almost embarrassingly narrow and earn its way up.
Two paths: the Slack MCP server, or your own tools
Since agents talk to the outside world through tools, the real question is where Slack's tools come from. There are two credible answers in 2026.
Use Slack's official MCP server. Slack shipped its own MCP server to general availability in February 2026, and it is the fastest way to get an agent searching channels, sending messages, and adding reactions. It handles auth through confidential OAuth 2.0 with PKCE, issues per-user tokens that admins can revoke centrally, and keeps expanding its tool set. If your needs are the common ones, start here.
Build your own Slack tools. The moment you want a Slack action fused with your own data — "summarize this incident channel, then open a ticket and link it back" — or you want guardrails tighter than a generic server allows, you build the tools yourself against the Slack Web API. This is more work and more control. Our guide to building an MCP tool walks through the shape; the Slack-specific part is mostly about scopes and restraint.
These are not mutually exclusive. A common setup is the official server for reads and search, plus a couple of custom write tools that enforce your own rules before anything reaches a channel.
The token and the scopes
Whichever path you take, a Slack app sits underneath it. You create the app, choose its permissions, and install it to your workspace, which mints a bot token — a string starting with xoxb- that authenticates every call the agent makes. Treat that token like a production database password, because that is roughly what it is.
Permissions are declared as OAuth scopes, and this is where discipline pays off. A read-and-post agent typically needs only a handful:
channels:read # list public channels
channels:history # read messages in them
chat:write # post messages
users:read # resolve user IDs to names
search:read # search across the workspaceAdd more only when a workflow demands it: reactions:write to let the agent acknowledge with an emoji, groups:history for private channels, files:read to pull an attachment. Every extra scope widens the blast radius if the token ever leaks. The safest agent is the one that literally cannot do the thing you never wanted it to do.
Reading is easy. Writing is where the care goes.
A read-only Slack agent is low-stakes; the worst case is a wrong answer in a DM. A writing agent can page an on-call engineer at 3 a.m. or post a half-finished thought to a channel of two hundred people. So the guardrails cluster around writes.
Three that matter most: restrict the channels the agent may post to, so an experiment in a sandbox channel can never spill into #general; keep a human in the loop for anything irreversible or public-facing until the workflow has earned trust; and log every message the agent sends, with the reasoning that led to it, so a bad post is something you can find and undo rather than discover from a confused colleague. That last point is not optional at scale — it is the difference between an agent you can operate and one you just hope about, a theme we go deeper on in our agent observability guide.
How the agent knows something happened
An agent that only acts when you ask is useful. An agent that reacts to Slack on its own is where the leverage is, and there are two ways to feed it events.
The Events API pushes an event to a webhook the instant a message is posted or a reaction is added. It is the right choice for real-time work — triage the moment an alert lands, answer a question seconds after it is asked. Polling is the humble alternative: read channel history on a schedule and act on what is new. It is easier to run and perfectly good for digests, end-of-day summaries, and anything that does not need to be instant. Plenty of production setups use both — events for the urgent channels, a nightly poll for the rest.
Where OBTO fits
OBTO is a place to host the Slack tools your agent uses and to own what happens after. You can stand up the Slack MCP server or your own custom tools on the platform, and the same rules we have been describing become defaults rather than chores. The bot token lives server-side, never in a prompt or a client — the same discipline we argue for in agent secrets management. Tools are data on OBTO, so a Slack write tool can be created, versioned, and restricted like any other record. And every call the agent makes — the message it posted, the channel, the tokens it burned — lands in the Glass Receipt, the per-run ledger that makes an agent in your workspace auditable instead of mysterious.
Slack is the second connector many teams reach for, right after a database. If you have already wired one, the pattern will feel familiar — see connecting Postgres to an AI agent for the same discipline applied to data.
Getting started
The order that keeps you out of trouble: create the Slack app and grant the narrowest scopes that cover your first workflow; host the tools on a platform that keeps the token server-side and records what the agent does; give the agent read access first and prove it behaves; then open up a single write action into a single channel and watch it for a week. Our getting-started guide takes about ten minutes, and the free Builder tier includes Glass Box tracing — enough to see exactly what your agent says in Slack before anyone else does. Pricing is published and per-app, not per-seat, so adding the agent to more channels never costs you more chairs.
An agent in Slack should feel like a careful new hire: eager, useful, and supervised until it has earned the room. Wire it that way and Slack stops being a place you demo automation and becomes a place it quietly runs.