# Как мультиагентная автоматизация выдерживает эксплуатацию

> Мультиагентная автоматизация работает в бизнес-операциях, когда роли, состояние, согласования и границы отказов заданы до инструкций.

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

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

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

## Несколько агентов должны окупать координацию

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

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

Перед разделением я применяю четыре проверки:

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

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

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

## Роли должны следовать границам полномочий

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

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

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

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

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

## Координатор управляет состоянием, а не истиной

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

Статусом владеет движок процесса. Агенты предлагают события вроде `invoice_extracted`, `policy_check_passed` или `approval_requested`. Движок проверяет, допустимо ли событие из текущего состояния, записывает его и назначает следующую задачу. Агент никогда не должен продвигать процесс, просто записав `status: complete` в общий документ.

Небольшая политика переходов полезнее длинной инструкции для агента-руководителя:

```yaml
workflow: supplier_bank_change
version: 3
states:
  received:
    next: extracted
    actor: extractor
  extracted:
    next: verified
    actor: verifier
  verified:
    next: awaiting_approval
    actor: coordinator
  awaiting_approval:
    next: scheduled
    actor: human_approver
  scheduled:
    next: applied
    actor: account_executor
limits:
  max_agent_attempts: 2
  expires_after_hours: 24
  require_two_source_match: true
```

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

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

Не рассчитывайте, что агент-руководитель заметит противоречия в расшифровке разговора. Выражайте согласие через данные. Например, требуйте `legal_name_match: true` от одного проверяющего и `bank_owner_match: true` от другого, причем каждый должен приложить ссылку на доказательство. Сервис переходов может потребовать оба результата, не истолковывая эссе.

## Долговечное состояние делает повторы безопасными

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

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

Полезное событие имеет скучную форму:

```json
{"workflow_id":"wf_1842","task_id":"apply_refund","attempt":2,"input_version":4,"idempotency_token":"wf_1842:refund:order_731","decision":"approved","evidence_refs":["order_731","case_992"],"policy_version":"refunds_2026_03"}
```

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

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

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

## Сдерживание начинается у каждого побочного эффекта

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

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

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

Путь отказа нужно спроектировать до запуска. Во время проверки пройдите такую последовательность:

1. Выберите один ложный результат, который проходит схему агента.
2. Проследите все переходы и учетные данные, доступные этому результату.
3. Отметьте первую детерминированную проверку и первую точку участия человека.
4. Рассчитайте максимальное число и стоимость побочных эффектов до обнаружения.
5. Изменяйте права или лимиты, пока максимум не станет приемлемым.

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

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

## Человек должен одобрить действие до исполнения

Точка человеческого согласования работает, только когда проверяющий видит конкретное предлагаемое действие, доказательства и результат одобрения. Просьба одобрить абзац, написанный агентом, вызывает усталость. Просьба одобрить «замену банковского счета поставщика 412 с отпечатка A на отпечаток B» создает решение с понятной ответственностью.

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

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

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

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

## У координации должен быть бюджет

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

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

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

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

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

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

## Наблюдаемость должна восстанавливать решение

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

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

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

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

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

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

## Расширяйте процесс по последствиям, а не по удобству

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

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

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

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

Я применял такой подход, начиная с последствий, когда сократил операционную команду AppMaster с 25 человек до 2 инженеров, усиленных ИИ, сохранив объем выпуска и доступность. Кадровый результат привлекает внимание, но перенести в другую компанию можно работу над контролем: сужение ролей, устранение повторяющейся ручной координации и защита производственных изменений явными операционными границами.

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

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

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

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

Выпуски агентов и политик также требуют разных путей согласования. Редактор инструкции не должен получать возможность увеличить лимит возврата изменением текста. Храните денежные пороги, списки защищенных полей, допустимые типы действий и правила согласования в политике, которую могут проверить владельцы делового контроля. Инструкции могут объяснять, как классифицировать доказательства внутри этих рамок.

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

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

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

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

## Оценивайте систему по сдержанным результатам

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

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

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

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