Anthropic Shipped @Claude For Slack. My Team Runs On

Anthropic Shipped @claude for Slack. My Team Runs on Telegram.

Anthropic just shipped @Claude inside Slack channels. Tag the bot, it reads the thread, does work async, posts back. Nice product. Except roughly 95% of small businesses don't live in Slack — they run on WhatsApp, Telegram, and Gmail. If you're a solopreneur or a 1-to-10-person team, here's the exact four-part recipe I use to run the same pattern in Telegram for under $12/month.

What Anthropic actually shipped (and who it's for)

Anthropic shipped an enterprise distribution deal wearing a product launch t-shirt. @Claude for Slack lets you tag the bot in a channel or thread, gives it channel memory, connects to your other apps, and returns work asynchronously — but only on Slack Team and Enterprise plans. That's the punchline: it lives where the annual contracts live.

Look at the raw user counts. Slack's own reporting puts it around 35–40 million weekly active users globally. WhatsApp is over 2 billion. Telegram is over 900 million. Gmail sits around 1.8 billion. In the 1-to-10-employee segment outside US tech, Slack penetration is single digits. Small teams in Europe, LATAM, and most of Asia coordinate in WhatsApp groups and run pipeline out of Gmail. They are not about to add Slack seats at $15/user/month just to get an @Claude mention.

That's a rational call for Anthropic — Slack is where the enterprise procurement motion already exists. It's just not a product for the operator segment. And the pattern they productized is trivially replicable on any messenger with a bot API.

Platform	Weekly/monthly active users	Bot API	Cost to run a mention-bot
Slack	~35–40M WAU	Yes, paid plan	$15/user/mo + API
Telegram	~900M MAU	Yes, free	~$5–12/mo API only
WhatsApp Business	~2B MAU	Yes, metered	$0.005–0.08/conversation + API
Gmail	~1.8B MAU	Pub/Sub push	Free tier + API

The four-part recipe (works in any messenger)

Every mention-bot is the same four moving parts: a webhook that fires on mention, a context store that holds recent thread history, a model call that produces the reply, and a send back to the same thread. Total code for a working Telegram version: three files, ~200 lines, running on a $10 VPS or a home server.

Here's the shape, framework-free:

[messenger webhook]  →  [ingest handler]  →  [SQLite context store]
                                              ↓
                                        [Claude API call]
                                              ↓
                                    [messenger send endpoint]

That's it. No Zapier, no n8n, no vendor lock-in. Every piece is a documented public API.

The four parts, one line each

• Webhook: Telegram/WhatsApp/Gmail fires a POST when your bot is mentioned or a filter matches.
• Context: SQLite table keyed by thread_id, last 20 messages.
• Model: Claude API with a system prompt describing the bot's job + thread context as the user turn.
• Reply: Same messenger's sendMessage endpoint, back to the same thread.

Part 1 + 2: Webhook and SQLite context store

The first 80% of the work is capturing the trigger and storing context. Do this step alone this week — don't wire Claude yet. Prove you can catch every mention and log the thread. It costs zero dollars.

Register a Telegram bot with @BotFather, add it to a group, set a webhook URL pointing at your server, and enable group message access. The webhook payload arrives as JSON on every message.

# webhook.py — FastAPI ingest, ~40 lines
import sqlite3, os
from fastapi import FastAPI, Request

app = FastAPI()
DB = "bot.db"

def db():
    c = sqlite3.connect(DB)
    c.execute("""CREATE TABLE IF NOT EXISTS msgs(
        chat_id INTEGER, msg_id INTEGER, user TEXT,
        text TEXT, ts INTEGER, mentions_bot INTEGER)""")
    return c

BOT_USERNAME = os.environ["BOT_USERNAME"]  # e.g. "myops_bot"

@app.post("/tg")
async def tg(req: Request):
    u = await req.json()
    m = u.get("message") or {}
    text = m.get("text", "")
    if not text:
        return {"ok": True}
    chat_id = m["chat"]["id"]
    mentions = int(f"@{BOT_USERNAME}" in text)
    con = db()
    con.execute("INSERT INTO msgs VALUES (?,?,?,?,?,?)",
        (chat_id, m["message_id"], m["from"].get("username",""),
         text, m["date"], mentions))
    con.commit()
    if mentions:
        # enqueue for the Claude worker — covered in Part 3
        pass
    return {"ok": True}

Ship that, add the bot to one real group, and let it log for two days. You'll immediately see which threads matter and how much context 20 messages actually covers. On my ops group, 20 messages is roughly the last 45 minutes of conversation — usually enough for the bot to answer without asking clarifying questions.

For WhatsApp, swap the webhook for the Meta Cloud API endpoint and the same table works. For Gmail, use a Gmail push notification via Pub/Sub with a label filter — the "thread" is the email thread ID.

Part 3: The Claude API call, wired to thread context

When a mention fires, pull the last N messages from SQLite for that chat, wrap them as one user turn, and call the API. That's the entire agent. Memory is not magic — it's a SELECT ... ORDER BY ts DESC LIMIT 20.

# worker.py — the Claude call
import os, sqlite3, anthropic

client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

SYSTEM = """You are the ops assistant for a 4-person consulting team.
Answer briefly. If the group is discussing a client, pull the relevant
client facts from the thread. Never invent numbers. If unsure, ask."""

def build_context(chat_id: int) -> str:
    con = sqlite3.connect("bot.db")
    rows = con.execute(
        "SELECT user, text FROM msgs WHERE chat_id=? ORDER BY ts DESC LIMIT 20",
        (chat_id,)).fetchall()
    rows.reverse()
    return "\n".join(f"{u}: {t}" for u, t in rows)

def answer(chat_id: int) -> str:
    ctx = build_context(chat_id)
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=600,
        system=SYSTEM,
        messages=[{"role": "user", "content":
            f"Recent thread:\n{ctx}\n\nRespond to the latest @mention."}]
    )
    return msg.content[0].text

