Правила выбора инструментов для агентов, которые пишут, отправляют и деплоят

Почему это быстро становится рискованным

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

Этот скачок легко пропустить, потому что задача на поверхности может выглядеть почти одинаково. "Напиши сообщение" звучит безобидно. "Отправь сообщение 8 000 клиентам" — это уже другой уровень риска. "Обнови конфигурационный файл" звучит мелко. "Запушь это в продакшн" — нет.

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

Контраст прост:

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

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

Хорошие правила выбора инструментов начинаются с blast radius, а не с удобства. Задайте один простой вопрос: если агент ошибётся, сколько вреда он сможет нанести до того, как человек заметит?

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

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

Как ранжировать инструменты по blast radius

Начните с одного вопроса: что может изменить этот инструмент, если агент один раз ошибётся? Это и есть blast radius. Ранжируйте инструменты по эффекту, а не по тому, как часто агент их использует, и не по тому, насколько уверенно звучит модель.

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

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

Отправка почты поднимает риски значительно выше, потому что сообщение быстро достигает реальных людей. Одно неправильное письмо может сбить с толку клиента, раскрыть внутренние детали или обещать то, чего команда не сможет выполнить. Можно отправить follow-up, но нельзя полностью вернуть доверие.

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

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

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

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

Модель риска в четыре уровня

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

Уровень 1 — только чтение. Агент может искать в документации, читать тикеты, просматривать логи или собирать аналитику. Он учится, но ничего не меняет.

Уровень 2 — подготовительная работа. Агент может подготовить письмо, написать SQL-запрос для ревью, подготовить план деплоя или заполнить ответ в поддержку без отправки. На этом уровне всё ещё возможен человеческий контроль перед действием.

Уровень 3 начинает затрагивать внешний мир или системные записи. Отправка письма клиенту, обновление поля в CRM, изменение события в календаре, закрытие тикета или правка записи в базе данных относятся сюда. Эти действия часто выглядят мелкими, но могут ввести людей в заблуждение, создать юридические проблемы или оставить запутанный аудит.

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

Уровень должен зависеть от стоимости восстановления, а не только от названия кнопки. Инструмент может выглядеть безобидно, но если отмена действия занимает часы, вовлекает несколько людей или требует обращения к клиентам — повышайте уровень.

Черновик письма обычно Уровень 2. Инструмент, который отправляет это письмо 5 000 клиентам, — Уровень 3. Инструмент, который может и отправить письмо, и начислить кредит на счёт после жалобы, близок к Уровню 4, потому что смешивает коммуникацию с деньгами.

Та же логика применима к инженерным инструментам. Чтение логов деплоя — Уровень 1. Написание релиз-нотов — Уровень 2. Перезапуск сервиса в staging — Уровень 3. Применение конфигурации в продакшне — Уровень 4, даже если это одна строка.

Какие проверки подходят каждому уровню

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

На самом низком уровне пусть агент действует сам, но ведите подробные логи. Это подходит для тегирования тикетов, суммирования звонков, черновиков внутренних заметок или сбора данных для отчёта. В журнале должен быть промпт, используемый инструмент, результат, метка времени и пользователь или сервис, который его вызвал.

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

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

Деньги и продакшн требуют подписанного одобрения, а не размытых административных проверок. Если действие может списать с карты, сделать возврат, изменить цену, задеплоить код, обновить DNS, коснуться продакшн-данных или повернуть секреты — связывайте одобрение с реальным человеком и точным действием, которое он одобрил. Если нагруз полеза меняется — запрашивайте одобрение снова.

Небольшая команда может упростить правила:

• Низкий риск: запуск без одобрения с логами
• Инструменты для черновиков и публикаций: требуют превью
• Внешняя коммуникация: требуют одобрения человека
• Деньги и продакшн: требуют подписанного одобрения, иногда двух человек

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

Как задать правила

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

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

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

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

После списка действий ранжируйте каждое по blast radius. Редактирование внутреннего черновика — мелко. Отправка 500 писем клиентам — серьёзнее. Слияние кода в main — ещё больше. Деплой в продакшн, связанный с выставлением счетов, платежами или пользовательскими данными — вверху.

Для каждого уровня установите три конкретных лимита: одобрение, время и объём. Решите, нужно ли действие без одобрения, одна проверка человека или двухфакторное одобрение. Решите, когда это действие может выполняться и как долго одобрение действительно. Решите, скольким письмам, записям, файлам или деплойам разрешено одновременно затрагиваться.

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

В современной стартап-стеке это быстро важно. Обновление статьи помощи в CMS и запуск CI/CD, который достигает живого кластера Kubernetes — очень разные вещи, даже если обе команды идут из одного чата.

Тестируйте правила сначала на фейковых данных. Используйте песочницу почты, staging-репозиторий и примерные записи клиентов. Пробуйте обычные кейсы, плохие промпты и крайние случаи. Если агент пытается отправить слишком много, изменить неправильную запись или просит одобрение слишком поздно — исправьте правило до выхода в реальную среду.

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

Реалистичный пример

Клиент пишет в поддержку после бага в биллинге: его дважды сняли. Агент читает тикет, проверяет историю аккаунта и вытаскивает последний счёт. Эта часть низкорисковая, агент только собирает факты.

