Slack AI Agent: How I Built One That Runs My Agency's Ops

A Slack AI agent is an AI that works inside your business tools on its own and talks to you through Slack. Mine runs on Claude Code on a Mac mini in my office. Every weekday morning it reads my inbox and my call notes, and it posts a numbered list of what it wants to do. I reply "approve 1 and 3" from my phone, and it does the work. It drafts emails but never sends them. It makes client changes on a preview link, never on the live site. The only new costs are my Claude subscription and Slack.

If you want the case for agents first, I wrote that up in building AI agents that actually work.

Why I built it

My wife had our second child this summer, and my working hours went close to zero overnight. The inbox didn't care. Emails piled up, and some of them were clients waiting on me.

I was already using AI every day, but in a chat window. I'd paste in an email, explain the client, explain the project, get an answer, and start from scratch the next day. Every conversation forgot the last one. That back and forth was eating the little time I had.

So I made a bet. If I gave an agent real access to every tool my business runs on, plus a written record of how we do things, it would stop forgetting. And because the repeatable parts would live in code, it would get better every week instead of starting over.

A few months in, the bet held. One client sends long, detailed feedback every review cycle on the app we're building for them. Working through a round of it used to take me about five hours, sometimes the whole day. Now I spend about five minutes kicking off the changes from my phone, often while I'm walking the dog or doing school drop-off. The agent makes them on a feature branch and sends me a preview link. Back at my desk I review, give it another round of notes, and send the finished changes to the client. That's about an hour in total.

What makes an AI agent different from Zapier, n8n or Make?

Zapier follows a fixed path, and an agent decides what to do next. A zap says "when a form comes in, add a row to this sheet." An agent reads a messy email from a client, works out what they're asking for, checks the project it's about, and proposes the next step. That move out of "if this, then that" is the whole difference.

Tools like Zapier, n8n and Make are code with prebuilt connectors. When you use one, you play by its rules, its syntax and its limits. They're built to move data between apps. An agent can do the work itself.

Here's an example none of them can touch. My agent can draft a blog post, put it on a preview branch of our site, open it in a real browser with Playwright, screenshot it at phone, tablet and desktop widths, and fix whatever looks wrong. That loop, from draft to visual check to fix to go-live, is one of the quieter perks of owning a custom-built website.

The bigger example is testing. If your website form kicks off a chain of actions (an email, a CRM record, a Slack alert), the agent can open the form in a browser, fill it out the way a customer would, and follow the data through every step. It can run a whole matrix of cases, like a missing field, a long answer, or a different service, instead of the two test values you'd type by hand.

The prebuilt connectors used to be the main reason to pay for those tools. That advantage is mostly gone. An agent can read any app's API documentation and write the connection in minutes.

Simple, single-step automations are still fine in Zapier. If a form submission just needs to land in a spreadsheet, leave it there.

What does the architecture look like?

The setup has six parts. Your numbers will differ from mine, so treat these as the shape, not a spec.

1. A knowledge base. Plain text files about your business, your customers, how you write, and who does what. The agent reads these before it makes any judgment call.
2. Playbooks, written in plain English. Email triage, turning call notes into tasks, the morning review, weekly cleanup. Each one says when it runs, whether it needs your approval, and what "done" looks like.
3. Scripts for the work itself. Small programs that talk to Slack, your project tool, your CRM, your email. The agent decides what to do, and the scripts do it the same way every time.
4. A schedule. Mine has three lanes: a weekday morning run that posts a brief, a listener that wakes the agent when I post in Slack, and a Saturday cleanup.
5. Slack as the control panel. The agent posts numbered proposals, and I approve them by number.
6. A work log. Every run reads it first and writes to it last, so the agent knows what it already did.

If you've seen Anthropic's Agent Skills, this will look familiar. A skill is a folder with an instructions file that starts with a name and a one-line description. The agent reads only those descriptions until a task needs one, then loads the full instructions. My playbooks work exactly that way. Anthropic's write-up on skills makes the case for the scripts too: some jobs need "the deterministic reliability that only code can provide," and a script can run without the model reading it, so a repeat job costs almost nothing. Anthropic published skills as an open standard in December 2025, at agentskills.io, so this structure isn't locked to one AI vendor.

One difference from the standard: skills usually keep their scripts inside their own folder. Mine share one folder, because several playbooks call the same scripts. Either way works.

