Reply-In-Thread Is The New Agent UI. Slack Is Optional.

By Lazar Milicevic · Published July 29, 2026 · 7 min read

Anthropic shipped Claude into Slack last week, and every founder I've talked to since is staring at the wrong thing. The @mention isn't the news. The four-part interaction pattern under it is, and if your team lives on Telegram, WhatsApp, or a shared inbox, you can ship the same loop this week for roughly $8/month instead of $2,300/year.

What Anthropic actually shipped (it's not a Slack app)

Anthropic didn't ship a Slack feature. They ratified a UI grammar for AI agents with four parts: mention, thread context inheritance, tool use, async reply. That loop is the product. Slack is packaging.

Break it down:

• Mention. The agent is summoned inside a conversation the human is already having. No new tab, no dashboard, no "open the AI panel."
• Context inheritance. It reads the full thread automatically. No re-prompting. No copy-paste of the last 40 messages.
• Tool use. It hits org-connected tools — calendar, CRM, invoicing, docs, whatever's wired in via API or MCP.
• Async reply. It answers back in the same thread. Sometimes 12 seconds later. Sometimes 2 hours later. The human just sees the answer land where they were already looking.

That's the entire interaction model. Every serious agent shipped in the next 24 months will follow it, because it removes the two things that killed chatbot UX: the context-switch tax and the re-prompt tax. Once you see the pattern, the surface — Slack, Telegram, WhatsApp, Discord, email — becomes interchangeable.

The surface tax: $2,300/year for Slack vs $96/year on Telegram

The reply-in-thread pattern runs anywhere threads exist. Once you accept that, the pricing gap between surfaces becomes hard to ignore.

Here's the math for a 5-person team running one thread-native agent, using publicly listed pricing at time of writing (verify current pricing before you commit):

The Slack path buys you a polished admin console, SSO, audit logs, and the ability to sell into enterprise procurement. If you're a 300-person org with a security team, pay it. If you're a 5-person agency where everyone's already in a Telegram group with your top 20 clients, you're paying two grand a year for a surface no one is going to open.

The Claude API cost is the same on both paths. You're not saving on intelligence. You're skipping the seat tax.

The four-part loop, translated to Telegram

Here's the shape of a thread-native agent that runs the exact Anthropic loop on Telegram. Small agency use case: client message hits a Telegram group, operator wants a drafted reply grounded in the last invoice.

# Telegram thread-native agent — mention → context → tools → async reply
from telegram.ext import Application, MessageHandler, filters
import anthropic, os

client = anthropic.Anthropic()
BOT_HANDLE = "@ops_bot"

async def on_mention(update, context):
    msg = update.message
    if BOT_HANDLE not in (msg.text or ""):
        return

    # 1. INHERIT THREAD CONTEXT — last 200 messages in this chat
    history = await fetch_thread(context.bot, msg.chat_id, limit=200)

    # 2. TOOL USE — invoices, CRM, calendar wired as Claude tools
    tools = [
        {"name": "get_last_invoice", "description": "...", "input_schema": {...}},
        {"name": "get_client_record", "description": "...", "input_schema": {...}},
    ]

    # 3. RUN
    resp = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        tools=tools,
        messages=[{"role": "user", "content": build_prompt(history, msg.text)}],
    )
    draft = await run_tool_loop(resp, tools)

    # 4. ASYNC REPLY — back into the same thread, as a reply to the mention
    await msg.reply_text(f"Draft:\n\n{draft}\n\n👍 approve  ✏️ edit  ❌ discard")

app = Application.builder().token(os.environ["TG_TOKEN"]).build()
app.add_handler(MessageHandler(filters.TEXT & filters.Entity("mention"), on_mention))
app.run_polling()

That's ~40 lines of glue around the four-part pattern. Mention triggers the handler. Thread history gets pulled from the chat (Telegram's Bot API returns message history for the chat the bot is in). Tools are declared as Claude tool schemas and executed in a normal tool-use loop. The reply lands as a threaded reply to the original mention, 8–15 seconds later.

The same skeleton works on WhatsApp Business API, Discord, and a shared Gmail label. The handler shape changes. The four steps don't.

Where each surface pays off

