10 AI-задач за один день: автоматизация которая работает без вас

3 июня 2026 года я закончил 2-часовую презентацию в 21:00. В зале было около 50 человек. К 23:00 в личке Telegram — 11 сообщений от незнакомых людей: «Хочу внедрить AI в свой бизнес». Ни один не пришёл после рассылки — рассылок я не делал. Они написали, потому что во время выступления система в фоне закрыла 10 реальных задач, и это было видно без слайдов.

Не метафора. Пока я стоял у экрана и объяснял архитектуру, 14 агентов на сервере параллельно: восстановили шаблон блога после регрессии SEO-агентов, обнаружили и изолировали 2 скомпрометированных Telegram-аккаунта, перегнали Excel с 88 бронированиями в новую управляющую компанию Vsemdom, закрыли доступ 5 неактивным инвесторам в дашборде, обновили Threads-токен без участия человека. Дневной отчёт пришёл в 21:30 — я читал его в машине уже после Q&A, пока люди из зала всё ещё переписывались в чате мероприятия.

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

Почему живая система убеждает лучше кейса

В большинстве презентаций про AI-автоматизацию показывают слайды: схемы процессов, диаграммы экономии, кейсы клиентов с округлёнными цифрами. Я сам так делал первые 8 выступлений в 2025 году. Средняя конверсия с такой встречи — около 5-8% в заявку. Люди слушают, кивают, уходят думать и не возвращаются. Проблема в том что автоматизация на слайдах выглядит как обещание. А обещаниям верят меньше чем фактам.

3 июня сработало иначе. Примерно на 40-й минуте выступления я открыл ноутбук и показал живой дашборд: агент финансов отчитывался по MRR клуба каждый час, SEO-агент только что опубликовал статью и запустил Cloudflare purge, watchdog по Telegram-аккаунтам показал флаг «anomaly detected». Я зашёл разобраться прямо на сцене. Оказалось — один из аккаунтов начал сам отправлять команды чужому боту. Изолировал его публично: аудитория видела весь процесс — обнаружение, диагностику, изоляцию — за 4 минуты реального времени.

Это был реальный инцидент, случившийся во время презентации. Не подготовленный, не срежиссированный. Именно это убеждает лучше любого кейса: не «у нас было», а «вот — происходит прямо сейчас, и система на это реагирует без меня». Q&A растянулось на час сверх плана, после поехали обедать вместе, а вечером — 11 входящих без единой рассылки.

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

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

Задача 1: Sentinel для блога — защита шаблона от регрессий

День начался в 7:30 с неприятного открытия. Листинг блога на 4bos.ru показывал страницы без шапки и футера. Статьи существовали, контент был на месте, но выглядело как сырой HTML: без стилей, без навигации, без Telegram-виджета. Пользователь пришедший из Яндекса видел белую страницу с текстом и ни одной кнопки «назад».

Причина: SEO-агент при публикации статьи вызывает rebuild_blog_index.py для пересборки листинга и sitemap. В предыдущей версии скрипт не проверял целостность шаблона — тихо записывал index.html с упрощённой структурой без проверки результата. Один из агентов-публикаторов использовал копию старого шаблона без основных блоков, скрипт принял это как корректный результат и применил к листингу. Регрессия ушла в прод без единого предупреждения.

Фикс занял около часа. Суть исправления: sentinel в rebuild_blog_index.py, который проверяет наличие 4 обязательных маркеров в сгенерированном HTML до записи на диск:

• class="header" — шапка сайта с навигацией
• class="footer" — футер с контактами
• /assets/css/style.css — основной stylesheet
• class="tg-float" — плавающий Telegram-виджет

Если хотя бы один маркер отсутствует — скрипт падает с ненулевым exit code и подробным сообщением об ошибке. Индекс не пересобирается. Агент получает сигнал что что-то пошло не так и задача требует диагностики.

Принцип называется fail-loud: явный сбой лучше тихой ошибки. В multi-agent системах это принципиально важно: агент не видит экрана, он видит только exit codes, логи и HTTP-статусы. Если скрипт завершается с кодом 0 при ошибке — агент считает что всё в порядке и продолжает работу с некорректными данными. Когда скрипт кричит — агент останавливается и ошибка становится видимой немедленно, а не через несколько часов мониторинга.

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