How to build a Slack AI agent for your business

Start with one job.

1. Pick a single job you do every week that annoys you. Email triage is a good first one.
2. Write it down as a playbook. What to do, when to run, what needs your approval, and what "done" looks like.
3. Connect the tools that job needs. Create a Slack bot for the agent, then give it scoped access to each app it touches, and write a small script for each action, like "create a task" or "draft an email."
4. Make Slack the control panel. The agent posts numbered proposals, and you reply with the numbers you approve.
5. Run it by hand in Claude Code until you trust the output. Only then put it on a schedule.
6. When you add a second job, add the work log and a weekly cleanup run.

Step six is the one people skip. I skipped it too.

Which tools should the agent have access to?

Give it scoped access to every tool it needs to do the job, and nothing else. I create a separate API key for each tool, limited to what the agent should be able to do. MCP connectors are another route. Either way, the access lives on the machine that runs the agent.

Here's the checklist I'd start from:

• Email, calendar and files. I set up a Google Cloud project with scoped access to Gmail, Sheets, Docs, Slides and Drive. Gmail access is draft-only, so it can't send.
• Your CRM, like HubSpot or GoHighLevel, so it can look up a customer or a lead before it answers anything.
• Your bookkeeping software.
• Your website, whether it's custom-built or on Webflow or Squarespace.
• Your phone system. I use Quo, and the agent subscribes to its webhooks. When I miss a call or someone leaves a voicemail, it flags it in Slack right away, so a high-value lead gets a callback or a text right away.
• Your analytics: Google Analytics and Search Console.
• Anything else the work calls for. Mine has DataForSEO for keyword research.

Email triage turned out to be the most useful job of all, but only after the agent had real context about my customers. Without that, it's a summary. With it, the agent knows which client is waiting on what.

The step everyone skips: cleanup and the work log

A weekly cleanup keeps your agent's instructions true. Your business changes. Something you wrote down on day one is slightly wrong by day fifty, and the agent will treat whatever is in its files as gospel for every request after that. Agents also write notes to themselves, and those notes pile up. My first cleanup found two files contradicting each other on which Slack channel to post in, pointers to files that no longer existed, and one rule copied into four places that had started to drift apart. Now a Saturday run audits the instructions, flags contradictions, and trims the log.

The work log is the agent's memory. If your agent doesn't have a database, the log is the only way it knows what it already did. Without it, two runs can redo the same task or overwrite each other's work.

What breaks when you run an AI agent unattended?

These were the three that cost me the most time.

A dead machine is silent

My Mac mini lost power for about two days in late August. Nothing ran, and nothing reported it, because a computer that's off can't post an error. I found out when I asked why things were quiet. You need a check for runs that didn't happen, not just runs that failed.

Slack timing takes tuning

The agent has to know what to pick up and when. At first, when the agent started a thread itself, my replies in that thread never reached it, and I had to repost at the top level.

Two agents on one Slack app split your messages

I run a second agent for another business, on two machines. Both were listening through the same Slack app, and Slack delivers each message to only one listener, picked at random. About half the messages reached the wrong machine. Tasks got duplicated, one alert posted twice, and the two agents' notes drifted apart. The fix was one Slack app per agent, so you call each one by name and it's always clear who owns what.

How much does a Slack AI agent cost to run?

The hard costs are your Claude subscription and Slack. Everything else in the stack (your CRM, your email, your phone system) you're already paying for, agent or not. Claude's Max plan starts at $100 a month and includes Claude Code, according to Claude's pricing page.

For comparison, Zapier's Team plan is $103.50 a month for 2,000 tasks on monthly billing and $253.50 for 10,000. Go over your allowance and extra tasks bill at two and a half times the base rate. If you run a real chunk of your business through it, a few hundred dollars a month is normal.

Cost isn't the main reason to build this, though. The main reason is control.

My setup runs on a subscription and a Mac mini because I wanted it as cheap as possible. That has a price: I own the uptime, and the power outage proved it. If the agent is critical to your business, host it in the cloud and run it on the API instead. It costs more, but it doesn't go dark when the power goes out.

Where to start

Pick the job that ate your morning today. Write down how you do it, give the agent access to the two or three tools it touches, and run it by hand for a week. If you'd rather have someone build it with you, that's the kind of work we do in custom apps and agents.