Как обучить AI-агентов работать вместе: структура команды из 18 ботов

В 5 утра Тригуна, мой балийский менеджер, проснулся от уведомления. Один из ботов отправил в рабочий чат отчёт про незавершённый чек-аут на вилле. Через два часа другой написал «Напоминание #6». В три ночи третий рапортовал что переезд отеля прошёл успешно и прислал лог из 14 строк. Балийские сотрудники спят с 21 до 06. Никто это не читал в реальном времени, но звуки в телефоне их будили. Тригуна написал мне утром одно слово: «почему».

Это произошло потому что у меня работала команда из 13 разных скриптов и ботов. Каждый из них думал, что у него одна работа: отправить сообщение, когда произошло событие. Никто из них не думал о том, что произошло это событие в 3 ночи. Каждый бот был по-своему прав. Вместе они были катастрофой. Утром я открыл код и увидел: 13 точек, через которые боты пишут в рабочий чат. Только одна знала про ночь. Остальные 12 работали круглосуточно и считали это нормой.

К полудню я сделал один общий модуль — окно тишины с 21 до 09, ночные сообщения копятся в очередь и пачкой выходят утром. Ничего не теряется, сотрудники высыпаются. Тригуна перестал просыпаться от ботов. Одно правило в одном месте решило проблему для всех 13 источников сразу.

Это один из десятков уроков, которые я получил за полтора года, строя систему управления бизнесом из AI-агентов. Сейчас их 18. Они управляют 16 виллами на Бали, обрабатывают входящие лиды, формируют финансовые отчёты для 9 инвесторов, публикуют контент в 5 соцсетях, отвечают клиентам. Я один человек. Без офиса. Без наёмного штата операционных сотрудников.

Это статья о том, как создать команду AI-агентов, которая реально работает — а не просто запускается и тут же начинает мешать самой себе.

Почему один AI-агент — это ещё не система

Большинство людей начинают с одного чат-бота или одного автоматизированного сценария. Это правильно. Один агент — понятная единица: он делает одно дело, его легко проверить, его легко починить если сломался. Проблемы начинаются когда таких агентов становится больше двух-трёх и они начинают пересекаться по данным, по каналам, по клиентам.

Типичная ситуация: агент отвечает на лид в Telegram, агент записывает лид в базу данных, агент отправляет уведомление менеджеру. Три агента, один лид. Если они не скоординированы, менеджер получит уведомление до того, как лид записан в базу. Или агент ответит клиенту «уточним детали у менеджера», а менеджер в это время уже отправил клиенту другое сообщение. Два разных текста с интервалом в одну минуту от имени одной компании — это не автоматизация, это имиджевая проблема.

У меня такое случилось с WhatsApp. Я вёл переговоры с хозяйкой одной из вилл про условия аренды. Одновременно мой WhatsApp-бот-переводчик, которого я обучил для перевода с балийского на английский, отвечал ей от моего же номера: «я ассистент Юрия, он сам ответит про контракт». Один номер, два голоса, противоречивые сообщения. Контрагент видел: один и тот же человек пишет два разных текста с интервалом в минуты. AI в переговорах о деньгах и контрактах без явного согласования — это шизофрения в реальном времени. Я выключил AI-ответы в WhatsApp немедленно. Функция перевода осталась, автоответ ушёл навсегда.

Из таких инцидентов я сформулировал главный принцип построения мультиагентной системы: команда AI-агентов — это не набор автономных ботов, запущенных параллельно. Это единый организм с жёсткими правилами взаимодействия, общим мозгом и чёткими границами зон ответственности. Без этих правил агенты не помогают бизнесу — они создают новый тип хаоса, который труднее обнаружить, чем обычный человеческий.

Конституция как общий мозг: как агенты разделяют правила поведения