После фикса правило добавлено в конституцию компании (файл constitution.md): шаблоны блога трогать напрямую запрещено, публикация статей только через agent_publish.py. Конституция автоматически распространяется по всем 14 AGENTS.md каждые 15 минут через cron. Через 15 минут правило знали все агенты.

Задачи 2-3: Два скомпрометированных Telegram-аккаунта

В 9:24 watchdog по аккаунтам поднял аномалию: один из наших Telegram-аккаунтов-продавцов отправлял команды чужому боту. Не из нашего кода, не из нашей инфраструктуры — просто исходящие /start команды к ботам которых мы не используем.

Механика атаки типичная для маркетов аккаунтов. При продаже продавец сохраняет копию session-файла. Через 10-14 дней — достаточно чтобы покупатель перестал активно мониторить активность — аккаунт подключают к drone-сети для рассылок, регистраций и команд ботам. Владелец обычно не замечает: аккаунт отвечает нормально, его переписки идут штатно. Только в логах исходящих видны запросы к посторонним ботам. Схема стандартная на всех рынках купли-продажи аккаунтов и известна с 2022 года.

У нас оказалось 2 таких аккаунта. Признаки которые позволили их найти:

• 105 строк в таблице inbox_spam_filter с нашими sender_id и незнакомыми адресатами
• Исходящие /start команды к 7 ботам из чужой инфраструктуры — в логах видны за последние 3 дня
• 11 топиков в рабочих группах с мусорным контентом: спам-шаблоны, ссылки на сторонние ресурсы

Порядок действий: оба аккаунта немедленно отключены, session-файлы удалены с сервера. Очищено 105 строк спам-таблицы. Удалено 11 мусорных топиков. Поставлен watchdog с правилом: если аккаунт отправляет более 3 исходящих сообщений за 60 минут без нашего кода в стеке вызовов — автоматически в карантин плюс алерт в Solar AI группу.

Watchdog работает через cron каждые 15 минут. Я обнаружил аномалию раньше — во время ручной проверки инфраструктуры перед выступлением. Но автоматический мониторинг нужен не чтобы заменить ручную проверку, а чтобы ловить аномалии в промежутках между ними. Без watchdog этот инцидент мог бы жить несколько недель незамеченным.

Практическое правило: Telegram-аккаунты для продакшн-систем — только свежесозданные с чистого номера, верифицированного вами лично. Стоимость нового номера — около 200 рублей. Стоимость инцидента: несколько часов ручной очистки, потенциальный бан аккаунта за спам, репутационный риск если ваш отправитель окажется в spam-report у партнёров. Соотношение делает экономию бессмысленной.

Задачи 4-7: Хандовер 88 бронирований в управляющую компанию

С 1 июня 2026 года 16 вилл на Бали переданы управляющей компании Vsemdom. Solar Property теперь работает как agency-слой: генерирует входящие лиды, получает комиссию за бронирования, не занимается операционкой — заселением, уборкой, обслуживанием. Передача операционки потребовала передачи данных о будущих бронированиях.

Vsemdom использует PMS Exely. У Exely есть API, но write-доступ для внешних интеграций закрыт: читать данные через API можно, загружать нельзя. Единственный способ импортировать данные — Excel-файл через административный интерфейс.

Задача: выгрузить 88 будущих бронирований из нашей базы solar_property в формат совместимый с импортом Exely. Структура файла: гость (имя, email, телефон), даты заезда и выезда, объект (вилла), канал бронирования (Booking.com, Airbnb, прямое бронирование), итоговая сумма, статус оплаты.

Из 88 бронирований 75 вышли чистыми: все поля заполнены, даты непересекающиеся на одном объекте, каналы нормализованы под справочник Exely. Оставшиеся 13 имели проблемы: пустые поля email у 4 гостей, задвоенные даты на 2 виллах при смежных бронированиях, нестандартные каналы («WhatsApp», «Referral») которых нет в системных справочниках Exely. Эти 13 выгрузили отдельным файлом с комментариями для ручного ввода на стороне Vsemdom.

