AgentKit и агентный UX как новый слой enterprise software
Агентные интерфейсы меняют то, как корпоративный софт выглядит и работает. Разбираю, что это значит для архитектурных решений и UX-стратегии компаний.
Когда несколько лет назад появились первые чат-боты в корпоративных системах, их воспринимали как удобный интерфейс поверх базы знаний. Спросил - получил ответ. Это был шаг вперёд по сравнению с поиском в документации, но принципиально ничего не менял.
Агентный подход - другое. Агент не просто отвечает. Он выполняет последовательность действий, использует инструменты, обращается к системам, принимает промежуточные решения. Пользователь даёт задачу - агент её выполняет, а не просто информирует.
Это меняет то, как нужно думать об архитектуре корпоративного ПО.
Что такое AgentKit и зачем он нужен
AgentKit - это концепция (и ряд конкретных фреймворков под этим или похожими названиями), которая описывает стандартизированный способ строить агентов: управлять инструментами, которые они вызывают, памятью между сессиями, контекстом задачи и безопасностью действий.
Без стандартизации каждый агент - это своя кухня со своими правилами. С ней агенты становятся компонентами, которые можно сочетать, тестировать и заменять.
Для enterprise это важно: компания не может управлять сотней уникальных агентов с разной логикой доступа и разной обработкой ошибок. Ей нужен слой управления.
Что меняется в UX
Традиционный enterprise-интерфейс - это форма, таблица, кнопка. Пользователь знает, что делает система, и управляет ею явно.
Агентный UX - другой контракт. Пользователь описывает намерение. Агент интерпретирует его, планирует шаги и выполняет. Пользователь видит результат, а не весь процесс.
Это удобнее для сложных задач. Но создаёт новые проблемы:
- что делать, если агент сделал не то?
- как объяснить пользователю, что произошло?
- как дать возможность отменить действие на полпути?
- как обеспечить аудиторский след для compliance?
Это не технические мелочи. Это центральные вопросы продуктового дизайна агентных систем.
Как это меняет архитектуру enterprise software
Когда агент вызывает инструменты - он вызывает API. Значит, качество внутреннего API-дизайна компании напрямую влияет на то, что могут делать агенты. Хорошие внутренние API становятся активом.
Управление доступом усложняется. Агент действует от имени пользователя, но не является пользователем. Нужна модель делегированных прав, которая позволяет агенту делать то, что разрешено пользователю, но не больше.
Логирование действий становится обязательным. Агент сделал что-то в системе - это должно быть записано с контекстом: кто дал задачу, какое действие было выполнено, в каком состоянии.
Практические вопросы для руководителей
Если в вашей компании рассматривают агентные системы - вот несколько вопросов, которые стоит задать до старта:
- Какие внутренние системы агент будет вызывать и готовы ли их API к этому?
- Как будет устроен аудитный след действий агента?
- Как пользователь сможет понять, что именно сделал агент и почему?
- Какие действия агент не должен иметь права выполнять без явного подтверждения?
- Кто несёт ответственность за ошибку агента - технический владелец или пользователь, который дал задачу?
Агентный UX - это не фича. Это архитектурный слой. Относиться к нему нужно соответственно.