AI-агент вместо операционного менеджера: как делегировать управление боту

С июня 2026 года у меня нет операционного менеджера. Компания Solar OS работает через 14 автономных AI-агентов, которые принимают задачи, маршрутизируют их между собой, контролируют выполнение и эскалируют исключения. Каждые 10 минут anomaly_watchdog.py сканирует действия всех агентов. В 07:30 WITA формируется ежедневный дайджест: что сделано, что застряло, что ждёт моего решения. Этот дайджест заменяет утреннее совещание с операционным менеджером.

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

Что делает операционный менеджер — и что из этого берут агенты

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

Приём задач. У меня единственный канал Юрий ↔ компания — личный ассистент @spb_claude_bot (tier 0.5, chief of staff). Он принимает голосовые и текстовые сообщения, классифицирует их и передаёт Альтрону — CEO-агенту Solar OS. Альтрон анализирует задачу, определяет класс (AUTO-1, AUTO-N или NEED-APPROVE) и маршрутизирует нужному менеджеру tier 2. Я не пишу агентам напрямую — только через ассистента.

Распределение задач. В системе 3 класса задач. AUTO-1 — агент исполняет и не уведомляет: рутинные heartbeat-задачи вроде мониторинга позиций в Яндекс.Вебмастере или публикации запланированного поста. AUTO-N — исполняет, потом уведомляет: публикация новой SEO-статьи, обновление KPI-отчёта, деплой готового шаблона. NEED-APPROVE — задача блокируется до явного решения Юрия: финансовые операции от 1.5M IDR, деплой нового сервиса в прод, удаление таблиц в БД. Правила зашиты в конституцию (/opt/constitution.md), которую constitution_distribute.py инжектирует в каждый AGENTS.md каждые 15 минут.

Контроль дедлайнов. Задачи живут в Paperclip — внутренней системе управления задачами на сервере 213.139.229.247. Heartbeat-задачи — публикация SEO-статей по вторникам и четвергам, weekly KPI-отчёт по понедельникам, мониторинг позиций по понедельникам — создаются по cron-расписанию. Агент видит свою очередь pending-задач при каждом запуске и работает без дополнительного пинга. Статус задачи обновляется напрямую в PostgreSQL: UPDATE issues SET status=done после завершения.

Эскалация. service_health_watchdog.py — cron каждые 5 минут — мониторит состояние всех сервисов Solar-контура. При аномалии: немедленный алерт в Telegram-чат Solar AI и запись в лог. Правило действующее с мая 2026: при инциденте агент глушит только источник, не родственные сервисы. Это правило появилось после одного случая, когда превентивный kill унёс с собой 3 несвязанных процесса и потребовал 2 часа восстановления.

Отчётность. Еженедельный KPI по MRR клуба, P&L допов, аудит approval-gate — всё генерируется автоматически. Ежедневный дайджест в 07:30 WITA агрегирует действия агентов за прошедшие 24 часа. Я читаю его 3-5 минут вместо часового совещания с операционным менеджером.

Архитектура: 14 агентов, 3 уровня иерархии

В Solar OS иерархия Tier 1-3 плюс горизонтальный QA-агент. Tier 1 — один CEO-агент (Альтрон). Tier 2 — 5 менеджеров: CTO, Marketing, Product, Sales, Finance. Tier 3 — 8 исполняющих агентов: seo-4bos, Telegram, Instagram, Threads, X, VK, Broadcaster, QA.

Каждый агент знает свою зону ответственности, список heartbeat-задач с расписанием, границы полномочий, и handoff-протокол — куда передавать задачи и исключения которые выходят за его зону. Это задаётся в AGENTS.md — файле инструкций, который Paperclip инжектирует в контекст агента при каждом запуске.

Конституция (/opt/constitution.md) — надстройка над всеми AGENTS.md. В ней глобальные правила: Approval Gate, запреты cold outbound, правила финансовой дисциплины, anti-slop фильтры для публикаций. Раз в 15 минут constitution_distribute.py прогоняет её во все AGENTS.md — локальные изменения не обходят глобальные ограничения.

Почему именно 14? Это минимальная конфигурация для покрытия всех операционных функций текущей версии Solar OS: контент на 4 платформах (Telegram, Instagram, Threads, X), SEO, финансы, продукт, продажи, CTO, QA и CEO-координатор. В начале было 3 агента. До текущей конфигурации дошли за 8 месяцев, добавляя агентов по одному когда находилась конкретная повторяющаяся задача которую агент закроет надёжнее человека.

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

