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

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

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

MuleSoft Agent Fabric - это объединенная платформа, которая предоставляет каждому предприятию легкий способ обнаружения, оркестрации, управления и наблюдения за любым агентом, вне зависимости от места его создания.

Столбы ткани MuleSoft Agent

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

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

Управление: Управление агентами MuleSoft использует Flex Gateway и его поддержку Протокола типового контекста (MCP) и Протокола Agent2Agent (A2A). С помощью Flex Gateway предприятия могут внедрять политики безопасности и соответствия каждому взаимодействию агента, агента и инструментария.

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

Ткань агента поддерживает метод «Спецификация-первая» (YAML), когда пользователи определяют сети агентов посредством дескриптора метаданных («YAML-файл»). Этот файл YAML агностичен для MuleSoft и отделяет определение сети агентов от его выполнения.

Каждая агентская сеть (YAML) определяет определенную функциональную область со своими агентскими активами, включая их операционные правила и политики. YAML используется для включения четырех столбцов ткани агента:

  1. Откройте: Заполнение реестра агентов существующими агентскими активами, например:
    1. Агенты, развернутые на разных платформах (MuleSoft или другие)
    2. Серверы MCP
    3. Поставщики LLM
  2. Оркестр: Создание брокеров-агентов для оркестрации
  3. Управление: Применение политик в отношении активов в целях безопасности и управления
  4. Наблюдайте: Определите и повторно используйте подключения к определенным активам. Кроме того, сети агентов поддерживают возможности наблюдения и мониторинга.

Путешествие пользователя начинается в конструкторе кодов Anypoint Code. Используйте новую команду, доступную посредством палитры команд под названием «MuleSoft: Создание проекта агентской сети» для создания нового проекта. Данная команда создает новый проект («Сеть агентов»), содержащий два файла.

  • agent-network.yaml: Этот файл определяет конфигурацию мультиагентной системы, включая оркестрацию агентов на основе искусственного интеллекта посредством внешних инструментов (посредством MCP) и агентов (посредством протокола A2A). Этот формат предоставляет декларативный способ определения возможностей агента, зависимостей и интеграций.

  • exchange.json: Все проекты сети агентов также содержат файл exchange.json. Этот файл содержит метаданные активов, доступные в Anypoint Exchange после публикации активов сети агентов.

Разработка сети агентов осуществляется в соответствии со стандартным жизненным циклом разработки программного обеспечения (SDLC), состоящим из четырех основных этапов:

  1. Настройка среды: Настройка среды выполнения и шлюзов
  2. Создание и дизайн проекта: Создание спецификации проекта «Сеть агентов»
  3. Создание и публикация: Создание и публикация активов в реестре агентов
  4. Развертывание: Развертывание или продвижение сети агентов в указанной среде

После создания проекта и создания требуемого приложения MuleSoft и активов сделайте их доступными в Exchange. В конструкторе кодов Anypoint запустите процесс создания и публикации посредством «MuleSoft: Команда «Опубликовать проект брокера-агента для обмена», доступная на палитре команд.

Этап публикации трансформирует каждый агентский актив в файле YAML в спецификацию A2A, MCP или LLM и публикует его в Exchange.

Кроме того, система публикует YAML для обмена посредством нового типа активов агентской сети. Вы можете просмотреть этот актив в пользовательском интерфейсе реестра агентов и найти его посредством Exchange API.

См. Файл Agent Network, определяющий сеть агентов для предприятия. Эта сеть агентов активирует сеть для выполнения заказа в Salesforce, Stripe, еще одном агенте выполнения заказа и сервере MCP запаса с единым управляемым политикой взаимодействием.

  • Обнаружение
    Опубликуйте существующих агентов и инструменты (например, Salesforce, Stripe, Exfillment заказа и Inventive) в качестве активов Exchange для повторного использования. Также определение выполнения заказа (YAML), версионное и общедоступное, позволяющее быстро адаптироваться для ролей, регионов или дочерних компаний без восстановления потоков.
  • Оркестр
    Брокер-агент использует LLM для разделения процесса выполнения заказа на последовательность задач, например, проверка сведений о клиенте, распределение запасов и вычисление стоимости доставки. Потом он выполняет этот бизнес-правило, вызывая агентов MCP и A2A, обеспечивая запрос на утверждение человека в цикле при необходимости.
  • Управление
    Anypoint Flex Gateway применяет проверку подлинности, доступ с наименьшими правами и ограждения. Политики API Manager обеспечивают последовательное управление во всех вызовах и обменах данными.
  • Наблюдать
    Мониторинг и трассировка предоставляют комплексное представление о ходе выполнения, сбоях и задержке. Визуализация отображает, какие агенты взаимодействовали и где произошли преграды.
  • Доверие и соответствие
    Централизованные регистрационные данные, контрольные журналы и наследование полисов поддерживают безопасность, конфиденциальность и нормативные требования (обработка PII, утверждения и разделение обязанностей).