Самое важное архитектурное решение при строительстве системы — создать единый документ, который получают все 18 агентов при старте каждой сессии. Я называю его конституцией. Это не список инструкций в стиле «делай это, не делай то». Это живой договор о поведении системы: как принимать решения в нестандартных ситуациях, кому эскалировать когда непонятно, что делать молча, что требует явного подтверждения человека.

Конституция отвечает на вопросы, которые агенты встречают каждый день в реальной работе:

• Агент обнаружил что-то подозрительное в данных — писать ли в общий чат или молча логировать в файл?
• Клиент задаёт вопрос про цену аренды — агент отвечает сам или переключает на менеджера?
• Нужно сделать что-то, что стоит больше 100 долларов — агент делает сам или ждёт подтверждения?
• Один агент уже начал выполнять задачу — второй агент должен подождать или может работать параллельно?
• Задача требует написать в рабочий чат с балийскими сотрудниками — на каком языке?

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

Конституция делит все действия на пять классов автономии. AUTO-1: агент делает сам, один объект, без уведомлений. AUTO-N: делает сам, но начинает с одного объекта как dry-run и только потом масштабирует. NEED-NOTIFY: делает сам, но за 10 секунд до действия отправляет уведомление мне — я могу успеть отменить. NEED-APPROVAL: создаёт задачу для меня и ждёт явного одобрения. HARD-STOP: это только я, агент не предлагает и не делает никогда.

Конкретно: публикация поста в Instagram — NEED-NOTIFY, я вижу что уходит и могу остановить. Изменение цены виллы на 30% и более — NEED-APPROVAL, агент создаёт задачу для меня и замирает. Финансовые переводы, удаление таблиц базы данных — HARD-STOP, это не автоматизируется никогда. Это не про недоверие к агентам — это про управляемость системы в масштабе.

Главная ценность конституции — не в том что она запрещает плохие действия. В том что она даёт агентам язык для принятия решений. Агент знает как называть то что он собирается сделать. И это называние само по себе защита от необдуманных действий.

Системный кризис: 16 агентов работают вполсилы 24 часа

Один из самых поучительных инцидентов случился когда я в 00:30 ночи руками скопировал снимок учётных данных и положил в базу агентов. Я спешил, не проверил свежесть данных. Учётные данные к тому моменту уже устарели на несколько часов. Я не думал о последствиях — просто скопировал то что было под рукой и пошёл спать.

Через сутки открыл утренний отчёт и увидел странное: 16 агентов за 24 часа закрыли 5 задач. Норма — 30 и более. Технический агент накопил 33 задачи в очереди и просто их не разбирал. Сервер за сутки перезапустился 11 раз. Казалось — глюк планировщика. Полез глубже — все провалившиеся прогоны выдавали одну и ту же ошибку: доступ просрочен. Я положил устаревший снимок. Сам создал инцидент своими руками в 00:30.

Починил так, чтобы никогда больше не делать это вручную. Написал автоматическую задачу: каждые 4 часа сверяет живой доступ из бота с копией у агентов. Если расходится — копирует сам. После рестарта первое успешное действие агента случилось через 2 минуты. Технический агент начал разбирать свои 33 накопившихся задачи.

Самое неприятное: я узнал о проблеме не от системы, а от клиента. Клиентский бот поддержки молчал в ответ на её вопросы — по той же причине: та же инфраструктура, тот же протухший доступ. Утренний инцидент с 16 агентами и вечерний инцидент с молчанием бота — одна первопричина, проявившаяся в двух местах с интервалом 12 часов. Если бы был хороший мониторинг — я бы узнал утром. Вместо этого узнал от клиента вечером.

После этого в конституцию добавлено жёсткое правило: ручная операция с токенами и учётными данными — это всегда риск класса NEED-APPROVAL. Не потому что агент должен меня спросить, а потому что я сам должен остановиться и подумать прежде чем делать что-то с credentials в 00:30.

Правило второй поправки: как система обучает сама себя

