Telegram Bot API 10.0 Guest Mode: What It Means for Group Admins

On May 8, 2026, Telegram shipped Bot API 10.0 — the biggest architectural shift to how bots work since the Business platform launched. The headline feature is Guest Mode: bots can now receive and reply to messages in chats they're not members of. Alongside it: built-in member tagging, bot-to-bot communication, reaction-level moderation, streaming text, and a handful of poll and media additions.

I run Varta — an AI moderation bot across 48 Telegram communities — and I wanted to understand the API changes carefully before commenting publicly. I read the official changelog and the Telegram blog announcement end-to-end. This post is what an admin needs to know — what shipped, what each change actually does, and where the architectural shift points.

What Bot API 10.0 shipped

The official changelog dates the release at May 8, 2026. The Telegram blog post was published May 7. Telegram positioned the release as "AI Bot Revolution: 11 New Features" — most are user-facing, some are admin- or developer-facing. From an admin perspective, six of them matter:

The other five (custom AI styles, expanded emoji/sticker search, poll statistics, custom poll limits, silent scheduled messages) are user-facing or marginal for moderation. I'll focus on what affects how communities are managed.

Guest Mode explained: bots summoned, not added

Before Bot API 10.0, a bot could only operate in a chat where it was a member. To use any bot's capability, an admin had to add the bot, manage its permissions, and trust it with full chat visibility (read history, see members, etc.). That was the only model.

Guest Mode changes the model. A bot can now expose itself via a new boolean — supports_guest_queries on its User object — and any user in any chat can @mention that bot. The bot receives a structured payload (new guest_message update field) containing the tagged message, the user who tagged it, and the chat context. The bot replies via the new answerGuestQuery method, producing a SentGuestMessage.

The privacy guarantee is specific: the guest bot sees only the tagged message and its own reply. It does not see other group members, message history, group admins, or any other content. Telegram's framing: "Guest bots operate with privacy protection — cannot see which users are in the chat."

Concretely, this is what it enables in a community:

• A member types @SomeAIBot summarize this thread. The bot reads only that message (and the thread it replies to), produces a summary, posts it. Never joins the group. Never sees other members.
• An admin asks @VartaBot is @userX safe to admit?. Varta returns a trust verdict based on cross-group reputation — without becoming a member of the admin's group.
• A user fact-checks a forwarded claim: @FactCheckBot is this true?. Bot replies to the user; group history is preserved without bot-as-member overhead.

Telegram's framing positions Guest Mode as the surface where "all AI models can compete freely." Practically: it's the first time Telegram has shipped infrastructure for queryable bot services as opposed to installed bots.

Member tagging: built-in trust labels

Member tagging arrived earlier (Bot API 9.5, March 1, 2026) but ties into the 10.0 architecture cleanly. The mechanic:

• Method: setChatMemberTag — assigns a custom string tag to a chat member.
• Message field: sender_tag — the tag displays next to the member's messages.
• Permissions: can_manage_tags (administrator right) — who can assign tags. can_edit_tag (member right) — whether the member can edit their own.

Where this matters for admins: tags become a built-in primitive for trust labeling. Concrete uses:

• "verified" tag for members who passed a manual vetting process — paid subscribers, KYC'd users, long-time contributors.
• "contributor" / "mod" / "VIP" tag for community structure that previously had to be cobbled together via nicknames, custom titles, or external trackers.
• Programmatic tag assignment via bot: a moderation bot can set a "verified" tag after a member passes its checks. The tag is then visible system-wide, not just in the bot's interface.

This is the technical primitive underneath what I called the community-level Trust Layer: a per-community statement about who belongs and under what rules. Member tags don't build a trust layer on their own — they're a label, not a decision system. But they're the first time Telegram has shipped the labeling primitive itself.

Bot-to-bot communication: agent workflows arrive

The third architectural change: bots can now send messages to other bots via username, and business bots can reply to other bots — provided both sides have enabled communication. Telegram's framing: "Creates fully autonomous agents."

What this unlocks practically:

• Querying chains. A moderation bot can query a trust bot for an account reputation signal. A mini-app gating bot can query an anti-spam bot for an authenticity check. A workflow bot can chain a translation bot, a summarization bot, and an action bot.
• Specialized agents. No single bot needs to do everything. A community can compose: one bot for moderation, one for analytics, one for verification — each focused, each callable.
• Trust APIs become possible. A bot exposing a "is this account safe?" endpoint queryable by other bots is now a Telegram-supported architecture, not a workaround. That's the architectural enabler for the kind of cross-bot trust queries I've been planning.

The catch: both bots have to opt in. Telegram doesn't open bot-to-bot communication automatically — each bot's owner has to enable it. That's a sensible default; it prevents bots from accidentally spamming each other and prevents abuse vectors.

Reaction moderation, polls, live photos

Three smaller updates worth noting:

Reaction moderation. Two new methods: deleteAllMessageReactions removes all reactions from a message; deleteMessageReaction removes a specific reaction type. Plus a can_react_to_messages permission on ChatMemberRestricted and ChatPermissions. Use: raid cleanup (mass-thumbs-down hostile-reaction removal), and surgical reaction removal for individual cases.