Далее агент готовит ответ. Он может объяснить ситуацию, извиниться и предложить следующий шаг. Также он может добавить заметку в CRM с типом проблемы, номером счёта и кратким резюме для команды.

Такие обновления CRM обычно имеют небольшой blast radius. Если заметка корявая, команда поправит её за секунды. Клиент этого не увидит, и деньги не сдвинутся.

Отправка письма — другое дело. Как только сообщение уйдёт, компания даёт письменное обещание. Если в черновике написано "мы уже вернули вам деньги", а возврат не был одобрен — у поддержки появится проблема более серьёзная, чем исходный баг.

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

• Агент может читать тикет и историю биллинга.
• Агент может подготовить ответ клиенту.
• Агент может писать внутренние заметки в CRM.
• Человек должен одобрить финальное письмо перед отправкой.

Теперь баг доходит до инженеров. Кодовый агент находит правило биллинга, из‑за которого произошло двойное списание, и готовит фикс. Он может открыть pull request, добавить тесты и объяснить изменение простыми словами.

Тем не менее он не должен пушить прямо в продакшн. Ревьюер должен проверить патч, а у команды должен быть план отката. Если фикс сломает генерацию счетов, нужен один понятный шаг, чтобы быстро вернуть систему в рабочее состояние.

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

Такое разделение сохраняет быстрые части быстрыми. Агенты занимаются чтением, подготовкой, тегированием и подготовкой работы. Люди одобряют действия, которые касаются обещаний клиентам, продакшна или денег.

Ошибки, которые делают команды

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

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

Ещё одна типичная ошибка — считать staging и production одним и тем же пространством с разными ярлыками. Команды позволяют агенту тренироваться в staging, не видят очевидных проблем и затем дают почти те же права в продакшне. Это упускает главное. Ошибка в staging — шум. Ошибка в продакшне может отправить реальные письма, изменить живые цены или сломать процесс оплаты.

Названия инструментов тоже вводят в заблуждение. "deploy-helper" или "mail-assistant" звучат безобидно, но названия не важны — важны права. Один почтовый инструмент может только готовить письма. Другой может отправлять 50 000 контактов. Один инструмент деплоя может собрать превью-ветку. Другой может перезапустить живые сервисы. Нужно инспектировать реальную область ответственности за каждой кнопкой.

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

Откаты тоже часто пропускают. Команды планируют успех, а не хаотичные сбои. Если агент редактирует конфигурацию — кто вернёт последнюю рабочую версию? Если он отправил не ту рассылку — кто остановит следующую партию? Если деплоит сломанный билд — кто его откатит и сколько это займёт? Если никто не ответит на эти вопросы за минуту, готовность недостаточна.

Именно такой обзор важнее всего перед релизом: давайте агентам минимально необходимые права, реально разделите staging и production, и протестируйте путь отмены прежде, чем доверять пути выполнения. Консультации Fractional CTO Олега Сотникова часто помогают командам пройти эти границы практически.

Короткий чеклист перед запуском

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

Проверьте это до того, как дать агенту живой доступ:

• Держите денежные операции за именованным одобрением. Списания, возвраты, покупки, кредиты и изменения счётов не должны выполняться по суждению агента.
• Разделяйте тестовую аудиторию и реальных людей. Если агент может отправлять e‑mail, SMS или сообщения, начните с внутренних аккаунтов, строгих лимитов и чётких логов каждого сообщения.
• Начинайте доступ к продакшну с минимально возможного уровня. Read-only лучше, чем write. Staging лучше, чем production. Сгенерированный diff плюс человеческое одобрение лучше прямого деплоя.
• Дайте людям реальную кнопку выключения. Кто‑то должен иметь возможность приостановить очередь, отозвать креденшеншлы или отключить задачу за секунды.
• Докажите, что вы можете отменить последний шаг. Откатите деплой, отмените партию сообщений или восстановите запись из бэкапа до запуска, а не после ошибки.

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

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

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

Если какой‑то ответ кажется смутным — не добавляйте инструмент в рабочий процесс. Безопасный первый запуск обычно медленнее и с большим числом одобрений, и это верный компромисс.

Что делать дальше

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

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

Практический rollout прост: дайте агенту read-only доступ к системам, которые ему нужны, разрешите ему создавать черновики писем, тикетов, документов или pull request-ов, но оставьте финальное действие человеку. Добавляйте по одному более рискованному действию только после того, как более безопасный вариант стабильно работает в ежедневной практике. Затем просматривайте реальные логи и ужесточайте промпты, права и правила одобрения.

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

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

То же самое — для кода и деплоев. Если агент может открыть pull request — укажите, кто его ревьюит. Если он может деплоить в staging — укажите, какие проверки должны пройти сначала. Если задействованы деньги или продакшн — назовите точный момент, где требуется человеческое одобрение.

Один рискованный шаг за раз — правильный темп. Команды попадают в беду, когда упаковывают слишком много полномочий в один rollout потому, что демо выглядело убедительно.

Если хотите второе мнение перед расширением доступа, Oleg Sotnikov и oleg.is специализируются на таких практических технических обзорах: права доступа, планы выката, границы продакшна и AI‑первых рабочих процессов, которые не дают агенту слишком много власти слишком рано. Это обычно дешевле, чем расхлёбывать последствия одной плохой рассылки или небрежного изменения в продакшне.