Agent Decommissioning

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

Триггеры, которые стоит назвать заранее

Без явных триггеров старые агентные системы почти всегда живут дольше, чем безопасно и полезно:

  • среда исполнения или модель устарели;
  • контракт возможности больше не считается безопасным;
  • стоимость сопровождения стала слишком высокой;
  • потолок качества достигнут, дальше нужна замена;
  • новый платформенный путь вытесняет старый (Architecture Governance);
  • изменились регуляторные или управленческие требования;
  • продуктовая задача больше не существует.

Последний пункт — самый частый и самый незамечаемый: задача ушла, а агент остался, потому что его никто не выключал.

Вывод и замена — разные сценарии

Вывод из эксплуатации — система или возможность просто снимается. Замена — старая снимается, но её место занимает новая, до или параллельно.

Разница не терминологическая: при замене возникает период, когда обе системы имеют право действовать, и именно в нём случаются двойные побочные эффекты. Поэтому замена делается поэтапно, а не бинарным переключением, с явным ответом на вопрос, кто владеет действием в переходном окне (Canary Release LLM).

Уход идёт по слоям

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

  • Право на действие — политики, подтверждения, контракты возможностей;
  • Идентичность и доступы — токены, сервисные учётки, подписки на события (Agent Identity);
  • Память и контрольные данные — отдельная дисциплина: записи, влиявшие на решения, нельзя просто удалить, если по ним ещё может понадобиться разбор (Memory Boundaries);
  • Возможности и схемы — объявляются устаревшими по процедуре, как публичный API (API As Product);
  • Пользовательский переход — то, что видит человек, тоже часть жизненного цикла.

Почему это вопрос безопасности, а не уборки

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

Связано с

  • ADLC — конец цикла, который обычно не проектируют
  • Agent Registry — учёт, из которого видно кандидатов на вывод
  • Agent Governance — управление парком и уровнями автономии
  • Agent Identity — какие субъекты нужно погасить
  • Memory Boundaries — почему память удаляется не сразу
  • API As Product — процедура объявления устаревшим
  • Canary Release LLM — поэтапность замены