Polls expanded. Polls can now include media (images, video) on the body and on each option (InputMediaSticker, InputPollMedia). Two new admin restrictions: members_only (poll visible only to members), country_codes (poll restricted to specific countries). Minimum option count dropped from 2 to 1.

Live Photos. A new media type — photo plus a short video component. New classes LivePhoto, InputMediaLivePhoto; method sendLivePhoto. Lower-priority for moderation but relevant for content-heavy creator communities.

Adjacent change: getChatAdministrators gained a return_bots parameter — admins can now query which bots are administrators in a chat. Useful for audit + visibility.

What this means for the moderation category

The biggest architectural takeaway is in three changes together: Guest Mode + bot-to-bot communication + member tagging. They jointly enable a model that didn't exist on Telegram before:

Bots become queryable services, not just chat members. A moderation tool no longer has to be added to every group it serves. It can be summoned via @mention for one-off questions, queried by other bots for trust signals, and used to assign verifiable member tags — all without joining the chat as a permanent member.

That's the architecture I'd been hoping for. It's what the Trust Layer for Telegram piece described as the "app-level" of the trust stack — bots and mini-apps querying trust signals from a community-level reputation service. Before API 10.0, that workflow required custom wiring outside the bot API. Now it's an officially supported architecture.

For the moderation category specifically, three implications:

1. "Bot per group" stops being the only model. A trust-query bot can serve a network of communities without being a member of any of them. The economics change — the bot infrastructure cost scales with queries, not with installs.
2. Composability becomes real. Admin teams can pick best-in-class tools at each layer (moderation, analytics, welcome flow, trust queries) and have them work together via bot-to-bot communication. The "Telegram admin stack" becomes a category.
3. Trust labels become portable. When a moderation bot assigns a "verified" tag via setChatMemberTag, that tag is visible system-wide — readable by any other bot via standard message handling. Trust signals stop being trapped inside each bot's private database.

What changes for admins running existing bots

Practically: nothing breaks. Bot API 10.0 is additive — every existing bot integration continues working as before. You don't have to migrate anything. The new methods are opt-in.

What you might want to consider:

• Audit your bot administrators. Use the new return_bots parameter to list all bots with admin rights. Most groups have accumulated bot installs over years — some are stale, some have permissions that exceed what they need.
• Plan for member tagging. If you have an existing community structure (VIPs, mods, contributors, paid subscribers), think about whether you want to migrate that structure to Telegram-native tags rather than third-party trackers. Tags will become a more universal primitive over the next 12 months.
• Wait on Guest Mode adoption. Guest Mode is genuinely new. The patterns for how groups will use it haven't settled yet. Watch how it's used in 1-2 communities you trust before adding guest-mode-capable bots to your own.
• Don't rush to bot-to-bot integrations. The composability is real but early. Most admin teams will benefit from sticking with their current single-bot setup for 60 days while the ecosystem learns the new patterns.

For Varta specifically: I'm exploring exposing a Trust Query endpoint that mini-apps and other bots can call. If you build a Telegram mini-app and the question "is this user trustworthy?" sits in your workflow, email me — I'm picking 3-5 design partners for the beta.

Frequently asked questions

Do I need to migrate my existing moderation bot?

No. Bot API 10.0 is additive — existing bot integrations continue working unchanged. The new methods (Guest Mode, member tagging, reaction deletion) are opt-in. You only adopt them if the bot's use case benefits. For most admin teams, the right move is wait — see how Guest Mode and bot-to-bot communication settle into the ecosystem over the next 60 days before changing your own setup.

Can spam bots abuse Guest Mode to flood new chats?

Less than you might expect. Guest Mode requires the user to @-mention the bot — it's pull, not push. A guest bot can't post unsolicited; it can only respond to a tagged query. The user initiating the query is the one giving the bot a one-message window. Privacy is preserved on the chat side too — the guest bot only sees the tagged message + its own reply, not group membership, history, or other messages.

Is Guest Mode enabled by default for my group?

It's enabled per-bot via BotFather, not per-group. A bot opts into supporting guest queries via its setup; the user_id has a supports_guest_queries boolean. Group admins don't toggle this globally — any user can @-mention a guest-mode-capable bot in any chat where their permissions allow @-mentioning. If you want to restrict it, that's a chat-permission setting, not a bot-API setting.

What's the difference between Guest Mode and a Telegram mini-app?

Guest Mode = bot replies to a single tagged message in a chat (chat-context, one-shot, no membership). Mini-app = full interactive web app launched from a button, with its own UI and session (app-context, persistent state, no chat unless you build one). Guest Mode is for "quick answer in the chat I'm already in." Mini-app is for "launch an experience." Both can coexist on the same bot.

What's the most strategic implication for the moderation category?

Moderation shifts from "bot owns the chat" to "bot is queried by chat." Bot-to-bot communication + Guest Mode + member tagging together mean a community-trust bot (like Varta) can be queried by mini-apps, by other admin bots, by users asking "is this account safe?", and by automated agent workflows — without that bot having to be a member of every surface where the question is asked. Trust becomes a queryable service. We covered the strategic frame in detail in the Trust Layer for Telegram manifesto.

Varta is the community trust layer for Telegram. AI reads every message in 33 languages, ban signals share automatically across 48 protected communities, and the bot never posts in your group. Free to add — the 5-day AI trial starts only when Varta catches your first spam. Add Varta in shadow mode →