Routing: как задача проходит от владельца до исполнения

Маршрут стандартной задачи: Юрий → ассистент → Альтрон → менеджер tier 2 → IC-агент tier 3 → результат → дайджест Юрию на следующее утро.

Разберём конкретный пример — задача SOL-3135, это статья которую вы читаете прямо сейчас. Marketing создал issue в Paperclip с темами двух статей и требованиями. seo-4bos при запуске первым делом запрашивает pending-задачи из БД: SELECT identifier, title, description FROM issues WHERE assignee_agent_id='...' AND status='todo'. Читает description, загружает geo_seo_addon.md и пример payload, пишет статью с TL;DR и FAQ, прогоняет через QA-гейт seo_article, публикует через agent_publish.py. После успеха обновляет статус: UPDATE issues SET status='done', updated_at=NOW(). Юрий видит результат в завтрашнем дайджесте. Без единого дополнительного сообщения.

Второй пример — входящий запрос от потенциального клиента. Запрос приходит в @yuriy_solar DM или через форму на 4bos.ru. Sales-агент слушает входящий поток (spider_daemon). Если запрос про «хочу автоматизацию» без чёткого бюджета — Sales передаёт в Product с предложением предложить клуб как первый шаг. Если готовый бюджет 180k+ — Product инициирует КП через skill new-client-kp. Если это villa-вопрос — handoff в SOL company через ассистента Юрия. Весь этот routing работает без участия Юрия на уровне классификации.

Критически важный момент: ассистент принимает задачи от Юрия, но не апрувит NEED-APPROVE. Если задача требует явного апрува — она возвращается Юрию. Ассистент — расширение Юрия, не независимый участник иерархии. Субагенты не ставят задачи ассистенту — только получают через него.

Контур безопасности: что агент не делает без апрува

Делегирование операций AI требует чёткой системы ограничений. У меня 4 категории обязательного апрува.

Финансовый Approval Gate. Разовый расход от 1.5M IDR или 100 USDT — блок до явного апрува Юрия. Задача попадает в очередь agent_approvals с TTL 24 часа. Если апрув не пришёл за 24 часа — задача аннулируется. Это покрывает оплату сторонних сервисов, переводы инвесторам по вилла-контрактам, закупку ресурсов для клиентских проектов.

Деплой в прод. Любой новый сервис в продакшн — NEED-APPROVE. Даже если агент уверен что это безопасно. Защита от ситуации когда агент решил улучшить архитектуру без ведома владельца.

Удаление данных. DROP TABLE, массовое удаление записей — блок. Прямая запись в критические таблицы БД тоже заблокирована на уровне AGENTS.md: единственный разрешённый writer для каждой таблицы — строго определённый скрипт. Это правило появилось после инцидента в мае 2026 когда прямая запись в eZee-таблицу нарушила синхронизацию с channel manager.

Cold outbound. Год экспериментов с mass-рассылками дал 0 продаж. С 21 мая 2026 — HARD-STOP: агенты не могут инициировать массовые рассылки. Broadcaster-агент остаётся в системе, но только для healthcheck и standby под client deploys — не для рассылок Solar.

Kill-switch. В KV-store флаг system_freeze. Установить в true — все агенты дропают текущий run немедленно. На случай если что-то идёт совсем не так и нужно остановить всё.

Каждое из этих правил появилось потому что без него что-то пошло не так. Это не теоретические рекомендации из best practices — это выводы из реальных инцидентов на живой системе. Паттерн всегда одинаковый: инцидент → анализ причины → явный запрет или ограничение в конституцию → distribute во все AGENTS.md. Без этого цикла система накапливает долг безопасности.

Инструменты: что лежит под капотом

Paperclip. Система управления задачами и агентами. Хранит issues с assignee, status, description; историю действий агентов; конфигурацию. Предоставляет API для агентов. Работает на PostgreSQL (порт 5433) на сервере 213.139.229.247, 24/7.

Claude Sonnet 4.6. Модель для всех 14 агентов. Причины практические: предсказуемое следование сложным инструкциям (AGENTS.md с 15+ правилами), качественный русский текст для контент-агентов, надёжная работа с длинным контекстом — конституция плюс AGENTS.md плюс история задач это 10 000+ токенов входящего контекста на каждый run.