Диаграмма отображает разные узлы сети агентов (метаданные), определенные в YAML.

  • Цель: Exchange - это каталог агентов, инструментов и других активов. Его главная цель - решить проблему "разрастания агентов", предоставив единый управляемый каталог для обнаружения, лечения и управления жизненным циклом разнородных агентов. Он позволяет разработчикам находить и повторно использовать агентов, ответственных за платформу для поддержания видимости, а оркестраторам для обнаружения возможностей.
  • Неоднородные по конструкции: Anypoint Exchange теперь поддерживает три новых актива - агентов, MCP и LLM. Exchange создан для универсального каталога, позволяющего регистрировать агентов любого типа и управлять ими. Он поддерживает совместимых с A2A агентов, серверов MCP и поставщиков LLM из любого источника, включая сторонних, Agentforce и настраиваемых агентов MuleSoft.
  • Базовые метаданные: Каждый зарегистрированный актив содержит базовый набор неизменяемых метаданных, включительно с «Уникальным именем» и «Версия», «Ответственность» и «Публикатор». Состояния жизненного цикла (разработка, этапирование, производство, нерекомендуемые) также отслеживаются.
  • Discovery:
    • Design-Time: Разработчики могут обнаружить зарегистрированных агентов либо посредством существующего пользовательского интерфейса Exchange, либо посредством естественно-языкового поиска с помощью флюидов в конструкторе кодов Anypoint.
  • Присвоение тегов и классификация: Активы можно классифицировать по типу (агент, MCP, LLM, брокер) и домену (например, отдел кадров, погода), используя базовую систему присвоения тегов ключевых значений, включающую динамические политики связывания, поиска и выбора.
  • Каталог: Хранилище поддерживает как личные, так и внутренние модели каталога для общего доступа к агентам в организации.
  • Визуализация: Предоставляет визуальный инструмент для поддержки представлений сети, отображающий подключения для отдельных активов или всю карту узлов и ссылок в организации с возможностями фильтрации.

Брокеры в агентской сети могут ссылаться на зарегистрированных агентов, серверы MCP и поставщиков LLM, хранящиеся в Anypoint Exchange. Но если они еще не зарегистрированы, они могут быть заявлены в метаданных сети агентов (YAML) и автоматически зарегистрированы. В примере несколько агентов, серверов MCP и поставщиков LLM объявляются и регистрируются в Anypoint Exchange.

Брокер-агент — это интеллектуальный агент маршрутизации, координирующий делегирование задач специализированным агентам предприятия. Он определяется агентами и серверами MCP, используемыми для выполнения задач.

Брокер — это специализированный агент, появляющийся в Anypoint Exchange после публикации актива сети агентов и повторного использования другими брокерами.

Брокеры определяются в разделе «Брокеры» YAML. Определенные брокеры прозрачно «компилируются» в приложение, не требуя предварительных Knowledge о Mule. Это созданное приложение развертывается в CloudHub 2.0 (CH2) и использует надежную инфраструктуру CH2.

Это значит, что брокеры-агенты пользуются установленными характеристиками производительности CloudHub 2.0, включительно с возможностями регистрации и показателей. Операционные аспекты, например, «Стоимость эксплуатации» и «Мониторинг/предупреждение/инструментирование» аналогичны любой другой загруженности.

В сценариях, требующих вмешательства человека (Human-in-the-Loop), состояние каждого взаимодействия поддерживается посредством MuleSoft Object Store, распределенного решения, созданного для эффективного управления состоянием в высокопараллельных средах.

Определение брокера состоит из двух разделов: карточки и спецификации.

Раздел карты соответствует спецификации A2A. Помимо прочего, в нем описываются контракт, навыки и возможности брокера-агента. URL-адрес карты автоматически заполняется значением ${ingressgw.url}/имя брокера. При развертывании структурный нуль стоимостью ${ingressgw.url} автоматически заменяется URL-адресом шлюза Anypoint Flex, передающего запросы на вход агента.

