En el cambiante entorno de múltiples agentes, los agentes son más efectivos cuando se les asignan tareas específicas y granulares. Esto requiere una red diversa de agentes especializados y reutilizables. Sin embargo, el principal reto es coordinar estos numerosos agentes heterogéneos, que pueden proceder de diversas fuentes, para colaborar eficazmente en la consecución de objetivos comerciales comunes. Sin una plataforma unificada, esta complejidad conduce a la expansión de los agentes y una falta crítica de gobernanza.

Estos agentes de IA se están multiplicando rápidamente, integrados en plataformas SaaS, desarrollados internamente o empaquetados con LLM populares. Esta multiplicación da como resultado silos organizativos desconectados. Aunque un agente optimiza tareas en sus aplicaciones nativas, a menudo carece de una vista de empresa holística. Esta falta de visibilidad evita que los agentes orquesten, protejan y rijan de forma efectiva acciones entre diferentes dominios y sistemas.

MuleSoft Agent Fabric aborda el reto de gestionar la "extensión de agentes" y permitir la orquestación sencilla de diversos agentes, independientemente de su origen. Establece prácticas recomendadas de arquitectura y proporciona las herramientas necesarias para crear la Red de agentes. Una red de agentes hace referencia a una recopilación coordinada de agentes, herramientas y recursos de IA que trabajan conjuntamente para ejecutar procesos comerciales complejos de múltiples pasos.

MuleSoft Agent Fabric es una plataforma unificada que proporciona a cada empresa una forma sencilla de descubrir, orquestar, gobernar y observar a cualquier agente independientemente de dónde se haya creado.

Descubrir: Registro de agentes proporciona un catálogo centralizado de todos los agentes y herramientas de IA en toda la organización. Permite descubrir y reutilizar activos internos, integrados en SaaS y externos. Al proporcionar una única fuente de verdad para todos los activos de agentes, Registro de agentes elimina la redundancia y garantiza que los desarrolladores puedan aprovechar las funciones existentes a escala.

Orquesta: MuleSoft Agent Broker es una solución de enrutamiento inteligente que compara dinámicamente tareas con el agente o herramienta que mejor se ajuste. Con la tecnología de un LLM de su elección, se coordina entre agentes y herramientas para garantizar que las solicitudes de múltiples pasos complejas y los procesos comerciales se ejecuten con alta fiabilidad y resultados rastreables.

Gobierno: MuleSoft Agent Governance utiliza Flex Gateway y su compatibilidad con Model Context Protocol (MCP) y Agent2Agent (A2A) protocolo. Con Flex Gateway, las empresas pueden aplicar políticas de seguridad y cumplimiento a cada interacción agente-agente y agente-herramienta.

Observar: Visualizador de agentes proporciona observabilidad en tiempo real a través de un mapa interactivo y dinámico de interacciones de agentes. Realiza un seguimiento de decisiones, supervisa el estado del sistema, permitiendo así la optimización continua y la supervisión fiable de todo el ecosistema de agentes.

Agent Fabric defiende un enfoque de especificación primero (YAML) donde los usuarios definen redes de agentes a través de un descriptor de metadatos (el "archivo YAML"). Este archivo YAML es agnóstico para MuleSoft y desvincula la definición de la red de agentes de su ejecución.

Cada red de agentes (YAML) define un área funcional específica con sus activos agentes, incluyendo sus reglas y políticas operativas. YAML se utiliza para activar los cuatro pilares de Fabricación de agentes:

1. Descubrir: Rellene el Registro de agentes con activos agentes existentes como:
   1. Agentes implementados entre varias plataformas (MuleSoft u otras)
   2. Servidores MCP
   3. Proveedores de LLM
2. Orquestar: Crear corredores de agentes para orquestación
3. Gobernar: Aplicar políticas sobre los activos para la seguridad y la gobernanza
4. Observar: Defina y reutilice conexiones con los activos definidos. Además, las funciones de observabilidad y supervisión están disponibles para redes de agentes.

La trayectoria del usuario se inicia en Anypoint Code Builder. Utilice el nuevo comando disponible a través de la paleta de comandos denominada “MuleSoft: Crear un proyecto de red de agentes” para crear un nuevo proyecto. Este comando crea un nuevo proyecto (la "Red de agentes") que contiene dos archivos.