В системе есть принцип, который я называю правилом второй поправки. Звучит так: если одна и та же категория ошибки повторилась второй раз — это баг конституции, не баг конкретной задачи. Агент обязан предложить новое правило в конституцию, а не просто исправить ошибку и двигаться дальше.

Это правило изменило то, как работает обучение в системе. Раньше каждая ошибка была разовой. Агент делал что-то не так, я исправлял, он делал снова через неделю по другому поводу — и я снова исправлял. Два раза подряд одно и то же — это паттерн. Паттерн должен стать правилом.

Конкретный пример из реальной работы. Агент написал в отчёт фразу «Клиентка попросила убрать дублирующее видео». Клиентка написала мне: «в каком сообщении я просила убрать?» Я поднял всё — экспорты чатов, базу сообщений, заметки. Прямого сообщения не нашёл. Агент додумал на основе контекста и написал как факт. Первая поправка: агент исправил конкретный отчёт. Вторая поправка: в конституцию добавлено правило — если агент приписывает кому-то решение или просьбу, обязана быть прямая ссылка на конкретное сообщение. Если прямого сообщения нет — «по результатам обсуждения» без присвоения авторства.

Теперь это правило работает для всех 18 агентов во всех отчётах. Ошибка не повторится — не потому что агент «запомнил», а потому что правило в общем документе, который все читают при старте.

За полтора года конституция обновлялась больше тридцати раз. Большинство обновлений — именно по этому механизму: снизу вверх, от инцидента к правилу. Живая система обучается на своих ошибках и не повторяет их — не потому что агенты умные, а потому что правила общие и обновляются.

Разделение зон ответственности и принцип dry-run

Самая частая проблема в многоагентных системах — конфликт ресурсов. Два агента пишут в одну таблицу одновременно. Два агента отвечают одному клиенту с разными сообщениями. Один агент начал задачу, второй видит что задача «не закрыта» и тоже начинает. Результат — дублированные действия, противоречивые данные, недоумевающий клиент.

Я решал эту проблему через несколько принципов, встроенных в конституцию.

Первый — жёсткие зоны ответственности. У каждого из 18 агентов есть своя зона и инструменты только для неё. Агент по продажам физически не имеет доступа к операционным чатам с сотрудниками. Агент по виллам не может инициировать маркетинговые задачи. Финансовый агент не пишет клиентам. Нарушение зоны — это архитектурная граница, которая встроена в дизайн, а не просто написано в инструкции.

Второй — молчание по умолчанию. Агент пишет в чат только три вещи: результат когда задача закрыта, блокер когда не может двигаться без решения человека, развилку когда есть выбор который должен сделать человек. Промежуточные статусы и «я начал работу» — не пишутся никогда. Это убрало примерно 80% шума из рабочих каналов. Когда в чат приходит сообщение — это значит что-то важное произошло или нужно решение.

Третий — dry-run перед масштабом. Всё что делается на N>1 объекте начинается с N=1. Агент хочет разослать обновление цен по всем 16 виллам — сначала делает одну виллу, показывает результат, ждёт подтверждения. Только после — остальные 15. Этот принцип без исключений несколько раз спасал от массовых ошибок.

Тихие поломки: главный риск масштабированной автоматизации

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

У меня в Threads два поста застряли. Содержательные посты по 800 знаков — платформа держит 600. Мой автомат помечал их «опубликовано» и записывал ошибку в лог. Пост в базе данных числится как опубликованный, но в живой ленте его никто никогда не видел. Тихая смерть. Я обнаружил через несколько дней — только потому что сам зашёл проверить вручную.

Решение: если пост «опубликован», но не виден в публичном API платформы через 10 минут — это алерт, не молчаливый успех. Проверка корректности результата, а не только факта попытки — это и есть зрелая автоматизация. Каждое критически важное действие должно иметь verification step, который проверяет не «я попытался отправить», а «это действительно дошло и выглядит правильно».

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