AGENTS.md. Операционный регламент каждого агента. Не просто описание роли — точный протокол: зона ответственности, список heartbeat-задач с cron-расписанием, что AUTO-класс, что NEED-APPROVE, протокол handoff для исключений. Агент с хорошо написанным AGENTS.md работает предсказуемо. Агент без чёткого AGENTS.md застревает на первом нестандартном случае и либо ждёт инструкции которой нет, либо делает что-то неожиданное.

Python на cron. Мониторинг (anomaly_watchdog.py раз в 10 минут, service_health_watchdog.py раз в 5 минут), дайджесты (daily_digest.py в 07:30 WITA), распределение конституции (constitution_distribute.py раз в 15 минут), публикация контента (agent_publish.py по вызову). Никаких сложных workflow-движков — обычные Python-скрипты под systemd или cron. Просто и надёжно.

PostgreSQL. Единое хранилище состояния системы. Задачи, KPI, финансовые данные, логи аномалий. Агенты работают напрямую через SQL — без ORM, без абстрактных слоёв. Прозрачно для отладки и мониторинга.

Telegram. Основной канал уведомлений. Алерты от watchdog, ежедневный дайджест, NEED-APPROVE запросы — всё в один чат. Юрий не смотрит в 5 разных интерфейсов — один бот, одно место где всё важное.

Что агенты реально делают каждый день — конкретные задачи

Абстрактная архитектура полезна для понимания принципов. Конкретные задачи — для понимания ценности. Вот что происходит в Solar OS за типичные сутки.

Marketing-агент (утро, вторник). Создаёт issue в Paperclip для seo-4bos с темой очередной SEO-статьи, требованиями по ключевым словам и ссылками на последние опубликованные статьи для исключения дублей. Параллельно проверяет Яндекс.Вебмастер на критичные ошибки — индексации, мобильной версии, Core Web Vitals. Если всё чисто — AUTO-N: уведомление Юрию в дайджест. Если критичная ошибка — NEED-APPROVE: задача эскалируется с описанием проблемы.

seo-4bos (утро, вторник). Видит pending-задачу от Marketing. Читает описание, загружает geo_seo_addon.md, пишет статью с TL;DR 40-75 слов и минимум 3 FAQ-вопросами. Прогоняет через anti-slop фильтр: проверка на AI-клише, scoring 5×10 (порог 35/50). Публикует через agent_publish.py — helper сам добавляет JSON-LD разметку Article, FAQPage, Author. После успеха: UPDATE issues SET status=done и CF-purge кеша Cloudflare. Ставит задачу на isitagentready.com проверку.

Telegram-агент (ежедневно). Проверяет очередь контента для @mr_solar_blog. Если в очереди есть утверждённый пост — публикует с Soft CTA на клуб. Если очередь пуста — создаёт NEED-NOTIFY: уведомление Юрию что контент закончился, нужно добавить материал. Никакой самодеятельности с генерацией контента без явного источника — только утверждённый материал.

Finance-агент (понедельник). Генерирует недельный отчёт по MRR клуба: новые подписки, отписки, нетто-изменение, retention за 30 дней. Данные берёт из PostgreSQL: таблицы solar_inside_subscriptions, payment_events. Кладёт отчёт в дайджест Юрию. Отдельно — аудит approval-gate за неделю: какие задачи были NEED-APPROVE, по каким пришёл апрув, по каким истёк TTL 24 часа.

anomaly_watchdog.py (каждые 10 минут). Не агент в полном смысле, но критический компонент. Сканирует последние действия всех агентов на аномалии: необычно высокое число API-вызовов, попытки записи в таблицы вне своей зоны, задачи у агентов которые должны быть в простое. Если что-то триггерит — алерт в Telegram и запись в anomaly_log. Тихий компонент о котором не думаешь пока всё хорошо.

Broadcaster-агент (ежедневно). С мая 2026 единственная задача — healthcheck аккаунтов парка для client deploys. Не публикует контент Solar, не делает рассылки. Просто проверяет что аккаунты живы и готовы к использованию клиентами в их проектах автоматизации. Пример агента у которого было 5 функций, 4 из них закрыли после пересмотра стратегии, осталась 1 — и это нормально.

Как внедрить первый AI-агент для операций: пошагово

Не надо строить систему из 14 агентов с первого дня. Минимальный рабочий прототип — 1 агент, 1 повторяющаяся задача, 1 метрика успеха. До текущей конфигурации Solar OS дошёл за 8 месяцев, начав с одного агента для контент-публикаций в Telegram.

