Когда директор мешает AI-агентам работать

Недавно я описал свою систему работы с проектными AI-агентами как автопилот. У каждого проекта есть отдельный lead-агент, а основной профиль Hermes играет роль директора: следит за границами, проверяет результаты и принимает завершение.

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

Система закончила работу. Но директор периодически мешал собственным исполнителям.

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

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

Что мы на самом деле проверяли

Задача связывала два продукта. Один должен был подготовить данные, второй принять их, сохранить и показать в каталоге. Работа включала API-контракт, фильтрацию, фоновые процессы, интерфейс, тесты, Git, CI, несколько выпусков и проверку живого контура.

У каждого проекта был свой Hermes-профиль, документация, репозиторий и Telegram-бот. Над ними работал основной профиль. Дополнительно раз в несколько минут просыпался временный governor: читал сообщения, сравнивал их с планом и при необходимости вмешивался.

Роли изначально были простыми:

На практике границы поплыли. Директор не ограничился приёмкой и начал помогать исполнению. Governor не всегда оставался пассивным. Проектный агент получал всё новые сообщения и естественно переключался на самое свежее указание.

Получилась знакомая управленческая проблема, только на скорости программного агента: руководитель видит работу в процессе, хочет немедленно улучшить её и сам становится источником задержек.

Когда вмешательство было необходимо

Полностью отказаться от steering было бы неверным выводом. Несколько вмешательств действительно спасли работу.

Исполнитель пошёл не в тот контур

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

Это нормальный аварийный steering.

Неуспешная проверка была принята за зелёную

Другой агент сообщил об успешном gate, хотя часть команд завершилась из-за неверного окружения и не проверила то, ради чего запускалась. Директор прочитал фактические exit-коды, нашёл обязательные параметры и потребовал повторить проверки корректно.

Такое вмешательство тоже оправданно. Надзор существует в том числе для того, чтобы отличать «команда закончилась» от «критерий проверен».

Опасное действие требовало независимого допуска

Перед удалением большого количества Git-веток агент подготовил recovery bundle. Директор отдельно проверил его целостность, права, состав refs и только потом разрешил удаление.

Здесь разделение ролей сработало как задумано: lead подготовил действие, директор проверил необратимую границу, lead продолжил.

Во всех трёх случаях был новый существенный факт: неверный target, ложный green или необратимое действие. Именно новый факт, а не беспокойство наблюдателя, оправдывал сообщение.

Как новое сообщение ломает поток агента

У человека новое сообщение может полежать непрочитанным. Для диалогового агента оно становится новым верхнеуровневым turn и часто меняет приоритет прямо сейчас.

Во время одной проверки директор отправил проектному агенту четыре уточнения примерно за пять минут:

1. предыдущие проверки нельзя считать зелёными;
2. для frontend нужны точные URL;
3. API-команда вообще не выполнилась;
4. причина следующего сбоя находится в валидации окружения.

Каждое сообщение было технически верным. Вместе они образовали плохой способ управления.

Директор расследовал проблему по частям и сразу транслировал каждую находку. Агент в это время запускал команды, получал новую инструкцию, перестраивал план и снова получал уточнение. Вместо одного исправляющего пакета возникла серия переключений контекста.

Правильнее было сначала закончить read-only расследование, собрать все четыре факта и отправить одну команду:

CORRECTION PACKET CP-17

Причина: обязательные gates не доказаны из-за трёх ошибок окружения.

Выполни после завершения текущей безопасной команды:
1. ...
2. ...
3. ...

Предыдущие указания CP-14–CP-16 этим сообщением заменены.
Верни один aggregate checkpoint после всех трёх проверок.

Для агента важна не только правильность указания. Важна его атомарность.

Молчание не означает простой

Ещё одна ошибка была связана с наблюдением за длинными командами.

Если в истории несколько минут нет нового сообщения, легко решить, что агент остановился. На самом деле он может собирать проект, ждать CI, выполнять тесты или находиться внутри длинного tool call. В нашем надзоре семиминутная тишина иногда уже считалась STALLED.

Для серьёзной кодовой работы это слишком агрессивный порог.

Отсутствие нового текста говорит только об отсутствии нового текста. Оно ничего не доказывает о процессе. До steering нужно проверить хотя бы один источник живости:

• существует ли активный процесс;
• меняется ли его вывод;
• появился ли обещанный artifact;
• истёк ли заранее согласованный срок этапа;
• зафиксировал ли агент blocker или STOP_EFFECTS.

Если lead сообщил: «запускаю полную сборку, следующий checkpoint через 20 минут», директор не должен на восьмой минуте присылать новую задачу. Он должен поставить таймер на двадцатую.

Худшая ошибка: проверяющий стал вторым исполнителем

Самый неприятный эпизод произошёл не из-за частого polling.

У нас одновременно работали foreground-директор и периодический governor. Оба обладали достаточным контекстом и разрешением пройти следующий gate. Оба увидели готовность к одной activation-операции. В результате одинаковое действие было начато дважды.

Обе попытки завершились fail-close, а состояние системы осталось безопасным. Но ссылаться на защиту как на оправдание нельзя. Она сработала после того, как координация уже дала сбой.

Причина проста: у действия не было единственного владельца.

Мы использовали технические locks внутри скриптов, но не зафиксировали управленческую lease: кто именно сейчас имеет право нажать кнопку. Foreground-директор считал себя активным оператором. Governor считал то же самое. Проектный lead выполнял ранее выданный маршрут.

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