Метрики реальной системы и итоги полутора лет

Через полтора года работы с командой агентов у меня есть конкретные цифры. Восемь предпринимателей пользуются персональными AI-ассистентами, которые я развернул для их задач. С октября ни один из восьми не отключил ассистента. Все пришли через рекомендации между предпринимателями, которые видели результат у других. Интересный паттерн: четыре раза подряд клиент приходил с партнёром. Психолог — с женой, тренер — с партнёром по бизнесу, ателье — владелец и управляющая, отель — основатель и операционный директор. Когда бизнес общий, решение об автоматизации тоже общее.

По операциям с виллами: 16 активных объектов, 9 инвесторов с разными условиями дележа прибыли. Раньше финансовый отчёт — ручная Excel-таблица раз в квартал. Сейчас закрытый месяц автоматически пересчитывается к 1-му числу следующего, каждый инвестор видит свою часть в дашборде без звонков мне.

По контенту: 5 платформ, публикация каждый день, 0 минут моего времени на рутинную публикацию. По производительности агентов: в норме 30+ задач в сутки на всю команду. Падение ниже нормы — сигнал разобраться, не ждать когда клиент напишет.

Ещё один показатель который удивил

Я заметил что агенты закрывают задачи равномерно в течение дня — не только в рабочие часы. В 3 ночи агент по продажам отвечает потенциальному клиенту из другого часового пояса. В 6 утра финансовый агент уже обновил данные по бронированиям за вчера. В 22:00 контент-агент публикует запланированный пост. Это не «автоматизация» в обычном смысле — когда настроил скрипт и он делает одно действие по расписанию. Это команда, которая работает пока я сплю. Именно поэтому 16 вилл и 8 клиентов — это не «много для одного человека». Это нормальный масштаб для команды с правильной архитектурой.

Между «успеть» и «не успеть» больше не стоит вопрос «нанять ли человека». Стоит вопрос «как правильно сформулировать задачу агенту до утра».

Семь уроков прежде чем строить команду агентов

Я потратил много времени на ошибки, которых можно было избежать. Если вы собираетесь строить мультиагентную систему, вот что я посоветую на старте.

Первое — один агент, одна задача, две недели без инцидентов. Не пытайтесь сразу строить систему из многих агентов. Один агент решает одну задачу. Работает без присмотра две недели — это успех первого уровня.

Второе — конституция должна быть живым документом. Каждый инцидент — это кандидат на новое правило. У меня конституция обновлялась больше тридцати раз за год. Самые важные правила написаны по следам реальных инцидентов.

Третье — молчаливые поломки опаснее шумных. Сервис с ошибкой 500 заметить легко. Сервис, который работает но делает не то — это катастрофа в замедленном режиме. Инвестируйте в мониторинг корректности результата с первого дня.

Четвёртое — агент должен уметь объяснить каждое своё действие. Если агент не может объяснить почему он написал эту цифру или принял это решение — у него нет правила для этого действия. Значит оно произвольное. Произвольные действия накапливаются и через три месяца вы не понимаете почему система ведёт себя именно так.

Пятое — разделение зон важнее скорости. Лучше агент сделает задачу медленнее, но точно в своей зоне. Межзональные конфликты — самые неожиданные и трудновоспроизводимые баги в мультиагентных системах.

Шестое — dry-run всегда. Всё что делается на множестве объектов начинается с одного. Без исключений. Этот принцип несколько раз спасал от массовых ошибок с данными и ценами.

Седьмое — инциденты делают систему сильнее, если вы из них учитесь. Каждая тихая поломка, каждый конфликт агентов, каждое непредвиденное поведение — это информация. Используйте её чтобы обновить конституцию. Не используете — та же ошибка случится снова через месяц в другом месте.

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

Про то как именно ломаются автоматизированные системы — читайте в статье про тихие поломки автоматизации. Про то как масштабировать бизнес без найма — в отдельном материале.