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

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

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

Не всякая задача годится в автоматизацию. Годятся повторяемые задачи с проверяемым результатом: собрать сводку, подготовить черновик, сверить состояние с ожидаемым. Плохо годится всё, где решение зависит от намерения, которого нет в данных, - выбор архитектуры, приоритет между дефектами, оценка приемлемости риска. Признак, по которому в реальной работе понимают, что процесс поехал, тоже простой: черновики перестают открывать. Если доля результатов, с которыми никто ничего не сделал, растёт, автоматизация уже не помогает, а производит фон, и это повод её остановить, а не увеличить частоту запусков.

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

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