• agent-network.yaml: Este archivo define la configuración para el sistema de múltiples agentes, activando la orquestación de agentes de IA con herramientas externas (a través de MCP) y agentes (a través del protocolo A2A). Este formato proporciona una forma declarativa de definir funciones, dependencias e integraciones de agentes.

• exchange.json: Todos los proyectos de red de agentes también tienen un archivo exchange.json. Este archivo contiene metadatos de activos disponibles en Anypoint Exchange después de publicar sus activos de red de agentes.

El desarrollo de su red de agentes sigue un ciclo de vida de desarrollo de software (SDLC) estándar que implica cuatro etapas principales:

1. Configuración de entorno: Configurar pasarelas y entornos de tiempo de ejecución
2. Creación y diseño de proyectos: Especificación del proyecto Crear red de agentes
3. Construcción y publicación: Crear y publicar activos en el Registro de agentes
4. Implementación: Implementar o promocionar la red de agentes en un entorno concreto

Después de crear el proyecto y generar la aplicación y los activos de MuleSoft requeridos, hágalos disponibles en Exchange. Dentro del Generador de códigos Anypoint, desencadene el proceso de creación y publicación utilizando “MuleSoft: Comando Publicar proyecto de agente corredor en Exchange” disponible a través de la paleta de comandos.

El paso de publicación transforma cada activo agente en el archivo YAML en una especificación A2A, MCP o LLM y lo publica en Exchange.

Además, el sistema publica el YAML en Exchange utilizando un nuevo tipo de activo de red de agente. Puede ver este activo en la interfaz de usuario del Registro de agentes y buscarlo a través de la API de Exchange.

Consulte un archivo Red de agentes que define una red de agentes para una empresa. Esta red de agentes activa la red para la realización de pedidos en Salesforce, Stripe, otro agente de realización de pedidos y servidor MCP de inventario con una única experiencia gobernada por políticas.

• Descubrir
  Publique agentes y herramientas existentes (como Salesforce, Stripe, Realización de pedidos e Inventario) como activos de Exchange para su reutilización. También la definición de realización de pedidos (YAML) que es versionada y compartible, permitiendo una adaptación rápida para funciones, regiones o filiales sin reconstruir flujos.
• Orquestar
  Un corredor de agentes utiliza un LLM para descomponer el proceso de realización de pedidos en una secuencia de tareas, como verificar detalles del cliente, asignar inventario y calcular costes de envío. A continuación ejecuta este flujo de trabajo llamando a agentes de MCP y A2A, garantizando que se soliciten aprobaciones de persona al día siempre que sea necesario.
• Gobernar
  Anypoint Flex Gateway aplica la autenticación, el acceso con menos privilegios y las barandillas. Las políticas de API Manager garantizan controles coherentes en todas las llamadas e intercambios de datos.
• Observar
  La supervisión y los rastreos proporcionan visibilidad integral del progreso, los fallos y la latencia. La visualización muestra qué agentes interactuaron y dónde se produjeron cuellos de botella.
• Confianza y cumplimiento
  Las credenciales centralizadas, los seguimientos de auditoría y la herencia de pólizas admiten requisitos de seguridad, privacidad y regulación (gestión de PII, aprobaciones y separación de funciones).

El diagrama muestra los diferentes nodos de la Red de agentes (metadatos) definidos en YAML.

• Objetivo: Exchange es el catálogo de agentes, herramientas y otros activos. Su objetivo principal es resolver la "extensión de agentes" proporcionando un catálogo único gobernado para el descubrimiento, depuración y gestión del ciclo de vida de agentes heterogéneos. Permite a los desarrolladores encontrar y reutilizar agentes, propietarios de plataformas para mantener la visibilidad y orquestadores para descubrir funciones.
• Heterogéneo por diseño: Anypoint Exchange ahora admite tres nuevos activos: Agentes, MCP y LLM. Exchange está diseñado para ser un catálogo universal, para registrar y gestionar cualquier tipo de agente. Admite agentes que cumplen con A2A, servidores MCP y proveedores LLM de cualquier origen, incluyendo agentes externos, Agentforce y MuleSoft personalizados.
• Metadatos principales: Cada activo registrado tiene un conjunto de línea base de metadatos inmutables, incluyendo un Nombre y versión exclusivos, Propiedad y Publicador. También se realiza un seguimiento de los estados del ciclo de vida (desarrollo, organización, producción, desusado).
• Discovery:
  • Tiempo de diseño: Los desarrolladores pueden descubrir agentes registrados a través de la interfaz de usuario de Exchange existente o a través de búsqueda de lenguaje natural con Vibes dentro del Generador de códigos de Anypoint.