Параллельно в нашем eZee выставили Stop Sell по всем виллам до 31 декабря 2026 года. Без Stop Sell OTA (Booking.com, Airbnb, Agoda) продолжали бы отображать объекты как доступные и принимать новые бронирования в нашу систему. Эти бронирования мы больше не обрабатываем — клиент ждёт подтверждения и не получает. Stop Sell решает это на уровне channel manager: объекты пропадают из выдачи и новые заявки не поступают.

Отдельно: закрыт доступ 5 инвесторам в дашборде 4bos.online/investor/. Все 5 не заходили более 90 дней, инвестиционные контракты закрыты. Открытые активные учётки для неактивных пользователей — избыточная поверхность атаки без операционной необходимости. Закрыть аккаунт занимает 2 минуты, открыть заново по запросу — 2 минуты. Держать открытым без причины — нет смысла с точки зрения безопасности.

Задачи 8-10: Автоматизация токенов и завершение villa-пивота

Threads API требует long-lived токен с TTL 60 дней. До 3 июня процесс обновления был полностью ручным: за несколько дней до истечения приходило напоминание, я вручную логинился в консоль, генерировал новый токен, находил и обновлял его в 14 конфигурационных файлах по всему репозиторию. Каждый раз около 25 минут ручной работы. Каждый раз с риском пропустить один файл и получить молчаливую ошибку публикатора через несколько дней.

Решение: cron-скрипт обновления каждые 20 дней — с запасом до истечения 60-дневного TTL. Скрипт делает refresh через Threads API, получает новый long-lived токен, обновляет все 14 конфигурационных файлов через sed с проверкой что замена прошла в каждом файле, записывает timestamp в лог, отправляет алерт в Solar AI если refresh завершился ошибкой. Запускается 1-го и 21-го числа каждого месяца по cron. Первый запуск 3 июня прошёл успешно: токен обновлён в 14 файлах, старый деактивирован.

Четвёртый проход по отключению villa-систем за неделю с момента пивота. Несмотря на три предыдущих прохода к 3 июня в инфраструктуре оставались активные villa-задачи: 4 cron'а на хосте (daily_reports по villa-доходам, alice_scheduler для villa-бронирований, pipeline villa-отзывов через Apify, rebuild villa-рейтингов), 3 шедулер-задачи в Paperclip, 1 outreach worker для villa-ниши. Найдены и отключены. Суммарно за неделю: 25 отключённых задач и правил, 2 остановленных systemd-сервиса.

Это типичная картина при крупных пивотах. Систем много, задокументировано не всё в одном месте. После первого прохода находятся ещё несколько задач. После второго — ещё. Нужно рассчитывать на 3-4 итерации прежде чем инвентаризация полная. Стратегия: каждую неделю делать grep по ключевым словам старой темы в cron, шедулерах, конфигах. Тихих простоев не было потому что отключали поэтапно с проверкой в логах.

Архитектура: почему 14 агентов не мешают друг другу

Самый частый вопрос после выступлений: «Как вы управляете 14 агентами одновременно — они же постоянно должны конфликтовать?».

Ответ: явные роли и явные зоны ответственности, прописанные в AGENTS.md каждого агента. Каждый агент имеет свою зону и не выходит за её границы. Финанс-агент не пишет контент. SEO-агент не трогает финансовые таблицы. Telegram-агент не делает SEO. Это не техническое ограничение через permissions — это контрактное: в AGENTS.md прописано что агент делает, кому докладывает и что ему запрещено явно. Зоны ответственности не пересекаются.

Иерархия для роутинга: CEO-агент принимает входящие задачи, распределяет по профилям, эскалирует к основателю только то что требует человека — суммы выше 100 000 рублей, удаление баз данных, деплой нового сервиса в прод. Всё остальное решается autonomous без участия человека.

Heartbeat-мониторинг: каждый агент периодически подтверждает работоспособность. Service health watchdog проверяет все сервисы каждые 5 минут и пишет алерт в Solar AI если что-то молчит или падает с ошибкой. Anomaly watchdog проверяет поведение агентов каждые 10 минут. Без этого мониторинга агенты тихо ломаются и узнаёшь об этом через неделю когда уже накопились проблемы.

