AI systems / 28 Jun 2026

How to build a Slack agent your team can talk to

Two of the AI systems I run do not have a dashboard. They live in Slack, and the team talks to them by name.

We call them Billy and Mikki. Billy writes and publishes blog content, drafts email campaigns and makes campaign images. Mikki watches our social comments across Instagram, Facebook and Meta ads, and replies to them. To use either one, someone types a message in a channel, the same way they would to a colleague.

This post is how that is put together, in plain terms. It is less work than it looks.

What it actually is

Strip away the word "agent" and a Slack bot is three things:

• A Slack app, which gives you a bot identity and a way to receive messages.
• A small program running somewhere, which receives those messages and decides what to do.
• A model API, which is the part that reads, reasons and writes.

That is the whole shape. Everything else is detail bolted onto those three.

The stack you need

Here is the actual shopping list. Billy and Mikki both run on close to this:

• A Slack app. Free. You create it at api.slack.com and it gives you a bot token.
• Somewhere to run code. I use Railway. It runs a Dockerised Python service, restarts it if it falls over, and gives it a small persistent disk. A cheap always-on box is all you need.
• Python, with Slack Bolt. Bolt is Slack's own library for receiving messages and replying. This is the glue between Slack and your code.
• A model API key. This is the brain. I use Claude: Sonnet 4.6 for the real reasoning and writing, Haiku 4.5 for the cheap high-volume jobs like sorting a comment into a category. One key covers both.
• A database. Small. SQLite, sitting on that persistent disk. More on why below.
• An image key, only if you want images. Billy makes campaign visuals with OpenAI's gpt-image-2, so it carries an OpenAI key on top of the Claude one. If your agent never makes pictures, skip this entirely.

You do not need to build a front end. Slack is the front end. That is the whole point.

Setting it up on the Slack side

Loosely, the path is:

1. Create a new app at api.slack.com.
2. Give it a bot user and a name. That name is what your team will talk to.
3. Turn on the permissions it needs (Slack calls them scopes): read messages, post messages, maybe upload files.
4. Subscribe it to events, so Slack tells your program when something happens.
5. Install it to your workspace and invite the bot into a channel.

The one tip that makes this easy: turn on Socket Mode. It lets your program hold an open connection to Slack instead of you having to host a public web address for Slack to call. For an internal team tool, it removes most of the fiddly setup.

How the team talks to it

There are two ways to reach the agent, and the difference matters more than it sounds.

The first is mentioning it: @Billy, what do you think?. Slack only sends your program an event when the bot is tagged. Clean and cheap. The agent only sees messages aimed at it.

The second is letting it listen. You subscribe to ordinary channel messages and react when someone uses its name. Now people write "Billy, can you publish that?" with no tag at all, and it answers like another member of the channel. This is the nicer experience. It is the one people mean when they say the bot feels like part of the team.

Guardrails, the part people skip

A bot that can post to your social accounts or publish to your store is not a toy. The guardrails are not optional, and they are where most of the real work goes.

The pattern that works for Billy and Mikki is layered, cheapest and safest first:

• Deterministic rules first. If a situation has a fixed correct answer, code it as a plain rule with no model involved. Pricing, warranty and legal questions get routed, not improvised.
• Approved knowledge second. For known topics, answer from a vetted store of product and policy facts.
• The model last. Only call Claude for the cases that are safe but not already covered by a fixed rule.

Then two habits on top. Anything that changes the outside world and is hard to undo, like publishing a blog or sending a campaign, goes through a human approval step in Slack first. And anything higher-volume or risky runs in dry-run mode, where the agent records what it would have done without doing it, until you trust it. Mikki validates each reply against its rules before it posts, and it hid no ad comments in the wild until that was explicitly switched on.

The database in the back

The database is what turns a chatbot into a system.

A bot with no memory answers each message from scratch and forgets it. A bot with a small database can hold a queue of work, remember what it already replied to, track what is waiting for approval, and keep a record you can audit later.

It does not need to be fancy. Billy keeps its editorial queue in a Google Sheet and its working state in SQLite. Mikki stores every comment decision in SQLite on a Railway disk. That is enough to know what has been handled, what is pending, and what went wrong.

The rule

Start with one agent, one job, one channel.

Give it the smallest task that is genuinely useful, put a human approval step in front of anything it sends to the outside world, and let your team talk to it by name. You can always hand it more once you trust it. The hard part was never the model. It is everything you build around it.