• Etiquetado y clasificación: Los activos se pueden clasificar por tipo (agente, MCP, LLM, corredor) y dominio (por ejemplo, RR. HH., clima) utilizando un sistema de etiquetado de valores clave básico, lo que permite políticas de vinculación, búsqueda y selección dinámicas.
• Catálogo: El repositorio admite modelos de catálogo privados e internos para compartir agentes dentro de una organización.
• Visualización: Proporciona una herramienta visual para admitir vistas de red, mostrando conexiones para activos únicos o el mapa completo de nodos y vínculos en toda la organización, con funciones de filtrado.

Los corredores en una red de agentes pueden hacer referencia a agentes registrados, servidores MCP y proveedores LLM almacenados en Anypoint Exchange. Pero si aún no están registrados, se pueden declarar en los metadatos de Red de agentes (YAML) y se registran automáticamente. En el ejemplo, múltiples agentes, servidores MCP y proveedores LLM se declaran y registran en Anypoint Exchange.

Un corredor de agentes es un agente de enrutamiento inteligente que coordina la delegación de tareas entre agentes especializados en una empresa. Se define por los agentes y servidores MCP que utiliza para realizar tareas.

Un corredor es un agente especializado que aparece en Anypoint Exchange después de publicar un activo de red de agente y reutilizarlo por otros corredores.

Los corredores se definen en la sección de corredores del YAML. Los brokers definidos se “compilan” de forma transparente en una aplicación, sin requerir ningún Knowledge previo sobre Mule. Esta aplicación generada se implementa en CloudHub 2.0 (CH2) y aprovecha la sólida infraestructura de CH2.

Esto significa que los Agent Brokers se benefician de las características de rendimiento establecidas de CloudHub 2.0, incluyendo sus funciones de registro y mediciones. Los aspectos operativos, como "Coste de operación" y "Supervisión/Alerta/Herramientas", son los mismos que cualquier otra carga de trabajo.

Para escenarios que requieren intervención humana (Human-in-the-Loop), el estado de cada interacción se mantiene utilizando MuleSoft Object Store, una solución distribuida diseñada para una gestión de estado efectiva en entornos altamente simultáneos.

Una definición de broker se compone de dos secciones: tarjeta y especificación.

La sección de tarjeta sigue la especificación Agente a agente. Entre otras cosas, describe el contrato, las habilidades y las funciones del agente de corretaje. La URL de la tarjeta se rellena automáticamente con el valor ${ingressgw.url} / broker-name. Tras la implementación, el marcador de posición ${ingressgw.url} se sustituye automáticamente por la URL de la pasarela Anypoint Flex que está frente a las solicitudes de ingreso de agentes.

La sección de especificación configura el “código fuente” del corredor. Aquí, el desarrollador puede especificar el LLM a utilizar, las instrucciones, las herramientas disponibles, la gestión de errores y, lo más importante, los diversos agentes y herramientas de MCP disponibles para este corredor.

Proveedores de LLM

Esta sección forma parte de la especificación de cada corredor. Esta es una referencia a uno de los LLM definidos en la sección de servicios. Podemos elegir si compartir un LLM entre todos los corredores o, si es necesario, hacer que diferentes corredores utilicen el LLM que mejor se adapte a sus tareas.

Los corredores pueden apuntar a proveedores de LLM. Podemos elegir modelos de estos proveedores dependiendo de nuestras necesidades.

Instrucciones

Esta sección es opcional y puede utilizarla para especificar instrucciones específicas para este agente de corredor. Estas instrucciones a menudo se centran en problemas específicos orientados a la empresa. Por ejemplo, imagine un Agente de servicio al cliente que coordina la gestión de incidentes reportados a clientes:

Observe que no es necesario proporcionar instrucciones explícitas, como "dividir la solicitud en tareas" o "seleccionar la mejor herramienta", ya que el corredor gestiona eso por sí mismo. Estas instrucciones solo son necesarias cuando se describen procesos comerciales específicos.

Configuración de herramientas

Las herramientas proporcionan a los agentes funciones externas. Siempre que un corredor necesita acceder a un sistema externo (que no es otro agente, por ejemplo, una API existente o un servicio SaaS), se comunica con un servidor MCP (Protocolo de contexto de modelo):

