Agentic Nesting предлагает новый подход к enterprise application integration через multi-agent архитектуру. Вместо API-связей — семантическая оркестрация через агентов.
Проблема классической enterprise application integration не в отсутствии инструментов, а в их предельной жесткости. ESB, API gateway, iPaaS и RPA решают связность, но усиливают coupling и стоимость изменений. Каждая новая интеграция требует явного описания схем, контрактов и потоков. При росте числа систем сложность растет нелинейно, а любые изменения в бизнес-логике ведут к каскадным правкам. Дополнительно, такие подходы плохо работают с неструктурированными задачами и не понимают бизнес-контекст. В результате системы остаются изолированными, а пользователи компенсируют это ручными процессами.
Предложенный подход Agentic Nesting переопределяет базовую единицу интеграции. Вместо “Application-as-Tool” вводится модель Application-as-Agent. Каждое приложение оборачивается в AI-агента, который понимает структуру, данные и поведение системы. Интеграция происходит не через вызовы API, а через диалог между агентами — “Conversation-as-Integration”. Это снижает зависимость от жестких контрактов, но вводит новые trade-offs. Система становится гибче и лучше работает с неопределенными задачами, но увеличивает latency и стоимость выполнения из-за LLM-инференса.
Архитектурно решение реализовано как иерархическая multi-agent система. В отличие от “плоских” моделей, используется вложенная структура. Есть три уровня:
- coordinating agent — разбирает intent и управляет задачами,
- application agents — инкапсулируют конкретные системы,
- capability agents — предоставляют общие функции.
Ключевой механизм — Application Agent Initialization (AAI). Он автоматически извлекает структуру приложения, строит knowledge graph и генерирует описание агента с границами возможностей. Это важно: агент получает не просто API-доступ, а семантическую модель системы. Взаимодействие между агентами происходит через natural language, что упрощает эволюцию системы — изменения не требуют пересборки контрактов.
На уровне реализации используется layered architecture. Frontend построен на Next.js с единым conversational интерфейсом. Backend управляет lifecycle агентов и маршрутизацией задач. Каждый агент запускается в изолированной среде, что обеспечивает security isolation и контроль доступа. Коммуникация реализована через NDJSON streaming, что позволяет отслеживать выполнение задач в реальном времени. Также предусмотрена поддержка разных runtime: CLI-агенты, API-интеграции и протоколы вроде ACP.
Результаты показывают практическую применимость подхода, но без точных метрик. В кейсах система автоматизирует сценарии, которые раньше требовали ручной координации между несколькими системами. Например, multi-source анализ данных или сквозные workflow выполняются через один запрос на естественном языке. Это снижает операционные издержки и уменьшает количество ошибок. Однако авторы явно указывают ограничения: рост latency, сложность обеспечения детерминизма и проблемы масштабирования при увеличении числа агентов.
Отдельно стоит отметить концепцию “Application-as-Data”. Подключение приложения фактически означает подключение его данных без ETL. Это сдвигает архитектуру от централизованных data lake к federated access модели. Такой подход снижает затраты на хранение и синхронизацию, но переносит сложность в слой оркестрации и семантического согласования.
В сравнении с Tool-Use парадигмой, Agentic Nesting выигрывает в гибкости и работе с комплексными задачами, но уступает в предсказуемости и эффективности для простых операций. Поэтому на практике возможна гибридная модель: API для детерминированных задач, агенты — для orchestration и reasoning.
Итог: Agentic Nesting — это эволюционное смещение от интеграции через интерфейсы к интеграции через смысл (semantics). Подход выглядит прагматичным для сложных enterprise-ландшафтов, но требует зрелых механизмов контроля, безопасности и оптимизации стоимости.
Источник информации
arXiv — крупнейший открытый репозиторий препринтов (с 1991 года, под эгидой Корнелла), где исследователи оперативно размещают рабочие версии статей; материалы общедоступны, но не проходят полное рецензирование, поэтому результаты следует считать предварительными и, по возможности, сверять с обновленными версиями или рецензируемыми журналами. arxiv.org