Исторически в Telegram действовало жёсткое правило: боты не должны «видеть» сообщения других ботов. Даже если бот был администратором чата или у него был выключен Privacy Mode, он всё равно не получал сообщения, отправленные другим ботом — именно чтобы не допустить бесконечных циклов «бот ответил боту, бот ответил боту…».
Теперь подход стал более гибким: в официальной документации появился отдельный раздел Bot‑to‑Bot Communication, который прямо говорит, что в целом боты по‑прежнему «обычно» не видят сообщения других ботов, но в определённых контекстах это разрешено — и это открывает «сложные агентные цепочки» и AI‑сценарии.
Русскоязычная техпресса уже отреагировала на изменение, описав его как снятие прежнего ограничения и указав два ключевых канала взаимодействия: внутри чатов (упоминания/реплаи) и через Business Mode.
Что именно разрешили по официальной документации
Документация описывает три составные части новой возможности.
Первое — включаемый режим. Чтобы «полноценно» использовать общение ботов, Telegram рекомендует включить Bot‑to‑Bot Communication Mode в BotFather (это условие вынесено отдельным примечанием).
Второе — общение в групповых чатах. Телеграм описывает два «явных» способа, как один бот может адресно взаимодействовать с другим в рамках одной группы: через команду с упоминанием второго бота (/command@OtherBot) и через ответ (reply) на сообщение другого бота.
Третье — общение через бизнес‑аккаунты. Если бот подключён к бизнес‑аккаунту в режиме доступа к чатам (Chat Access Mode), он может отправлять сообщения другим ботам, «используемым» этим бизнес‑аккаунтом — но для отправляющего бота требуется включённый Bot‑to‑Bot Communication Mode.
Как это работает в групповых чатах: условия доставки и «радиус видимости»
В групповом сценарии важно различать два уровня доступа.
Адресное взаимодействие (точка‑в‑точку)
Если один бот обращается к другому через /command@OtherBot или через reply на сообщение этого бота, то получающий бот должен получить это сообщение как событие (update) и иметь возможность ответить. В документации указано, что для этого достаточно, чтобы Bot‑to‑Bot Communication Mode был включён хотя бы у одного из участвующих ботов.
Расширенное получение сообщений других ботов (без упоминаний и реплаев)
Отдельно Telegram описывает «более широкий» режим: боты с включённым Bot‑to‑Bot Communication Mode будут получать все сообщения других ботов в группе даже без явного адресования, если выполняется одно из условий:
- у бота есть права администратора в группе;
- либо отключён Group Privacy Mode (то есть бот и так работает в более «наблюдательном» режиме).
Это фактически меняет старую модель, где «сообщения ботов для ботов» были полностью закрыты на платформенном уровне, независимо от настроек приватности. Тогда Telegram прямо объяснял это риском бесконечных циклов.
Как это работает через бизнес‑режим: что меняется для Business‑ботов
Telegram отдельно развивает направление «Bots for Business»: бот может включить Business Mode, чтобы подписчики Telegram Business подключали его к своему аккаунту для автоматизации личных чатов. При этом владелец аккаунта выбирает, какие чаты доступны боту, а бот получает обновления (updates) по этим чатам и при определённых настройках может отправлять сообщения от имени владельца в активных чатах (в документации упоминается окно активности «за последние 24 часа»).
На этом фоне добавляется важная деталь: коммуникация “бот → другой бот” теперь возможна и в бизнес‑контуре. Документация формулирует это так: если бот подключён к бизнес‑аккаунту с Chat Access Mode, он может отправлять сообщения другим ботам, которые используются этим бизнес‑аккаунтом — и для этого должен быть включён Bot‑to‑Bot Communication Mode у отправляющего бота.
Практический смысл: бизнес‑бот становится «оркестратором», который может дергать специализированных «инструментальных» ботов (например, бронирование, справочник, AI‑ассистент, CRM‑интегратор) прямо из личных диалогов — в рамках прав и настроек бизнес‑подключения.
Что это открывает разработчикам, админам и рынку ботов
В официальном примере Telegram описывает «человеко‑машинный» рабочий процесс: бот‑контрибьютор просит ревью у бота‑ревьюера в групповом чате и обрабатывает фидбек, при необходимости оставляя человеку контроль/надзор.
Если переложить это на реальные сценарии для каталогов и админов сообществ, появляется несколько классов решений, которые раньше упирались в платформенное «боты не видят ботов»:
- Цепочки ботов в одном чате: один бот собирает ввод и маршрутизирует задачу другому (например, модерация → анализ текста → логирование → итоговый ответ). Основание для такого паттерна — разрешённый обмен через
/command@OtherBotи reply‑взаимодействия. - Единый “логгер/аудитор” для команд: раз Bot‑to‑Bot Communication Mode может дать доступ к сообщениям других ботов без упоминаний при админ‑правах или отключённой групповой приватности, появляется концепция «наблюдающего бота», который фиксирует действия автоматизации в чате (для техподдержки и разборов инцидентов).
- Agentic‑сценарии и AI‑оркестрация: Telegram прямо позиционирует Bot‑to‑Bot Communication как шаг к «agentic flows» и AI‑кейсам (то есть цепочкам, где несколько автоматизированных исполнителей делят задачу).
- Бизнес‑оркестрация: бизнес‑бот, действующий от имени аккаунта, получает возможность писать другим «внутренним» ботам, что делает возможным более сложные workflow без внешних интеграционных “костылей”.
Для сайта‑каталога это означает появление новой «фичи‑метки» для карточек: поддерживает Bot‑to‑Bot Communication Mode. Это не маркетинговая мелочь: в будущем она будет напрямую влиять на то, можно ли встроить бота в мультиботную цепочку или использовать его как “инструмент” для другого бота.
Риски, ограничения и рекомендации по безопасной реализации
Telegram отдельно предупреждает, что общение ботов между собой «легко» приводит к бесконечным циклам, поэтому при включении возможности разработчик обязан реализовать предохранители, чтобы взаимодействия гарантированно завершались.
В документации приведены рекомендуемые меры:
- дедупликация повторяющихся сообщений;
- лимиты на частоту ответов (например, не чаще одного ответа раз в несколько секунд на пару отправитель/получатель);
- ограничение глубины взаимодействия или таймауты (глобально и на уровне конкретной пары ботов).
Также есть жёсткое предупреждение: ваш бот должен оставаться стабильным даже если другой бот намеренно отвечает мгновенно и непрерывно; если этого не обеспечить, возможны деградация работы и «platform restrictions» (ограничения со стороны платформы).
С практической точки зрения (уже как инженерная рекомендация поверх документации) имеет смысл проектировать bot‑to‑bot взаимодействия как «протокол», а не как свободную переписку:
- фиксировать в тексте или метаданных сообщения корреляционный идентификатор (request_id), чтобы вычищать дубли;
- внедрять TTL/лимит шагов (“depth”), чтобы цепочка не могла уйти в бесконечность;
- использовать allowlist ботов, от которых вы принимаете команды (особенно если бот получает все сообщения других ботов в группе благодаря админ‑правам или отключению групповой приватности). Это снижает риск того, что сторонний бот в чате начнёт провоцировать ваш бот на нежелательные действия.
Наконец, важно понимать: Telegram не говорит, что «все боты теперь видят всех ботов всегда». Формулировка документации подчёркивает, что по умолчанию боты «обычно не видят» сообщения других ботов, а разрешение включается только в описанных контекстах и с дополнительными требованиями по предотвращению циклов.