Se hace referencia al servidor MCP con el nombre del activo de intercambio. Los detalles de conectividad para él se especifican en la sección de servicios.

De forma predeterminada, el corredor tiene acceso a todas las herramientas disponibles en el servidor MCP. Según nuestra observación, los LLM más modernos solo pueden manejar alrededor de 20 a 25 herramientas por contexto antes de comenzar a generar imprecisiones (o perder contexto). Por este motivo, es generalmente una buena práctica limitar las herramientas disponibles al mínimo necesario. Puede aplicar ese filtrado a través de las listas permitidas.

Vínculos de agentes

Esta sección es la parte más importante de toda la definición. La sección de vínculos activa la comunicación y orquestación entre agentes. Eso significa que este corredor confía en los agentes vinculados aquí para ejecutar las acciones apropiadas para completar el objetivo del usuario.

En efecto, esta sección define una red de agentes para la colaboración.

La gobernanza de agentes es un pilar crítico para el tejido de agentes, fundamental para crear una red de agentes de confianza y garantizar la seguridad y el cumplimiento.

Para la regulación, se requiere un total de dos pasarelas flexibles (1 entrada y 1 salida) en su espacio privado.

La gobernanza establece las estructuras, los controles y la evidencia necesarios para ampliar de forma segura todo el ciclo de vida de desarrollo de agentes (ADLC). Específicamente, la gobernanza implementa procesos clave como la certificación de agentes, la catalogación, las decisiones del ciclo de vida y la aplicación de políticas de tiempo de ejecución.

• Catálogo:
  • Intercambio: Admite el registro de fines de agentes, propietarios, entornos y límites de datos y clasificación. También registra funciones, herramientas, recursos, solicitudes y dependencias externas con versiones.
• Versión y ciclo de vida:
  • Documente y gestione versiones semánticas de agentes, herramientas y activos durante el ciclo de vida completo de Desarrollo de agentes.
  • La versión ayuda a gestionar las cronologías de desaprobación de agentes y admite la doble ejecución (donde sea posible) garantizando migraciones sin problemas.
• Aplicación de políticas:
  • La arquitectura de IA agente amplía la superficie de ataque (interfaz de conversaciones, solicitudes y nuevos protocolos como MCP). Cualquier compromiso en cualquier componente puede llevar a efectos en cascada en múltiples sistemas que proporcionan componentes como protocolo, solicitud, API o herramienta.
  • Garantizar implementaciones de IA de agentes comerciales requiere un enfoque especializado, ya que estos entornos autónomos e impredecibles amplían de forma inherente la superficie de ataque a través de interacciones de agente a agente. Aunque las herramientas de seguridad existentes para sistemas estáticos son esenciales, ya no son suficientes por sí solas. Las empresas deben planificar e implementar de forma proactiva cuatro soluciones de seguridad específicas, cada una directamente abordando un riesgo comercial crítico asociado con la IA de agentes.
  • Flex Gateway: Todo el tráfico A2A y MCP se enruta a través de Flex Gateway, incluso si el sistema de destino no es seguro, para garantizar que se aplican políticas en cada extremo. Este enrutamiento es crucial para proteger las comunicaciones de los agentes e integrar con los servidores de autorización.
  • Paquetes de pólizas: Los usuarios pueden definir y aplicar paquetes de políticas predefinidas a flujos de trabajo antes de la ejecución, aplicando un conjunto coherente de políticas operativas y de seguridad.
  • Tipos de pólizas: La plataforma admite varias políticas entrantes y salientes, incluyendo:
    • Políticas de A2A: Tarjeta de agente, Detector de PII, Decorador de solicitudes, Validación de esquema.
    • Políticas de MCP: Control de acceso basado en atributos, Validación de esquema, Compatibilidad con MCP.
    • Políticas de LLM/IA: Decorador de solicitudes de IA, Protección de solicitudes de IA (filtrado de contenido dañino), Plantilla de solicitud de IA (aplicación de plantillas predefinidas), Limitación de la velocidad de tokens básica de IA.
    • Políticas de telemetría: Telemetría A2A y MCP para ampliar las soluciones de telemetría abierta para la recopilación y exportación de datos de registro.
• Registro: Gracias al rastreo automático, los registros en la Red de agentes están disponibles para realizar un seguimiento de cada interacción de agentes, explicar comportamientos y generar Trust.