Шаг 1. Найти одну повторяющуюся задачу. Что вы или ваш опер.менеджер делаете каждую неделю, что занимает 1-3 часа, имеет чёткие входные данные и предсказуемый результат? Хорошие кандидаты: weekly KPI-отчёт из данных в таблицах, публикация контента по расписанию, первичная квалификация входящих заявок по скрипту из 5 критериев, мониторинг позиций в поисковиках и алерт при падении.

Шаг 2. Написать AGENTS.md для этого агента. Файл должен содержать: роль и зону ответственности в 3-5 предложениях, список heartbeat-задач с расписанием (что делать каждую неделю, каждый день), что агент делает самостоятельно (AUTO-класс), что требует апрува (NEED-APPROVE), и handoff-протокол — куда передавать исключения. Без handoff-протокола агент застрянет на первом нестандартном случае и будет бесконечно ждать инструкции.

Шаг 3. Выбрать инструмент. Claude Code (CLI) — для контент-задач, аналитики, задач требующих рассуждения и работы с текстом. n8n или Make — для интеграций между сервисами, автоматических триггеров по событиям, пайплайнов данных. Zapier — для простых триггеров без кода. Выбор зависит от технического стека команды и сложности задачи, не от хайпа вокруг инструмента.

Шаг 4. Определить Approval Gate. До запуска: какие действия агента необратимы? Отправка сообщений клиентам, изменение данных в производственной БД, финансовые операции — всё это должно требовать апрув до перехода в полную автономию. Начните с узкого AUTO-класса (только читай и отчитывайся) и расширяйте по мере того как убеждаетесь в надёжности.

Шаг 5. Запустить в режиме shadow. 2 недели агент делает всё, но результат показывает вам до публикации и отправки. Вы проверяете, соглашаетесь или правите. Через 2 недели без грубых ошибок — переводите в AUTO-режим. Shadow-режим покажет какие граничные случаи не покрыты в AGENTS.md. Это не осторожность ради осторожности — это calibration, которая экономит время потом.

Типичное время от концепции до первого AUTO-запуска: 2-4 недели. Зависит от сложности задачи и того насколько точно написан AGENTS.md с первой попытки. Если AGENTS.md написан расплывчато — первые 2 недели уйдут не на shadow-режим, а на доработку протокола. Это нормально и предсказуемо: AGENTS.md хорошего качества требует 3-5 итераций.

Где AI-агент операционного менеджера не работает

Год экспериментов показал чёткие границы системы.

Cold outbound. Автоматические рассылки выглядят как масштабируемый инструмент продаж. Год экспериментов в Solar OS, закрытый 21 мая 2026, дал 0 продаж через cold outbound. Агент может отправить тысячу сообщений, но не может создать доверие. Входящий лид с прогретым контекстом — читатель @mr_solar_blog, подписчик 4bos.ru — конвертируется принципиально иначе, чем холодный контакт.

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

Задачи без чётких критериев успеха. Если владелец сам не может сформулировать что значит «хорошо выполнено» — агент не справится. AGENTS.md без ясного handoff-протокола и описания граничных случаев даёт агента который застревает на первом исключении. Правило простое: если вы не можете написать критерий успеха одним предложением — задача ещё не готова для автоматизации.

Поиск product-market fit. Агенты хорошо масштабируют и поддерживают то, что уже работает. Для поиска нового продукта, прощупывания рынка, итеративных экспериментов с аудиторией нужен человек с живым чувством контекста. Агент отлично поддерживает «Solar — внутрянка» — но создавала этот продукт не система агентов, а Юрий через прямое взаимодействие с рынком.

Итоги и следующий шаг

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

Полная система из 14 агентов строилась постепенно: от одного агента на одну задачу до текущей конфигурации за 8 месяцев. Каждый агент появлялся когда находилась конкретная задача, а не «потому что так надо в многоагентной системе». Начните с одного повторяющегося процесса — запустите за 2-4 недели. Посмотрите работает ли. Дальше сами поймёте что автоматизировать следующим.

Все артефакты из этой статьи — AGENTS.md-шаблоны разных агентов, конституция Solar OS, скрипты мониторинга и дайджестов, настройки Paperclip — в моём клубе «Solar — внутрянка». Не курс. Вот моё, бери и адаптируй: https://4bos.ru/inside/ — от 2 500 рублей в месяц.

Подробнее про написание AGENTS.md как инструмента операционного управления агентами: как писать AGENTS.md — полный гайд. Про то как один день выглядит в системе с автоматизацией: 10 AI-задач за один день.