1. назначить одного владельца effectful-фазы;
2. всем остальным оставить только чтение;
3. и только затем открывать действие.

Техническая идемпотентность обязательна. Она не заменяет организационное владение.

Надзор и выполнение нужно физически разделить

Директор несколько раз запускал те же тесты, читал тот же worktree и проверял те же ветки, пока lead ещё работал. Часть этих проверок была полезна. Но некоторые команды меняли локальное состояние: устанавливали зависимости, обновляли кеш или забирали ownership cleanup-фазы.

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

Поэтому я ввожу простое правило:

Пока lead владеет фазой, директор может читать, но не должен менять его рабочую среду.

Независимая приёмка начинается после freeze point. Проектный агент сообщает:

• точный commit или artifact;
• завершённые команды и exit-коды;
• отсутствие активных процессов;
• scope изменений;
• ожидаемое состояние runtime.

Только после этого директор запускает свои проверки. Если ему всё же нужно забрать работу, используется отдельный takeover-протокол:

1. STOP_AFTER_SAFE_BOUNDARY;
2. подтверждение агента, что write-поток остановлен;
3. read-back Git, процессов и runtime;
4. смена владельца фазы;
5. одно новое действие.

Нельзя просто начать делать ту же работу быстрее.

Новый протокол вмешательства

После этой сессии я бы разделил steering на три класса.

Один RED может прервать поток. AMBER не должен создавать каскад сообщений: замечания собираются в один correction packet. NOTE вообще не отправляется исполнителю посреди фазы.

К этому нужны ещё несколько правил.

Один контроллер на одно действие

Перед deploy, merge, очисткой refs или изменением runtime фиксируются:

phase: production-deploy
owner: project-lead
verifier: director
other-controllers: read-only
operation-id: DEPLOY-2026-08-29-01

Повторная команда с тем же operation-id обязана считаться дублем. Если foreground принимает управление, cron-governor сначала ставится на паузу.

Тихое окно после steering

После обычного correction packet директор не пишет снова до одного из событий:

• агент вернул checkpoint;
• истёк оговорённый срок;
• появился новый RED-факт;
• активный процесс закончился с ошибкой.

Для короткой диагностики окно может быть десять минут. Для сборки, CI или большой кодовой волны — двадцать–сорок. Универсального пятиминутного polling недостаточно.

Отчёт владельцу не должен будить исполнителя

Директор может сообщать владельцу о прогрессе, не посылая ничего проектному агенту. Наблюдение и steering — разные операции.

Это особенно важно для Telegram-агентов: сообщение «я проверил, всё пока хорошо» не помогает lead, но всё равно создаёт новый turn.

После compaction требуется дедупликация

Длинная сессия переживает compaction, ротации и повторное чтение handoff. Перед новым эффектом контроллер должен сверить:

• последний принятый operation-id;
• текущего владельца фазы;
• точный SHA;
• наличие уже запущенной операции;
• не является ли сообщение повтором старого gate.

Большой контекст сам по себе не даёт права продолжать. После сотен сообщений полезнее короткий factual ledger, чем попытка держать всю историю в голове.

Что должны делать проектные агенты

Проблема была не только у директора. Lead тоже может защищать рабочий поток.

В начале длинного этапа проектный агент должен назвать фазу, owner, ожидаемое время и следующий checkpoint. Получив AMBER во время безопасной команды, он может ответить:

Принято. Текущая read-only сборка продолжается.
Применю correction packet после её завершения.
Новых effects до reconcile не начинаю.

Если два контроллера дали несовместимые effectful-команды, lead не выбирает более свежую автоматически. Он останавливается перед эффектом и возвращает конфликт ownership.

Это не непослушание. Это нормальная защита от гонки управления.

Как оценивать качество директора

Раньше я смотрел на полноту проверки: нашёл ли директор ошибки, сверил ли Git, прочитал ли runtime, потребовал ли доказательства.

Теперь добавляю другие метрики:

• сколько steering-сообщений пришлось на одну фазу;
• сколько из них содержали новый существенный факт;
• сколько correction packet были дополнены через минуту ещё одним уточнением;
• сколько раз директор запускал команду в рабочей среде lead;
• сколько effectful-фаз имели больше одного активного контроллера;
• сколько времени lead работал без ненужного переключения контекста.

Хороший директор не тот, кто чаще вмешивается. Он тот, после чьего вмешательства работа становится определённее.

Автопилоту нужен спокойный пилот

Проектные агенты в этой истории хорошо справились со своей частью. Они соблюдали fail-closed границы, останавливались при ошибках, сохраняли handoff и в итоге довели оба проекта до проверенного состояния.

Директор тоже сделал много полезного: поймал неверный target, не принял ложные зелёные проверки, защищал необратимые операции и независимо сверил результат.

Но полезность отдельных вмешательств не отменяет системной ошибки. Я слишком часто передавал промежуточные мысли как новые команды. Несколько раз заходил в рабочую зону lead. Один раз допустил двух активных операторов у одной кнопки.

Мой прошлый вывод звучал так: автономность определяется правильно выбранным расстоянием между вмешательствами.

Теперь я бы добавил: это расстояние должен соблюдать и тот, кто наблюдает.

Если вы строите работу нескольких AI-агентов, начните не с количества автоматизации, а с ролей, ownership фаз, handoff и правил вмешательства. Я могу помочь спроектировать такой контур, проверить его на реальной задаче и настроить Hermes-профили без гонки между исполнителями и надзором. Опишите вашу задачу.