El ejemplo representa una política para el registro de mensajes, que se configura utilizando los metadatos de red de agentes. El corredor de Orderfullfillment hace referencia a un agente existente denominado agente de Salesforce y la política para la mensajería se configura utilizando los metadatos. Tenga en cuenta que Tela de agente configura automáticamente todas las políticas mencionadas bajo la sección “spec” en Pasarela flexible. No requiere pasos adicionales.

Dada la naturaleza no determinista y la complejidad de los agentes de LLM y las implementaciones de múltiples agentes, la observabilidad y la supervisión son fundamentales.

• Registros y rastreos básicos: El razonamiento y el rastreo de ejecución de herramientas se proporcionan a través de registros. Los registros y rastreos de ejecuciones de flujos de trabajo son visibles después de la ejecución en Gestor de tiempo de ejecución.
• Métricas: En la fase inicial, la plataforma publica a2a_total_calls y mcp_total_calls como contadores con etiquetas (como, ruta, estado, método, herramienta) para determinar llamadas totales, correctas y fallidas. Estas mediciones se publican desde código de política utilizando la interfaz de estadísticas nativas de Envoy (Puerta de enlace Flex), preferiblemente a través de políticas existentes como mcp_support_policy y a2a_agent_card_policy.
• Observabilidad mejorada (futura): Los planes incluyen el uso de telemetría abierta para el rastreo distribuido en versiones futuras. La observabilidad más avanzada incluye:
  • Rastreo de solicitudes detallado: Obtener visibilidad integral de solicitudes, incluyendo solicitudes, procesos de planificación, acciones invocadas e interacciones con subagentes.
  • Supervisión de salud: de agentes Supervisión del tiempo de disponibilidad de los agentes, la latencia de la respuesta, el rendimiento, los índices de error y la utilización subyacente de los recursos (CPU, memoria, red, GPU).
  • Supervisión de coordinación de múltiples agentes: Capturar índices de éxito y fracaso de interacciones de agente a agente, detectar patrones de invocación circulares (bucles) y realizar un seguimiento de mediciones por agente como la finalización de tareas y el recuento de invocaciones.
  • Seguimiento de costes: Realizar un seguimiento del uso de tokens y los costes asociados para cada llamada LLM, idealmente por agente, con paneles y alertas.
  • Rastreo cognitivo: Captura y visualización de un rastreo detallado de la sesión de un agente, incluyendo procesos de pensamiento internos y todas las llamadas de herramientas, que sirven como un rastreo de auditoría inmutable.
  • Reproducción de sesión de agente: Una interfaz de usuario que permite "reproducir" visualmente el rastreo cognitivo de un agente paso a paso para una depuración profunda.
  • Visualización de DAG: Proporcionar una visualización de gráfico acíclico dirigido (DAG) de la ejecución del flujo de trabajo de agentes para interacciones complejas con múltiples agentes.

El Visualizador de agentes se utiliza para identificar las partes de su red de agentes y ver cómo funcionan juntas.

• Distinga los tipos de nodos (agentes y servidores MCP).
• Vea los bordes para ver interacciones declaradas y en tiempo de ejecución.
• Utilizar capas para centrar vistas en entornos específicos
• Tarjetas de detalles abiertas para inspeccionar metadatos y mediciones para nodos y acceder a registros y rastreos
• Revise indicadores de gobernanza como la protección Flex Gateway y las políticas aplicadas.

Encuentre detalles sobre los componentes de Visualizador de agentes aquí.

Con estos cuatro pilares juntos, MuleSoft Agent Fabric amplía la seguridad y el control a cualquier agente con regulación integrada. Permite a los agentes actuar en cualquier lugar aprovechando nuevos protocolos como A2A (Agente a agente) y MCP (Protocolo de contexto de modelo) para crear y ampliar los procesos comerciales. Conectamos todo (aplicaciones, datos y sistemas) para potenciar y gobernar a los agentes cuando actúan en todo el negocio. Las herramientas inteligentes admiten la creación y ampliación de procesos comerciales o API utilizando IA de forma nativa o aportando herramientas de IA externas.

No se requiere el uso de los cuatro pilares juntos, pero se recomienda. Puede elegir pilares de forma independiente según sea necesario. Por ejemplo, puede aprovechar Tela de agente para el registro y la gobernanza, sin utilizar la capa de orquestación. Del mismo modo, puede utilizar el corredor para orquestar agentes que se rigen a través de otra plataforma.

