Telegram Bot-to-Bot API: что это означает для архитектуры AI-агентов — UnifyPort

7 мая 2026 года Telegram выпустил функцию, которой большинство мессенджеров не касались: прямая нативная коммуникация между автономными ботами. Без общего бэкенда. Без сервера-ретранслятора. Один бот адресует сообщение другому через @username — и оно доставлено. Для разработчиков, строящих системы AI-агентов, это стоит внимания.

Что именно изменилось

До этого обновления, чтобы два бота координировали действия в Telegram, нужно было маршрутизировать все через внешний сервис. Бот A отправляет результат на ваш бэкенд, бэкенд решает, что делать дальше, и даёт инструкции боту B. Сами боты были изолированы — они могли получать сообщения только от пользователей или вызываться вашей собственной инфраструктурой.

Новая система работает иначе. Теперь бот может отправить личное сообщение другому боту напрямую, указав его @username. Действуют два условия: и отправитель, и получатель должны явно включить этот режим. Ни один бот не может быть принудительно добавлен в граф агентов без своего согласия.

Это ограничение двустороннего opt-in намеренно. Оно защищает ботов от спама и от принудительного включения в графы агентов, для которых они не предназначены, а также позволяет разработчикам чётко разграничить, какие боты входят в координационный слой, а какие работают напрямую с пользователями.

Почему это важно для мультиагентных систем

Мультиагентные AI-системы, где специализированные модели обрабатывают разные задачи и передают работу друг другу, стали значительно популярнее за последний год. Координационный слой — обычно самая сложная часть: нужен надёжный, низколатентный канал для передачи контекста, делегирования подзадач и получения результатов.

Сейчас большинство команд решают это с помощью очереди сообщений, общей базы данных или кастомного HTTP-сервиса. Эти решения работают, но добавляют инфраструктуру, вносят точки отказа и полностью существуют вне мессенджера, где происходит взаимодействие с пользователем.

Поддержка Bot-to-Bot в Telegram превращает саму платформу в часть координационной инфраструктуры. Вместо отдельного ретранслятора можно строить систему агентов напрямую вокруг гарантий доставки Telegram, механизма повторных попыток и существующей модели аутентификации.

Два паттерна, которые из этого возникают

Паттерн оркестратор-воркер. Один бот выступает центральным координатором. Он получает запрос пользователя, разбивает его на подзадачи и распределяет каждую подзадачу специализированному боту-воркеру через личное сообщение. Боты-воркеры обрабатывают свои части и отчитываются оркестратору, который собирает итоговый ответ и возвращает его пользователю.

Пользователь → Оркестратор
                   ↓              ↓
             Воркер-бот A    Воркер-бот B
                   ↓              ↓
             Оркестратор (агрегирует)
                   ↓
              Пользователь

Этот паттерн подходит для параллелизуемых задач: исследование + резюмирование, перевод + форматирование, получение данных + анализ.

Паттерн конвейера. Боты выстраиваются в последовательную цепочку. Бот A обрабатывает первый шаг, затем напрямую передаёт результат боту B, который обрабатывает следующий шаг, и так далее. Пользователь взаимодействует только с первым ботом в цепочке; промежуточные результаты перемещаются исключительно внутри бот-слоя.

Этот паттерн подходит для задач, где каждый шаг преобразует результат предыдущего: сбор → валидация → обогащение → доставка.

Что нужно учесть перед разработкой

Двусторонний opt-in обязателен. Нельзя добавить существующего бота в граф агентов без его модификации — бот-получатель должен включить режим приёма сообщений от ботов. Если вы используете сторонних ботов наряду с собственными, уточните, поддерживают ли они этот режим.

Формат сообщений ограничен. Сообщения bot-to-bot используют тот же API, что и пользовательские сообщения, а значит, на них распространяются те же ограничения по размеру payload и типам медиа. Отправить произвольные структурированные данные нативным сообщением не получится. Если агентам нужно передавать большие JSON-payload, используйте отдельный канал для данных, а сообщения ботов — только для сигналов задач.

Функция ограничена экосистемой Telegram. Если один агент должен реагировать на событие Telegram, а другой — отправлять уведомление в WhatsApp на основе результата, кросс-платформенная координация по-прежнему должна происходить за пределами платформы.

Когда агенты работают в нескольких каналах

Для команд, запускающих агентные системы сразу на нескольких мессенджерах — Telegram для одной аудитории, WhatsApp для другой, LINE или Zalo для третьей — проблема координации выходит за рамки возможностей Bot API отдельной платформы.

Унифицированный Webhook-слой означает, что агенты получают нормализованные события вне зависимости от исходного канала и могут маршрутизировать ответы через нужный канал, не заставляя каждого агента понимать несколько Provider API. Именно эту проблему решает UnifyPort: единая API-поверхность, стандартные форматы событий для каждого канала, который нужен вашим агентам.

Bot-to-Bot в Telegram — важный шаг к тому, чтобы воспринимать мессенджинговую инфраструктуру как первоклассный координационный примитив. Паттерн, который она открывает — агенты общаются через тот же канал, которым обслуживают пользователей — чище, чем отдельный ретранслятор. Для систем, где Telegram является основным каналом, эту функцию стоит учитывать в архитектуре агентов. Для систем, которым нужно большее покрытие, тот же принцип применим на уровне мультиканального слоя.