AES FIELD NOTE / АРХИТЕКТУРА АГЕНТОВ
AI-агенту нужна идентичность, а не только prompt
Почему корпоративным агентам нужны устойчивая identity, цепочки делегирования, ограниченные полномочия, короткоживущие credentials и отзыв прав вне model session.
Большинство AI-агентов до сих пор определяются именем, prompt и chat session. Для демонстрации этого достаточно. Для организации — нет.
Компания должна отвечать на другой набор вопросов. Кто действует? Кто делегировал миссию? На основании какой политики? С доступом к каким системам, данным и бюджету? На какой срок? И как отозвать эти полномочия, не разыскивая агента во всех приложениях, где он успел появиться?
Модель — это executor. Идентичность агента принадлежит организационному runtime.
Почему session не может быть identity
Model session временна. Контекст может быть обрезан. Модель может обновиться. Workflow может передать исполнение другой модели, детерминированному сервису или человеку. Если полномочия неявно хранятся внутри session, каждый переход либо теряет нужный контекст, либо переносит дальше невидимые права.
Ошибка здесь концептуальная: мы путаем интеллект, исполняющий отдельный шаг, с организационным principal, который отвечает за работу.
В AI-native компании один устойчивый агент за время жизни может использовать несколько моделей. Одна модель, в свою очередь, может выполнять задачи многих агентов. Поэтому identity нельзя выводить из названия модели, API key или conversation ID.
Устойчивая карточка агента
Runtime нужна стабильная запись, существующая вне любой session. Она должна описывать агента как участника организации, а не как программный процесс.
Практическая модель идентичности агента
Глобально уникальная identity с владельцем, организационной принадлежностью и lifecycle state.
Ответственность, которую ожидает организация, а не случайный набор доступных tools.
Человек, стратегия или parent agent, выдавшие текущую миссию и полномочия.
Явные ограничения на системы, классы данных, действия, бюджет, время и дальнейшее делегирование.
Непрерывная связь решений и действий с миссией, политикой и делегатором.
Created, active, suspended, expired или revoked — с исполнением состояния на всех поверхностях.
Identity — это цепочка делегирования
Агент редко владеет полномочиями сам по себе. Они начинаются у человека, совета, политики или операционной роли и делегируются в конкретную миссию. Эта цепочка должна оставаться видимой.
Практическая последовательность выглядит так: principal → role → mission → delegation → capability envelope → session credentials → action receipts.
Каждое звено сужает предыдущее. Strategy agent может получить право создать campaign mission. Campaign agent — запросить разрешённые клиентские сегменты. Publishing executor — один credential для одного подготовленного поста и одного канала. Он не должен наследовать более широкий доступ strategy agent.
Credentials должны быть временными, identity — устойчивой
Долгоживущие API keys склеивают идентичность и доступ в один объект. После копирования в workflow их трудно ограничивать, отслеживать и отзывать.
Более надёжный паттерн — сохранять identity агента, но после policy evaluation выдавать короткоживущие credentials на конкретное действие. Credential содержит только минимально необходимую capability, resource scope, срок действия и контекст делегирования.
- Модель никогда не получает постоянный организационный secret.
- Задача не может незаметно расширить собственные полномочия.
- Отозванный агент перестаёт получать новые execution credentials.
- Любое внешнее действие связано с миссией и делегатором.
- Смена модели не меняет identity и не стирает ответственность.
Настоящая проверка — отзыв полномочий
Многие системы умеют выдавать доступ. Гораздо меньше систем умеют согласованно его отзывать. Если остановка агента требует редактировать prompts, менять общие secrets и вручную проверять несколько SaaS-продуктов, организация не контролирует его identity.
Revocation должна менять одно авторитетное lifecycle state. Выдача новых credentials прекращается сразу. Задачи в очереди отменяются или удерживаются. Активная работа доходит до безопасной точки. Downstream delegations истекают по явной политике. Evidence record при этом сохраняется.
Как это меняет архитектуру продукта
Agent identity не может оставаться подписью в chat UI. Она становится отдельным сервисом, связанным с политикой, задачами, памятью, approvals, интеграциями и аудитом. Каждый запрос на исполнение проверяет не только намерение модели, но и то, какая организационная identity действует, по какой цепочке делегирования и с каким остатком полномочий.
Здесь проходит граница между ассистентом и цифровым коллегой. Ассистент заимствует session пользователя. Управляемый агент имеет собственную устойчивую identity, получает явные миссии, работает внутри capability envelope и оставляет доступные организации доказательства.
Без устойчивой identity агент остаётся диалогом с tools. С ней он становится управляемым участником компании.