El diagrama muestra cómo interactúan los cuatro componentes entre sí:

1. Publique los activos agentes en Anypoint Exchange para su descubrimiento y reutilización después de definir la red de agentes (corredores, agentes, servidores MCP) en la red de agentes YAML en Anypoint Code Builder.
2. Implemente los activos agentes en CloudHub 2.0 (gestionado en Gestor de tiempo de ejecución).
3. Aplique políticas sobre el tráfico entrante a la red con una Pasarela flexible de entrada, que se encuentra frente a los extremos de corredores y API.
4. Aplique políticas, gestione conexiones y emita datos de telemetría con una pasarela flexible de salida. Esta pasarela se encuentra en rutas salientes desde corredores y agentes a servicios externos.
5. Recopile registros, mediciones y rastreos desde Flex Gateway y tiempos de ejecución en Anypoint Monitoring.

Es tentador hacer que cada agente especializado sea accesible de inmediato en una arquitectura plana y sin restricciones, con un único orquestador capaz de abordar cualquier tarea teniendo acceso a cada activo de IA disponible. Sin embargo, este enfoque resulta rápidamente perjudicial para la eficiencia y fiabilidad generales del sistema. Al igual que el principio aplicado a un exceso de herramientas individuales, muchas opciones de agentes introducen ruido y complejidad significativos para el agente de corredor central (u orquestador). Esta complejidad aumentada conduce directamente a una caída notable tanto en la precisión de la toma de decisiones del corredor (seleccionando el agente correcto para el trabajo) como en el determinismo de la respuesta del sistema (resultados predecibles y coherentes para consultas similares). El agente corredor sufre efectivamente de parálisis de opciones, lo que lleva a un enrutamiento más lento y menos fiable.

En vez de una estructura plana, defendemos firmemente un enfoque jerárquico de múltiples niveles para estructurar la Red de agentes. Este principio organizativo ofrece numerosas ventajas críticas. En primer lugar, favorece inherentemente la trazabilidad y gestión. Una estructura jerárquica refleja las prácticas recomendadas organizativas establecidas, facilitando la auditoría del flujo de una solicitud, la depuración de problemas precisando la capa de fallo y la gestión de la implementación y retirada de agentes o subredes específicos.

En segundo lugar, y de forma crucial en el contexto de los modelos de lenguaje grandes (LLM) que impulsan estos agentes, una jerarquía ayuda de forma espectacular a mantener controlados los tamaños de contexto. Al segmentar el panorama de agentes, el agente corredor en cualquier capa determinada solo tiene en cuenta el conjunto limitado de agentes o subcorredores directamente debajo de él. Esta estructura evita que el orquestador principal cargue la descripción, las funciones y el contexto histórico de cada agente en su memoria de trabajo, evitando el riesgo de superar rápidamente los límites de plazo de contexto del LLM y suponiendo costes prohibitivos y latencia.

La red de agentes puede implementarse de múltiples formas. Dos de ellos son:

1. Ley de Conway: forma intuitiva de asignarla a la estructura jerárquica del mundo real.
2. Diseño dirigido por dominios - Más centrado en dominios comerciales

Opción 1: Asignación con estructura jerárquica del mundo real

En una organización jerárquica, la comunicación fluye verticalmente -desde gerentes a subordinados- y las decisiones a menudo están centralizadas. Según la ley de Conway:

• Los sistemas o las arquitecturas de software creados por dichas organizaciones tienden a ser estratificados y jerárquicos también.
• Cada equipo tiende a diseñar subsistemas que reflejan sus propios límites y autoridades.
• Las interfaces entre sistemas reflejan los canales de comunicación entre los departamentos.

La Red de agentes también se puede asignar de forma intuitiva a la estructura jerárquica real de una gran empresa siguiendo la Ley de Conway.