Real numbers from my server last month across three groups (roughly 40 mentions/day):

• Input tokens billed: ~2.1M
• Output tokens billed: ~180K
• Total Anthropic bill: $11.42
• VPS: home server, $0 marginal
• Slack seats saved for a 4-person team at $15/user/mo: $720/year

That's the whole economic argument. The Slack version isn't better — it's just packaged.

Part 4: Reply to the same thread + reliability tricks

Sending back to Telegram is one HTTP POST. The trick is quoting the original message so the reply lands in-thread and doesn't spam the channel, and rate-limiting so a chatty group doesn't burn your API budget on one bad afternoon.

import httpx, os

TG_TOKEN = os.environ["TG_TOKEN"]

def reply(chat_id: int, reply_to: int, text: str):
    httpx.post(
        f"https://api.telegram.org/bot{TG_TOKEN}/sendMessage",
        json={
            "chat_id": chat_id,
            "reply_to_message_id": reply_to,
            "text": text,
            "parse_mode": "Markdown",
        }, timeout=15)

Three cheap reliability moves that have saved me real money and real embarrassment:

• Debounce: if two mentions fire within 10 seconds in the same chat, collapse to one call. Group chats double-tap constantly.
• Daily cap: hard-stop each chat at 200 mentions/day. One runaway loop between two bots almost cost me $80 in a single evening before I added this.
• Fail-quiet: if the Claude call errors, log it, don't reply. Silent failure is better than "I'm sorry, I encountered an error" flooding the group.

For WhatsApp Business the send endpoint is a POST to graph.facebook.com/v20.0/{phone_id}/messages with a context.message_id for the reply target. For Gmail, users.messages.send with the original threadId keeps replies in-thread. Same four parts, different vendor.

Why the moat is the wiring, not the model

Every frontier lab is going to ship the polished version of this workflow for the platform where their enterprise buyers already pay. Anthropic picked Slack. OpenAI's team offering is heading the same direction. Neither of them is going to ship a first-class WhatsApp Business or Telegram bot because there's no procurement contract at the other end.

That leaves a specific opening for operators. The API is public. The messenger webhooks are public. The only thing that isn't handed to you is knowledge of your own workflow — which client threads matter, which questions repeat, which context the bot needs to be useful instead of annoying. That's not a technical moat. It's an operator moat, and it takes about a weekend to build the first version.

The one practical takeaway for this week: pick the messenger your team actually uses, register a bot, and set up the webhook + SQLite logger. Don't add Claude yet. Just prove you can capture every mention and the surrounding thread. Once that's stable, adding the API call is an afternoon.

Where bizflowai.io fits in

This is exactly the pattern we assemble for clients at bizflowai.io — mention-bots and inbox agents wired into the messenger the team already lives in (Telegram, WhatsApp Business, Gmail), backed by a small SQLite or Postgres context store, running on a $10 VPS or the client's own server with no per-seat fees. Same four parts as above, hardened with the debouncing, daily caps, and fail-quiet handling that keep the API bill boring. It's not a SaaS subscription and it's not a Slack replacement — it's the wiring most small teams don't have time to write themselves.

---

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.