Раздел спецификации настраивает «исходный код» брокера. Здесь разработчик может указать LLM для использования, инструкции, доступные инструменты, обработку ошибок и, самое главное, разные агенты и инструменты MCP, доступные этому брокеру.

Поставщики LLM

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

Брокеры могут указывать на поставщиков LLM. В зависимости от потребностей, мы можем выбрать модели этих поставщиков.

Инструкции

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

Обратите внимание, что нет необходимости предоставлять четкие инструкции (например, «разделить напоминание на задачи» или «выбрать лучший инструмент»), поскольку брокер справляется с этим самостоятельно. Эти инструкции необходимы только при описании определенных бизнес-процессов.

Конфигурация инструментов

Инструменты предоставляют агентам внешние возможности. Всякий раз, когда брокеру нужен доступ к внешней системе (то есть не другому агенту, например, существующему API или службе SaaS), он обращается к серверу MCP (Model Context Protocol):

На сервер MCP ссылается имя актива обмена. Сведения о подключении для него указаны в разделе услуг.

По умолчанию брокер имеет доступ ко всем инструментам, доступным на сервере MCP. По нашему наблюдению, самые современные LLM могут обрабатывать только около 20-25 инструментов на контекст, прежде чем начать генерировать неточности (или терять контекст). По этой причине обычно рекомендуется ограничить доступные инструменты нужным минимумом. Эту фильтрацию можно применить по спискам разрешенных.

Ссылки агента

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

Фактически, этот раздел определяет агентскую сеть для сотрудничества.

Управление агентами является важным компонентом для ткани агента, основным для создания надежной сети агентов и обеспечения безопасности и соответствия.

Для управления необходимо наличие двух Flex Gateway (1 вход и 1 выход) в личном пространстве.

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

  • Каталогизация:
    • Обмен: Поддерживает запись целей агента, ответственных, сред и границ данных и классификации. Он также регистрирует возможности, инструменты, ресурсы, напоминания и внешние зависимости с версиями.
  • Версия и жизненный цикл:
    • Документируйте и управляйте семантическими версиями агентов, инструментов и активов во время полного жизненного цикла разработки агентов.
    • Версия помогает управлять временными шкалами аннулирования агентов и поддерживает двойное выполнение (где возможно), обеспечивающее гладкие миграции.
  • Применение политики:
    • Архитектура Agentic AI расширяет поверхность атаки (интерфейс разговоров, напоминания и новые протоколы, например, MCP). Любой компромисс с любыми компонентами может привести к каскадным эффектам для нескольких систем, предоставляющих такие компоненты, как протокол, напоминание, API или инструмент.
    • Безопасность развертывания корпоративного агентского искусственного интеллекта требует специализированного подхода, поскольку эти автономные и непредсказуемые среды изначально расширяют поверхность атаки посредством взаимодействия между агентами. Хотя существующие инструменты безопасности для статических систем являются важными, сами по себе их уже недостаточно. Предприятия должны активно планировать и внедрять четыре конкретных решения в области безопасности, каждое из которых непосредственно касается критического бизнес-риска, связанного с агентским искусственным интеллектом.
    • Flex Gateway: Весь трафик A2A и MCP перенаправляется через Flex Gateway, даже если целевая система небезопасна, чтобы обеспечить применение политик к каждой конечной точке. Эта маршрутизация важна для безопасности коммуникаций агентов и интеграции с серверами авторизации.
    • Пакеты политик: Пользователи могут определить и применить пакеты предопределенных политик к бизнес-правилам перед выполнением, применив последовательный набор политик безопасности и операционной политики.
    • Типы полисов: Платформа поддерживает разные входящие и исходящие политики, включая:
      • Политики A2A: Карточка агента, детектор персональных данных, декоратор напоминаний, проверка схемы.
      • Политики MCP: Управление доступом на основе атрибутов, проверка схемы, поддержка MCP.
      • Политики LLM/AI: Декоратор подсказок на основе искусственного интеллекта, охрана подсказок на основе искусственного интеллекта (фильтрация вредоносного содержимого), шаблон подсказки на основе искусственного интеллекта (применение предопределенных шаблонов), ограничение базового уровня маркера на основе искусственного интеллекта.
      • Политики телеметрии: A2A и MCP Telemetry для расширения решений Open Telemetry для сбора и экспорта данных журнала.
  • Запись: Благодаря автоматическому отслеживанию, журналы в сети агентов доступны для отслеживания каждого взаимодействия агентов, объясняя алгоритмы и создавая Trust.

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

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

  • Базовые журналы и трассировки: Причины и отслеживание выполнения инструмента предоставляются посредством журналов. Журналы и трассировки из выполнения бизнес-правил доступны после выполнения в менеджере среды выполнения.
  • Показатели: На начальном этапе платформа публикует a2a_total_calls и mcp_total_calls в качестве счетчиков с метками (например, путь, статус, метод, инструмент) для определения общего количества, успешных и неудачных вызовов. Эти показатели публикуются из кода политики посредством собственного интерфейса статистики посланника (Flex Gateway), предпочтительно посредством существующих политик, например, mcp_support_policy и a2a_agent_card_policy.
  • Повышенная наблюдаемость (будущее): Планы включают использование открытой телеметрии для распределенной трассировки в будущих версиях. Более расширенные возможности наблюдения включают:
    • Подробное отслеживание запросов: Получение полного представления о запросах, включая напоминания, процессы планирования, вызванные действия и взаимодействия с подагентами.
    • Отслеживание состояния агента: Время работы агента мониторинга, задержка ответа, производительность, уровень ошибок и использование основных ресурсов (процессор, память, сеть, GPU).
    • Мультиагентный мониторинг координации: Сбор показателей успешности и неудачности взаимодействий между агентами, обнаружение схем круговых вызовов (циклов) и отслеживание показателей для каждого агента, например, выполнения задач и количества вызовов.
    • Отслеживание расходов: Отслеживание использования маркера и связанных расходов для каждого вызова LLM, в идеале на агента, с помощью панелей мониторинга и предупреждений.
    • Когнитивное отслеживание: Сбор и отображение подробного журнала сеанса агента, включительно с внутренними мыслительными процессами и всеми вызовами инструментов, служащими неизменным контрольным журналом.
    • Воспроизведение сеанса агента: Пользовательский интерфейс, позволяющий визуально «воспроизводить» когнитивную трассировку агента для глубокой отладки.
    • Визуализация DAG: Предоставление визуализации направленного циклического графика (DAG) выполнения бизнес-правил агента для сложных взаимодействий нескольких агентов.