• El modelo conceptual: Del mismo modo que una corporación tiene divisiones, departamentos y capas de gestión diferentes (por ejemplo, C-suite, vicepresidentes, directores, gerentes), una red de agentes que opera dentro de un dominio específico puede modelarse como un organigrama paralelo.
• Los nodos y las hojas: En esta jerarquía:
  • Las Hojas de la estructura del árbol son los Agentes Especializados o MCP. Son las unidades funcionales que realizan el trabajo real (por ejemplo, un "Agente de consulta de base de datos", un "Agente de autenticación de clientes" y un "Agente de análisis de sentimientos"). Representan a los contribuyentes individuales o las unidades de trabajo de la organización.
  • Todos los demás nodos de la jerarquía, incluidas las capas raíz e intermedia, son agentes corredores (o suborquestadores). Estos agentes no realizan la tarea final pero son responsables del enrutamiento, la delegación, la agregación y la resolución de conflictos dentro de su dominio o capa específicos. Un corredor de alto nivel delega una tarea a un "corredor de dominios de ventas", que a su vez delega a un "corredor de gestión de oportunidades", que realiza la tarea a través de un "agente de actualización de estado de oportunidad" (la hoja).

Esta estructura garantiza que la complejidad se gestione localmente, que el contexto esté contenido y que el sistema se amplíe de forma previsible y fiable. Puede introducir nuevos agentes especializados en ramas específicas y apropiadas del árbol organizativo.

Considere la analogía de un gráfico de organización para trabajo digital. Cada archivo YAML representa cada una de las organizaciones internas (Éxito de empleados, Seguridad, Finanzas, etc.). Dentro de cada organización (agente-red) puede tener una estructura jerárquica a través de la cual los actores colaboran, los trabajos se dividen en tareas y se asignan. En el diagrama anterior, la comunicación fluye de arriba a abajo. Además, las hojas no están restringidas para el consumo solo por un conjunto de agentes de corredor.

El modelado de redes de agentes basadas en el organigrama humano conlleva el riesgo de requerir re-arquitectos frecuentes, particularmente en empresas que experimentan re-organizaciones frecuentes. Un enfoque alternativo es organizar agentes por dominio funcional. Esta agrupación puede requerir cruzar los límites organizativos humanos tradicionales. Por ejemplo, la incorporación de nuevos empleados implica operaciones de TI para el aprovisionamiento de hardware y usuarios, mientras que una moción de ventas requiere operaciones y marketing.

Nikhil Aggarwal es Arquitecto Principal de Salesforce, donde lidera la arquitectura para MuleSoft y Salesforce Automation Cloud. Nikhil aporta más de 18 años de experiencia entregando productos a gran escala y es un apasionado de la arquitectura escalable, las experiencias de desarrollador intuitivas y la creación de equipos de alto rendimiento. Antes de Salesforce, dirigió múltiples iniciativas en Microsoft Power Platform, Dataverse y Office 365 desde el concepto hasta el lanzamiento. Su trabajo continúa dando forma a cómo las empresas modernas conectan sistemas, automatizan flujos de trabajo y desbloquean valor comercial en la primera era de la IA.

Mariano González se unió a MuleSoft en sus primeros días en 2011, especializándose en sistemas distribuidos de misión crítica, integración, PaaS e informática en nube. Hoy, Mariano se centra en el avance de las plataformas de IA, con especial atención a la gobernanza, orquestación, descubrimiento y observabilidad. Con más de 20 años en la industria de TI, Mariano se ha desempeñado como arquitecto de software y líder de equipo, diseñando y entregando soluciones de BPM, ERP e integración en los sectores de agricultura, energía, gobierno, TI, telecomunicaciones y gestión de contenidos.

Pedro Colunga es arquitecto ingeniero de software de Salesforce, especializado en arquitectura de metadatos y API. Con un enfoque en el ciclo de vida completo de la plataforma, Pedro desempeña un papel clave en la configuración de cómo interactúan las organizaciones con la inteligencia del sistema, la semántica y las soluciones dirigidas por metadatos. La carrera de 20 años de Pedro, que incluye experiencia empresarial, abarca empresas como Fuego, BEA Systems, Oracle y TekGenesis, una empresa adquirida más tarde por MuleSoft, donde ha impulsado constantemente la arquitectura basada en plataforma, proporcionando profunda experiencia en áreas como BPM, RAD e Integraciones.

Gulal Kumar es Arquitecto de Ingeniería de Software en Salesforce, con un enfoque en datos y arquitectura de integración. Con más de 20 años de experiencia en integración y API, programas de modernización, seguridad e iniciativas AIML, aporta una gran experiencia. Gulal se ha comprometido a impulsar iniciativas de transformación comercial, mejorar la seguridad y la resiliencia, promover la excelencia de la arquitectura y liderar iniciativas de AIML en varios dominios.