Historically, Telegram had a strict rule: bots should not «see» messages from other bots. Even if a bot was an admin of a chat or had Privacy Mode disabled, it still would not receive messages sent by another bot — precisely to prevent endless loops of «bot replied to bot, bot replied to bot…».
Now the approach has become more flexible: a separate section Bot‑to‑Bot Communication has appeared in the official documentation, which directly states that bots in general still «usually» do not see messages from other bots, but in certain contexts this is allowed — and this opens up «complex agentic chains» and AI‑scenarios.
Russian-language tech press has already reacted to the change, describing it as the removal of the previous restriction and pointing out two key channels of interaction: inside chats (mentions/replies) and through Business Mode.
What exactly was allowed according to the official documentation
The documentation describes three components of the new capability.
The first is an enabled mode. To «fully» use bot communication, Telegram recommends enabling Bot‑to‑Bot Communication Mode in BotFather (this condition is placed in a separate note).
The second is communication in group chats. Telegram describes two «explicit» ways one bot can address another within a single group: via a command mentioning the second bot (/command@OtherBot) and via a reply to a message from another bot.
The third is communication through business accounts. If a bot is connected to a business account in Chat Access Mode, it can send messages to other bots «used» by this business account — but the sending bot requires Bot‑to‑Bot Communication Mode to be enabled.
How it works in group chats: delivery conditions and «visibility radius»
In the group scenario, it is important to distinguish between two levels of access.
Addressed interaction (point-to-point)
If one bot addresses another via /command@OtherBot or via a reply to that bot’s message, then the receiving bot must receive this message as an event (update) and have the ability to respond. The documentation states that for this it is sufficient for Bot‑to‑Bot Communication Mode to be enabled for at least one of the participating bots.
Extended receipt of messages from other bots (without mentions and replies)
Separately, Telegram describes a «broader» mode: bots with Bot‑to‑Bot Communication Mode enabled will receive all messages from other bots in the group even without explicit addressing, if one of the following conditions is met:
- the bot has admin rights in the group;
- or Group Privacy Mode is disabled (i.e., the bot already operates in a more «observant» mode).
This effectively changes the old model, where «bot-to-bot messages» were completely closed at the platform level, regardless of privacy settings. Back then, Telegram explicitly explained this by the risk of endless loops.
How it works through Business Mode: what changes for Business bots
Telegram is separately developing the «Bots for Business» direction: a bot can enable Business Mode so that Telegram Business subscribers can connect it to their account for automating personal chats. At the same time, the account owner chooses which chats are available to the bot, and the bot receives updates for these chats and, under certain settings, can send messages on behalf of the owner in active chats (the documentation mentions an activity window «for the last 24 hours»).
Against this background, an important detail is added: communication “bot → another bot” is now also possible in the business context. The documentation formulates it as follows: if a bot is connected to a business account with Chat Access Mode, it can send messages to other bots used by this business account — and for this, Bot‑to‑Bot Communication Mode must be enabled on the sending bot.
Practical meaning: the business bot becomes an «orchestrator» that can call specialized «tool» bots (for example, booking, reference, AI assistant, CRM integrator) directly from personal dialogs — within the rights and settings of the business connection.
What this opens for developers, admins, and the bot market
In the official example, Telegram describes a «human-machine» workflow: a contributor bot asks a reviewer bot for a review in a group chat and processes feedback, leaving control/supervision to a human when necessary.
If we translate this into real scenarios for directories and community admins, several classes of solutions appear that previously ran into the platform-level «bots don’t see bots»:
- Bot chains in one chat: one bot collects input and routes the task to another (for example, moderation → text analysis → logging → final response). The basis for such a pattern is the allowed exchange via
/command@OtherBotand reply interactions. - Single “logger/auditor” for commands: since Bot‑to‑Bot Communication Mode can provide access to messages from other bots without mentions when admin rights are present or group privacy is disabled, the concept of an «observing bot» emerges that records automation actions in the chat (for tech support and incident analysis).
- Agentic scenarios and AI orchestration: Telegram directly positions Bot‑to‑Bot Communication as a step toward «agentic flows» and AI cases (i.e., chains where multiple automated executors divide the task).
- Business orchestration: a business bot acting on behalf of an account gains the ability to message other «internal» bots, enabling more complex workflows without external integration “crutches”.
For a directory site, this means the appearance of a new «feature label» for cards: supports Bot‑to‑Bot Communication Mode. This is not a minor marketing detail: in the future it will directly affect whether a bot can be embedded in a multi-bot chain or used as a “tool” for another bot.
Risks, limitations, and recommendations for safe implementation
Telegram separately warns that bot-to-bot communication «easily» leads to endless loops, so when enabling the feature, the developer must implement safeguards to ensure interactions terminate reliably.
The documentation provides recommended measures:
- deduplication of repeated messages;
- limits on response frequency (for example, no more than one response every few seconds per sender/receiver pair);
- limiting interaction depth or timeouts (globally and at the level of a specific bot pair).
There is also a strict warning: your bot must remain stable even if another bot intentionally responds instantly and continuously; if this is not ensured, performance degradation and «platform restrictions» (restrictions from the platform) are possible.
From a practical standpoint (as an engineering recommendation on top of the documentation), it makes sense to design bot‑to‑bot interactions as a «protocol» rather than free-form correspondence:
- include a correlation identifier (request_id) in the message text or metadata to eliminate duplicates;
- implement TTL/step limits (“depth”) so the chain cannot run to infinity;
- use an allowlist of bots from which you accept commands (especially if the bot receives all messages from other bots in the group due to admin rights or disabled group privacy). This reduces the risk that a third-party bot in the chat will provoke your bot into undesirable actions.
Finally, it is important to understand: Telegram is not saying that «all bots now see all bots at all times». The documentation’s wording emphasizes that by default bots «usually do not see» messages from other bots, and permission is granted only in the described contexts and with additional requirements to prevent loops.