Agent Visualizer используется для идентификации частей сети агентов и просмотра их совместной работы.

  • Различают типы узлов (агенты и серверы MCP).
  • Просмотрите края для просмотра заявленных взаимодействий и взаимодействий среды выполнения.
  • Использование слоев для фокуса представлений на определенных средах
  • Открытые карты сведений для проверки метаданных и показателей узлов и доступа к журналам и трассировкам
  • Просмотрите показатели управления, например, защиту Flex Gateway и применяемые политики.

Сведения о компонентах Agent Visualizer см. здесь.

Используя эти четыре компонента вместе, MuleSoft Agent Fabric расширяет безопасность и контроль для любого агента со встроенным управлением. Он позволяет агентам действовать в любом месте, используя новые протоколы, например, A2A (агент агенту) и MCP (типовой протокол контекста) для создания и расширения бизнес-процессов. Мы подключаем все - приложения, данные и системы - для расширения возможностей и управления агентами в процессе их работы в рамках всего предприятия. Интеллектуальное оборудование поддерживает создание и расширение бизнес-процессов или API посредством собственного использования искусственного интеллекта или использования сторонних инструментов искусственного интеллекта.

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

Диаграмма отображает взаимодействие всех четырех компонентов:

  1. Опубликуйте агентские активы в Anypoint Exchange для обнаружения и повторного использования после определения агентской сети (брокеры, агенты, серверы MCP) в агентской сети YAML в конструкторе кодов Anypoint.
  2. Разверните агентские активы в CloudHub 2.0 (управляется в менеджере среды выполнения).
  3. Внедрите политики входящего трафика в сеть посредством Flex Gateway входа, расположенного напротив конечных точек брокера и API.
  4. Внедряйте политики, управляйте подключениями и излучайте телеметрические данные посредством эгрессионного Flex Gateway. Этот шлюз находится на исходящих путях от брокеров и агентов к внешним службам.
  5. Собирайте журналы, показатели и трассировки из Flex Gateway и среды выполнения в Anypoint Monitoring.

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

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

