FlowKit

Building an AI Slack Bot with n8n: Your Team's Internal Assistant

Published 26 July 2026 · 7 min read

Slack is already where your team asks its questions — about internal procedures, time off, the product, the last deployment. An AI Slack bot wired into n8n turns that place into an internal assistant: mention the app in a channel or DM it, and an AI agent replies in the thread, with conversation memory and, if you plug it into your knowledge base, sourced answers. Good news compared to Discord: n8n ships a native Slack Trigger here, which makes the architecture far more direct than the setup described in our AI Discord bot guide. This guide covers the whole circuit: creating the Slack app, triggering, the anti-loop filter, per-thread memory and the RAG connection.

What an internal Slack assistant actually changes

Three use cases come up again and again with teams that deploy this kind of bot:

  • Answering recurring questions: leave policy, expense reimbursement procedure, dev environment setup, product talking points. The same questions come back every week, and it's always the same people answering them.
  • Summarizing a thread: a 60-message thread about a production incident, condensed into five lines for the person arriving after the fact.
  • Triaging incoming requests: an #internal-support channel where the bot qualifies each request (IT, HR, product), answers directly when it can, and routes the rest to the right person.

The impact of this kind of assistant is now rigorously measured. The study by Brynjolfsson, Li and Raymond, "Generative AI at Work" (NBER, 2023), conducted on more than 5,000 customer support agents, showed that access to an AI assistant increased productivity by about 14% on average — with the biggest gain for the least experienced agents. Transposed to an internal assistant: it's the newcomers and junior teams who benefit most, because the bot gives them instant access to the knowledge accumulated by everyone else.

Step 1: create the Slack app and connect it to n8n

Everything starts on api.slack.com, where you create a new app attached to your workspace:

  • Create the app ("Create New App", from scratch or from a manifest) and give it a meaningful name — that's the name your team will mention.
  • Grant the OAuth scopes under "OAuth & Permissions", on the Bot Token side. At minimum you need the ability to post messages (chat:write) and to receive the events you care about — typically app mentions (app_mentions:read) and, if you want a private conversation mode, reading direct messages. Slack shows each scope's description as you add it: grant only what the workflow actually needs, and widen later if necessary.
  • Install the app to the workspace ("Install to Workspace"): Slack then generates the Bot Token, to be copied into a Slack credential in your n8n instance — never in plain text inside a node. n8n's Slack node and Slack Trigger each offer their own credential type; follow the node's configuration screen, which states exactly which token it expects.
  • Invite the bot into the channels where it should operate (/invite @your-bot): without that invitation, it sees nothing that happens there.

Step 2: trigger the workflow with the Slack Trigger

This is where Slack stands apart: n8n provides a native Slack Trigger, backed by Slack's Events API — no community node or hand-rolled webhook needed, unlike the setup required on the Discord side. Two triggers cover most of an internal assistant:

  • App mention: the workflow starts when someone writes @your-bot in a channel where the bot is present. This is the "public assistant" mode: the question and answer are visible to everyone, which feeds collective knowledge.
  • Direct message: the workflow starts when someone messages the bot privately. This is the mode suited to HR or individual questions.

The received event contains everything the rest of the workflow needs: the message text, the channel ID, the author's ID, and the message's ts (timestamp) — which serves both as the message identifier and as the thread key.

Step 3: the anti-loop filter (the classic mistake)

Here is the trap almost everyone falls into on the first try: the bot replies, its reply is a message, that message fires an event, the event re-runs the workflow, which generates a new reply… and the bot talks to itself forever, burning an LLM call on every turn.

The fix is simple but non-negotiable: an If (or Filter) node placed immediately after the trigger that discards any event emitted by the bot itself. Concretely, you reject events whose author matches the bot's ID, or that carry an app/bot identifier in their payload. Make it the very first node of the workflow, before the AI agent: every execution avoided is also an LLM call saved.

Step 4: the AI agent with per-thread memory

Next, wire up an AI Agent node with a system prompt that frames the role ("You are team X's internal assistant; you answer concisely; if you don't know, you say so and offer to route to a human"), and above all a conversation memory with the right session key.

