If your bot works in DMs but goes weirdly silent in Slack channels, start by blaming your event handling.
Not GPT-5.
Not Claude.
Not your prompt.
We lost a bunch of time learning this the dumb way.
Our bot was great in 1:1 chats. In Slack DMs it could hold context, call tools, summarize results, and generally look like a competent AI teammate.
Then we dropped the exact same bot into a busy channel.
It became a ghost.
Sometimes it replied.
Sometimes it replied twice.
Sometimes the backend finished successfully and Slack showed nothing.
Sometimes it answered in the wrong thread.
That kind of failure is extra annoying because it makes you debug the wrong layer first.
We blamed the model.
We swapped GPT-5 for Claude.
We trimmed prompts.
We argued about whether Llama or Qwen would be more reliable in channels.
None of that mattered.
The real problem was that we treated Slack group chats like DMs, and Slack absolutely does not work that way.
This is the first thing I’d check in any Slack bot.
A direct message to your app comes in as a message event with channel_type="im".
A mention in a channel comes in as app_mention.
Those are different event streams with different behavior.
DM example:
{
"event": {
"type": "message",
"channel_type": "im",
"channel": "D024BE91L",
"text": "Hello hello can you hear me?"
}
}
Channel mention example:
{
"event": {
"type": "app_mention",
"channel": "C123ABC456",
"text": "<@U0LAN0Z89> is it everything a river should be?",
"ts": "1515449522.000016"
}
}
That one distinction explains a lot of “works in DMs, fails in channels” bugs.
In DMs, the shape is simple: user talks to bot.
In channels, everything gets more fragile:
If your code has one generic handleIncomingMessage() path for everything, there’s a decent chance that’s your bug.
Quiet channels hide bad architecture.
If your bot mostly lives in DMs or low-traffic channels, a synchronous handler can look fine for weeks.
Then one incident channel gets busy.
Five people mention the bot.
One tool call takes 8 seconds.
One GitHub request stalls.
One retry comes in.
And suddenly your “AI reliability issue” is obviously just broken event lifecycle handling.
Slack expects a fast HTTP 200 acknowledgment.
The practical rule is simple:
you have about 3 seconds to ack
If you don’t ack quickly, Slack may retry the event, and now you’re in duplicate-processing land.
This is the dangerous flow:
app_mention
That feels natural when you first build it.
It’s also how you build a bot that disappears under load.
We moved all slow work out of the request path.
That means:
Here’s the shape in Slack Bolt for Python:
from slack_bolt import App
app = App(process_before_response=True)
def ack_fast(ack):
ack("Accepted")
def run_long_process(respond, body, logger):
user_text = body["event"]["text"]
respond("Completed")
That’s the idea, but in production I’d usually push this into a queue instead of doing everything inside the listener.
Something more like this:
from fastapi import FastAPI, Request, BackgroundTasks
import os
import json
app = FastAPI()
@app.post("/slack/events")
async def slack_events(req: Request, background_tasks: BackgroundTasks):
payload = await req.json()
if payload.get("type") == "url_verification":
return {"challenge": payload["challenge"]}
event = payload.get("event", {})
event_id = payload.get("event_id")
background_tasks.add_task(process_event, event_id, event)
return {"ok": True}
def process_event(event_id: str, event: dict):
pass
The important part is not the framework.
The important part is the split:
Reliable Slack bots are event systems first and AI apps second.
This one was nastier.
We assumed that if our worker finished and called chat.postMessage, the message would show up.
That is not safe in busy channels.
Slack rate-limits chat.postMessage at roughly 1 message per second per channel.
Per channel.
That means if your bot posts:
and three people mention it in the same thread at once, you’ve basically built a rate-limit machine.
The ugly part is that your logs can still look fine while users see silence.
We stopped treating outbound messages like free writes.
The new rules were:
That improved reliability more than any prompt tweak.
Not because the model got smarter.
Because the plumbing stopped fighting the app.
In DMs, state is easy.
In channels, state is thread-shaped.
If you reply without the right thread_ts, your answer lands in the wrong place or becomes useless noise in the channel.
A lot of teams do this:
conversations.replies
That works at first.
It’s also expensive, slow, and increasingly brittle.
A better pattern is to keep your own compact thread state.
Store:
channel`` thread_ts
Use Slack history as recovery, not as your primary memory system.
Here’s the tradeoff:
| Approach | What actually happens |
|---|---|
| Rebuild thread from Slack every turn | Easy to start, but slower, noisier, and more fragile under load |
| Maintain your own thread state | Slightly more engineering, much more reliable for long-running agents |
If you’re running workflows in n8n, Make, Zapier, OpenClaw, or your own worker stack, this matters even more.
Those tools make it easy to ship a bot quickly.
They also make it easy to hide state bugs until traffic spikes.
If I were rebuilding this from scratch, I’d do it like this.
Handle DMs and mentions separately.
def route_event(event: dict):
event_type = event.get("type")
channel_type = event.get("channel_type")
if event_type == "message" and channel_type == "im":
return "dm"
if event_type == "app_mention":
return "channel_mention"
return "ignore"
Different paths should have different logic for:
Anything slow goes to background work.
That includes:
Your webhook should be boring.
Boring is good.
Slack retries are not edge cases.
Store event_id and make processing idempotent.
Pseudo-code:
def process_event(event_id: str, event: dict):
if already_processed(event_id):
return
mark_processing(event_id)
try:
handle_event(event)
mark_processed(event_id)
except Exception:
mark_failed(event_id)
raise
If you skip this, duplicate replies are just a matter of time.
One queue per channel is a sane default.
from collections import defaultdict
from queue import Queue
import time
channel_queues = defaultdict(Queue)
def post_with_throttle(channel_id: str, message: dict):
q = channel_queues[channel_id]
q.put(message)
while not q.empty():
next_msg = q.get()
slack_client.chat_postMessage(**next_msg)
time.sleep(1.0)
In real code you’d use a proper worker, lock, or async queue, but the design point stands:
throttle per channel, not globally
If you want progress updates, update one message instead of posting five new ones.
That usually looks cleaner for users and is friendlier to rate limits.
Slack is a transport layer.
It should not be your source of truth.
Minimal thread record example:
{
"channel": "C123ABC456",
"thread_ts": "1712345678.123456",
"participants": ["U111", "U222"],
"messages": [
{"role": "user", "text": "check prod errors"},
{"role": "assistant", "text": "Looking into GitHub and Datadog"}
],
"summary": "Investigating production error spike after deploy",
"last_updated": "2026-10-10T12:00:00Z"
}
That gives you a stable context source for long-running agents.
The labels differ, but the architecture lesson is the same.
Slack has:
chat.postMessage
Discord has:
Different APIs, same rule:
respond fast, queue slow work, dedupe retries, and control outbound writes
If you do long-running agent work inline, both platforms will punish you.
When a bot works in DMs but not in channels, this is the checklist I’d run in order.
Log the event shape.
import json
def debug_event(payload):
print(json.dumps(payload, indent=2))
Check whether you’re actually receiving app_mention and not assuming all traffic is message.
Make sure the app is actually in the channel and has the scopes it needs.
Log how long your webhook takes before returning 200.
import time
start = time.time()
elapsed = time.time() - start
print(f"ack path took {elapsed:.3f}s")
If that number is drifting upward, you’re moving work back into the request path.
Log event_id and retry headers.
If duplicate replies exist, you probably don’t have idempotency under control.
Make sure replies use the correct thread_ts.
If the bot is chatty in one channel, assume rate limits are part of the problem until proven otherwise.
This bug looked like a model problem because model calls were the most visible slow step.
That’s common in agent systems.
People blame GPT-5, Claude, Grok, or tool-calling reliability when the real issue is orchestration:
That’s also why predictable AI infrastructure matters.
When you’re building bots, automations, or long-running agents, you want the freedom to offload the slow work without obsessing over every token or every retry path.
That’s the appeal of Standard Compute: you can keep your app OpenAI-compatible, swap in a flat-rate endpoint, and let agents run in the background without per-token cost anxiety creeping into every architecture decision.
Especially if you’re wiring together Slack, GitHub, Jira, Notion, n8n, Make, Zapier, or custom workers, the expensive part is usually not one single prompt. It’s the whole loop.
Our bot never needed a better personality.
It needed better manners.
The real fix was not prompt engineering.
It was:
message.im and If your chatbot stops replying in groups while behaving perfectly in DMs, start with the boring plumbing.
That’s the stuff that actually fixes production bots.