Во-вторых, что особенно важно в контексте широкоязычных моделей (LLM), которые управляют этими агентами, иерархия значительно помогает держать размер контекста под контролем. Сегментируя ландшафт агента, агент брокера на любом заданном уровне учитывает только ограниченный набор агентов или субброкеров непосредственно под ним. Эта структура предотвращает загрузку описания, возможностей и архивного контекста каждого агента в его рабочую память, избегая риска быстрого превышения ограничений контекстного окна LLM и возникновения непомерно высоких расходов и задержек.

Сеть агентов может быть внедрена несколькими способами. Два из них:

  1. Закон Конвея - Интуитивный способ соотнесения его с реальной иерархической структурой.
  2. Дизайн под управлением домена - Больше внимания бизнес-доменам

Вариант 1: Соотнесение с реальной иерархической структурой

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

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

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

  • Концептуальная модель: Подобно тому, как корпорация имеет отдельные подразделения, отделы и уровни управления (например, C-suite, вице-президенты, директора, менеджеры), сеть агентов, действующая в определенном домене, может моделироваться как параллельная организационная схема.
  • Узлы и листья: В этой иерархии:
    • Листья древовидной структуры являются специальными агентами или МХП. Это функциональные единицы, выполняющие фактическую работу (например, «Агент запроса базы данных», «Агент проверки подлинности клиента», «Агент анализа мнений»). Они представляют отдельных соавторов или рабочие подразделения организации.
    • Все остальные узлы иерархии, включая корневой и промежуточный уровни, являются агентами брокера (или подорганизаторами). Эти агенты не выполняют конечную задачу, но отвечают за маршрутизацию, делегирование, агрегацию и решение конфликтов в пределах определенного домена или уровня. Высокопоставленный брокер делегирует задачу «Брокеру домена продаж», который, в свою очередь, делегирует «Брокеру управления возможностями», который выполняет задачу посредством «Агента обновления статуса возможности» (лист).

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

Рассмотрим аналогию организации-диаграммы для цифрового труда. Каждый файл YAML представляет каждую внутреннюю организацию (успех сотрудника, безопасность, финансы и т. д.). В каждой организации (агентской сети) может быть иерархическая структура, посредством которой участники сотрудничают, задания делятся на задачи и назначаются. На предыдущей диаграмме потоки связи отображаются сверху вниз. И листья не ограничены для потребления только набором агентов брокера.

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

Никхил Аггарвал является главным архитектором в Salesforce, где он возглавляет архитектуру MuleSoft и Salesforce Automation Cloud. Компания Nikhil обладает более чем 18-летним опытом производства масштабных продуктов и увлечена масштабируемой архитектурой, интуитивно понятным опытом разработчиков и созданием высокопроизводительных рабочих групп. До Salesforce он возглавлял несколько инициатив в Microsoft Power Platform, Dataverse и Office 365 от концепции до запуска. Его работа продолжает определять, как современные предприятия соединяют системы, автоматизируют бизнес-правила и разблокируют ценность бизнеса в эпоху искусственного интеллекта.

Мариано Гонсалес присоединился к MuleSoft в начале его существования в 2011 году, специализируясь на важных распределенных системах, интеграции, PaaS и облачных вычислениях. Сегодня Мариано фокусируется на продвижении платформ искусственного интеллекта, уделяя особое внимание управлению, оркестрации, открытиям и наблюдению. На протяжении более 20 лет в IT-индустрии Мариано работал архитектором программного обеспечения и руководителем рабочей группы, разрабатывая и предоставляя решения BPM, ERP и интеграции в секторах сельского хозяйства, энергетики, правительства, IT, телекоммуникаций и управления содержимым.

Педро Колунга является инженером-программистом в Salesforce, специализируется на архитектуре API и метаданных. Используя фокус на полном жизненном цикле платформы, Педро играет ключевую роль в определении способа взаимодействия организаций с системной аналитикой, семантикой и решениями на основе метаданных. 20-летняя карьера Педро, которая включает предпринимательский опыт, охватывает такие компании, как Fuego, BEA Systems, Oracle и TekGenesis, компания, позже приобретенная MuleSoft, где он последовательно управляет архитектурой платформы, предоставляя глубокий опыт в таких областях, как BPM, RAD и интеграции.

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