Конституция: все правила и ограничения живут в одном файле constitution.md на сервере. Скрипт constitution_distribute.py прокидывает актуальную версию во все 14 AGENTS.md каждые 15 минут через cron. Новое правило в конституции — через 15 минут знают все агенты без ручного обновления каждого файла. Это снимает 80% операционной нагрузки по синхронизации.

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

С чего начать: практический путь без теории

Практический путь из реального опыта — не теория из книги:

Шаг 1. Одна рутина которая раздражает больше всего. Не «автоматизировать весь бизнес», а одно конкретное действие: отвечать на FAQ в директе, собирать заявки с сайта, отправлять ежедневный отчёт по продажам. 1 неделя на реализацию, 1 неделя на калибровку. Потом следующая рутина. Solar Property строил стек с апреля 2025 года — к июню 2026 получилось 14 агентов с 10+ heartbeat-задачами каждый.

Шаг 2. Telegram как первый операционный слой. Для малого и среднего бизнеса Telegram — самая практичная точка входа: боты, группы, топики. Здесь живёт большинство коммуникаций. Паттерн: listener на входящие, classifier по типу запроса, handoff в нужный канал обработки. Этот паттерн покрывает 80% задач первого уровня и реализуется за 1-2 недели без сложной инфраструктуры.

Шаг 3. Явные роли, явные зоны. AGENTS.md — это не просто системный промпт, это контракт агента с компанией. Что он делает, что ему запрещено, кому докладывает при нештатной ситуации. Чёткие зоны — главная причина почему 14 агентов не мешают друг другу. Без этого агенты начинают перекрывать зоны ответственности: два агента пишут в одну таблицу, один переписывает конфиг другого.

Шаг 4. Heartbeat и мониторинг с первого дня. Каждый агент должен периодически подтверждать что работает. Service health watchdog — первое что нужно настроить после первого агента. Без мониторинга агенты тихо ломаются и узнаёшь об этом когда уже накопились проблемы которые нужно разгребать часами.

Шаг 5. Sentinel-паттерн на критичных операциях. Fail-loud везде где агент может незаметно навредить: запись в базу данных, отправка сообщений пользователям, изменение конфигов. Явная ошибка с понятным сообщением лучше тихого неправильного результата который обнаружишь через неделю после того как он уже нанёс ущерб.

Полный набор артефактов: шаблоны AGENTS.md для разных типов агентов, промпты для classifier и handoff, скрипты watchdog и мониторинга, примеры sentinel-кода — всё это из реальной системы Solar Property в клубе «Solar — внутрянка».

Метрики: как измерить работу автоматизации

Частая ошибка при построении multi-agent системы — отсутствие метрик. Агенты работают, что-то делают, но насколько хорошо — непонятно. Без метрик нельзя улучшать. Можно наблюдать активность и принимать её за эффективность — это ловушка.

Для стека из 14 агентов Solar Property использует 3 уровня метрик:

Операционные (ежечасно): сколько задач выполнено, сколько провалилось с ошибкой, сколько ожидает обработки. Агент финансов видит эти цифры в дашборде и включает в ежечасный отчёт. Аномалии — резкий рост ошибок или падение throughput — триггер для watchdog.

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

Качественные (ежемесячно): по каким задачам агенты делают ошибки чаще всего, где нужна человеческая проверка, что можно перевести в fully autonomous. Это основа для итерации по AGENTS.md — каждый месяц стек становится немного умнее.

День 3 июня дал конкретную качественную метрику: 11 лидов после выступления. Это гипотеза которую теперь можно проверить на следующих 3-5 выступлениях и сравнить с конверсией слайдовых презентаций без живой демонстрации. Данные накапливаются автоматически в логах системы.

«Автоматизация работает не потому что она умная. Она работает потому что каждый агент знает ровно одно дело и защищён от соседей которые могут его сломать.»

— Юрий Солар, основатель Solar Property, 3 июня 2026

У меня это всё крутится 24/7. Кому интересно как устроено внутри — клуб «Solar — внутрянка», от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/

— Solar OS.