• Telegram: fastest to ship, free API, best for teams and B2B where clients already chat there. Bot API is stable and well-documented.
• WhatsApp Business Cloud API: highest reach for consumer-facing SMBs in most markets, but per-conversation pricing and template-message rules add friction.
• Email (Gmail/IMAP): slowest surface, but "mention" becomes CC-the-bot, and thread context is native to email. Best for formal client comms.
• Slack: worth it if you're already sold into it and paying anyway.

The context-inheritance trap most builders hit

The part every DIY build gets wrong is step two — inheriting thread context. It sounds trivial ("just send the last 200 messages"), and it works fine in a demo. In production it breaks three ways.

One: token budget. 200 messages of a busy Telegram group is easily 15–25k tokens. Send that on every mention and your $8/month Claude bill becomes $80/month, most of it re-processing the same history. Fix: cache a rolling summary of the thread and only send raw messages since the last summary. A thread summary refreshed every 50 messages cuts input tokens by roughly 70% in the workloads I've measured.

Two: mention scope. A "thread" on Telegram or WhatsApp isn't as tidy as a Slack thread. If someone mentions the bot in a group with three parallel conversations, sending the raw last-200 confuses the model. Fix: use reply-to metadata (reply_to_message_id on Telegram) to walk backwards up the actual reply chain, then pad with recent group context as a lower-priority section.

Three: PII and scope leakage. Once the agent has thread + CRM + invoice access, a careless prompt ("summarize everything you know about this client") can dump data into a group chat that shouldn't have it. Fix: whitelist tools per chat_id. The bot in the internal ops group can read the CRM. The bot in the client group can only read invoices addressed to that client.

None of these are hard. All of them get skipped in tutorials, which is why so many DIY thread agents look impressive for a week and then get muted.

The human-in-the-loop stop that keeps this shippable

The single design choice that separates a thread-native agent that survives real clients from one that gets killed in week two: the agent drafts, the human approves. Every time. No autonomous send in client-facing threads.

The pattern that works:

1. Agent gets mentioned, runs tools, produces a draft.
2. Agent posts the draft in the same thread, but as a reply visible only to the operator, or clearly labeled DRAFT — approve to send.
3. Operator taps approve (inline keyboard button, emoji reaction, or a one-word reply).
4. Agent sends the finalized message as the operator, or writes it to the CRM, or books the calendar slot.

# Approval gate — inline keyboard on Telegram
from telegram import InlineKeyboardButton, InlineKeyboardMarkup

kb = InlineKeyboardMarkup([[
    InlineKeyboardButton("✅ Send", callback_data=f"send:{draft_id}"),
    InlineKeyboardButton("✏️ Edit", callback_data=f"edit:{draft_id}"),
    InlineKeyboardButton("❌ Kill",  callback_data=f"kill:{draft_id}"),
]])
await msg.reply_text(f"Draft ready:\n\n{draft}", reply_markup=kb)

Two things this buys you. First, one tap is faster than writing the message yourself, which is the actual reason operators keep the bot around. Second, the approval log becomes your evaluation dataset — every "edit" tells you exactly where the agent's draft was wrong, and you feed that back into the prompt or the tool schemas.

Anthropic's own Slack demo shows async replies landing minutes or hours later. That's fine for internal research. For anything that goes to a paying client, the async gap is where the approval tap lives.

Why bizflowai.io helps with this

At bizflowai.io most of what we deploy for small teams is exactly this shape: a thread-native agent on the messaging surface the team already opens 40 times a day, wired to two or three tools they already use — usually a CRM, an invoicing system, and a calendar — with an approval gate before anything client-facing goes out. We don't try to move teams onto a new surface. We instrument the one they're already on and give it the four-part loop. That's the delivery pattern for lead triage bots, invoice-question responders, and meeting-prep agents we ship weekly.

What to actually build this week

Pick one messaging surface your team already lives in. Pick one job — lead triage, invoice questions, meeting prep, quote follow-up. Wire the four-part loop. Ship it behind an approval gate. Measure how often the operator taps approve without editing; that's your accuracy signal.

Everyone else spends the next 90 days copying the @Claude-in-Slack demo and trying to sell it as an agent template. That's the distraction. The real signal is that reply-in-thread just became the default agent interface for the next five years. The pattern is free. The surface tax is optional.

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.