The right Session ID on Slack is the channel + thread combination: Slack identifies each thread by the ts of its parent message (thread_ts for replies, ts for the message that opens the thread). Building the session key on that pair means each thread keeps its own history — two parallel conversations in the same channel never contaminate each other, and a follow-up question asked in the thread is understood in its context. That's exactly the principle detailed in our article on conversation memory for an AI agent in n8n, applied at Slack-thread granularity. In direct messages, the DM channel's ID is enough as the key.

Step 5: reply inside the thread

Last building block of the base circuit: the Slack node (send-message operation), configured to reply inside the thread rather than in the channel. Just pass the parent message's ts (the one received by the trigger, or its thread_ts if the question was already inside a thread) as the destination thread. Result: the question and the agent's answer stay grouped in the same thread, the channel stays readable, and the whole team can find the exchange later.

That same Slack node can do much more — notably the send-and-wait-for-response operation, the button-based human-approval mechanism we detail in our article on the Wait node and interactive Slack buttons. Combined with the agent, it enables a valuable pattern: the bot proposes an action (create a ticket, notify a manager) and waits for a validation click before executing it.

Step 6: plug the agent into your knowledge base (RAG)

An agent that answers from memory is fine; an agent that answers from your internal documents is what makes the assistant genuinely reliable. The principle: vectorize your documentation (procedures, product docs, HR FAQ) in a database like Supabase with pgvector, then give the agent a vector-search tool it queries before answering. The full setup — ingestion, embeddings, queries — is detailed in our RAG guide with n8n and Supabase.

Two reflexes are worth adopting from day one: ask the agent to cite its sources (the title or link of the document used) in every answer, and plan for an honest reply when the knowledge base contains nothing relevant, rather than an improvisation. It's the same architecture as our RAG chatbot on WhatsApp — only the input and output channel changes, the RAG core stays identical.

Slack, Telegram or Discord: which channel for which assistant

Criteria Slack Telegram Discord
Native n8n trigger Yes (Slack Trigger, Events API) Yes (Telegram Trigger) No — community node or interactions webhook
Natural ground Internal team, company Personal assistant, notifications Community, public support
Threaded conversations Yes, native Limited Yes (threads)
Typical use case Internal HR/product/support assistant Quick-to-deploy personal bot Community bot

For an internal assistant, Slack is almost always the right choice: it's where the team already works, threads naturally structure conversations, and the native trigger makes the setup fast. For a personal bot, our AI Telegram bot guide remains the shortest path.

In summary

An AI Slack bot with n8n comes down to five building blocks: a Slack app created on api.slack.com with the right OAuth scopes, a Slack Trigger on mentions or direct messages, an anti-loop filter as the very first node, an AI agent whose memory uses the channel + thread pair as the session key, and a reply posted inside the thread via the parent message's ts. Then plug the agent into your vectorized knowledge base and you get an internal assistant that answers with sources — the one that saves the most time for the newest members of the team, as the NBER study cited above shows. To start from a proven foundation rather than a blank page, the RAG Assistant Pack (€119) provides the document ingestion and the citation-backed RAG chatbot, ready to rewire onto your Slack Trigger.

FAQ

Frequently asked questions

Does n8n have a real Slack Trigger fired by incoming messages?

Yes. Unlike Discord, n8n ships a native Slack Trigger built on Slack's Events API: it can fire a workflow when the app is mentioned in a channel, when it receives a direct message, or on other workspace events. You first need to create a Slack app on api.slack.com, grant it the required OAuth scopes and install it in the workspace.

How do you stop the Slack bot from replying to its own messages in a loop?

That's the classic trap: the bot's reply is itself a message event, which re-fires the workflow, which generates a new reply, forever. The fix is an If (or Filter) node placed right after the trigger that discards any event authored by the bot itself — by comparing the author's ID to the bot's, or by rejecting events that carry a bot identifier. This filter must be the very first node after the trigger.

How do you give the bot per-thread conversation memory?

By using the thread identifier as the session key in the AI agent's memory node. Slack identifies each thread by the timestamp (ts) of its parent message: combining the channel ID with that thread_ts as the Session ID means each thread keeps its own history, and two parallel conversations in the same channel never mix.

Can the bot reply inside the thread rather than in the channel?

Yes, and it's strongly recommended to keep the channel readable: n8n's Slack node lets you specify the destination thread by passing the parent message's ts when sending. The question and the agent's answer stay grouped in the same thread, visible to the whole team.

Bundle FlowKit Complet

€269