En el panorama de múltiples agentes en evolución, los agentes son más efectivos cuando se les asignan tareas granulares específicas. Esto requiere una red diversa de agentes especializados y reutilizables. Sin embargo, el reto principal es coordinar estos numerosos agentes heterogéneos, que pueden proceder de diversas fuentes, para colaborar eficazmente en la consecución de objetivos de negocio comunes. Sin una plataforma unificada, esta complejidad lleva 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 compañía holística. Esta falta de visibilidad impide 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 transparente de diversos agentes, independientemente de su origen. Establece mejores prácticas arquitectónicas y proporciona las herramientas necesarias para crear la Red de agentes. Una Red de agentes hace referencia a una recopilación coordinada de agentes de IA, herramientas y recursos que trabajan conjuntamente para ejecutar procesos de negocio complejos de múltiples pasos.

MuleSoft Agent Fabric es una plataforma unificada que proporciona a cada compañía una forma sencilla de descubrir, orquestar, gobernar y observar a cualquier agente independientemente de su ubicación.

Descubra: Registro de agentes proporciona un catálogo centralizado de todos los agentes y herramientas de IA en toda la organización. Permite el descubrimiento y la reutilización de 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.

Orquestar: MuleSoft Agent Broker es una solución de enrutamiento inteligente que compara dinámicamente tareas con el agente o la herramienta que mejor se ajuste. Con 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 de negocio se ejecutan con alta fiabilidad y resultados rastreables.

Gobierno: MuleSoft Agent Governance utiliza Flex Gateway y su compatibilidad con Model Context Protocol (MCP) y el protocolo Agent2Agent (A2A). Con Flex Gateway, las compañías 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 dinámico de interacciones de agentes. Realiza un seguimiento de decisiones, monitorea 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 de agente, incluyendo sus reglas y políticas operativas. El YAML se utiliza para activar los cuatro pilares Tela de agente:

1. Descubrir: Rellene el Registro de agentes con Activos de agente 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 en los activos para la seguridad y la gobernanza
4. Observe: Defina y reutilice conexiones con los activos definidos. Del mismo modo, las funciones de observabilidad y monitoreo están disponibles para redes de agentes.

La trayectoria del usuario comienza 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, permitiendo 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 tras la publicación de sus activos de red de agente.

El desarrollo de su Red de agentes sigue un ciclo de vida de desarrollo de software (SDLC) estándar que incluye 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 de proyecto Crear red de agentes
3. Edificio 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, déjelos 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 agente-red. 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 compañía. 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 está versionada y se puede compartir, permitiendo una adaptación rápida para funciones, regiones o filiales sin volver a construir flujos.
• Orquestar
  Un corredor de agentes utiliza un LLM para descomponer el proceso de realización de pedidos en una secuencia de tareas, como la verificación de detalles de clientes, la asignación de inventario y el cálculo de costos de envío. A continuación, ejecuta este flujo de trabajo llamando a agentes de MCP y A2A, garantizando que se solicitan aprobaciones actualizadas siempre que sea necesario.
• Gobierno
  Anypoint Flex Gateway aplica la autenticación, el acceso con menos privilegios y las barandillas. Las políticas del Gestor de API garantizan controles coherentes entre todas las llamadas e intercambios de datos.
• Observar
  El monitoreo 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 la seguridad, la privacidad y los requisitos normativos (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, la depuración y la gestión del ciclo de vida de agentes heterogéneos. Permite a los desarrolladores encontrar y reutilizar agentes, propietarios de plataforma 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 una 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).
• Detección:
  • 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 la búsqueda de lenguaje natural con Vibes en Anypoint Code Builder.
• Etiquetado y clasificación: Los activos se pueden clasificar por tipo (agente, MCP, LLM, corredor) y dominio (por ejemplo, RRHH, 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 en 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 se 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 compañía. Está definido 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 desempeño establecidas de CloudHub 2.0, incluyendo sus funciones de registro y mediciones. Los aspectos operativos, como "Costo para operar" y "Monitoreo/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 (A2A). 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}/nombre-corredor. 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 broker. Aquí, el desarrollador puede especificar el LLM a utilizar, las instrucciones, las herramientas disponibles, la gestión de errores y, lo que es más importante, los diversos agentes y herramientas MCP disponibles para este broker.

Proveedores de LLM

Esta sección forma parte de la especificación en 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 brokers, o si es necesario hacer que diferentes brokers utilicen el LLM que mejor se ajuste 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 broker. Estas instrucciones a menudo se centran en problemas específicos orientados a la actividad empresarial. Por ejemplo, imagine un Agente de servicio al cliente que coordina la gestión para incidentes reportados a clientes:

Tenga en cuenta 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 al describir procesos de negocio específicos.

Configuración de herramientas

Las herramientas proporcionan a los agentes funciones externas. Siempre que un broker necesita acceder a un sistema externo (que no sea otro agente, por ejemplo, una API existente o un servicio SaaS), hace contacto 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 gestionar entre 20 y 25 herramientas por contexto antes de empezar 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 agente

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 se apoya 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 gobernanza, se requiere un total de dos pasarelas Flex (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 clasificación y datos. 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 de desarrollo de agentes completo.
  • El versionado ayuda a gestionar las cronologías de desuso 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 pláticas, 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.
  • Asegurar implementaciones de IA de agentes de compañía 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 compañías deben planificar e implementar de forma proactiva cuatro soluciones de seguridad específicas, cada una directamente abordando un riesgo de negocio 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 las políticas se aplican 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 solicitud, 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 frecuencia de tokens básicos 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 fomentar 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 “especificaciones” en Pasarela Flex. 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 el monitoreo son fundamentales.

• Registros y trazas 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 el total, el éxito y el error de las llamadas. Estas mediciones se publican desde código de póliza utilizando la interfaz de estadísticas nativa 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 Open Telemetry 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.
  • Monitoreo de salud: de agentes Monitoreo del tiempo de disponibilidad de los agentes, la latencia de la respuesta, el rendimiento, los índices de error y la utilización de recursos subyacente (CPU, memoria, red, GPU).
  • Monitoreo de coordinación de múltiples agentes: Captura de índices de éxito y fallo de interacciones de agente a agente, detección de patrones de invocación circulares (bucles) y seguimiento de mediciones por agente como la realización de tareas y el conteo de invocaciones.
  • Seguimiento de costos: Seguimiento del uso de tokens y los costos asociados para cada llamada LLM, idealmente por agente, con tableros y alertas.
  • Rastreo cognitivo: Captura y visualización de un seguimiento detallado de la sesión de un agente, incluyendo procesos de pensamiento internos y todas las llamadas de herramientas, que sirve como un seguimiento 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 de múltiples agentes.

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 registros y rastreos de acceso
• Revise indicadores de gobernanza como protección de pasarela flexible y 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 gobernanza integrada. Permite a los agentes actuar en cualquier parte aprovechando nuevos protocolos como A2A (Agente a Agente) y MCP (Protocolo de contexto de modelo) para crear y ampliar los procesos de negocio. 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 de negocio 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 broker para orquestar agentes gobernados a través de otra plataforma.

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

1. Publique los activos de 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 de agente 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 Flex de entrada, que se encuentra frente a los extremos de broker y API.
4. Aplique políticas, gestione conexiones y emita datos de telemetría con una pasarela Flex 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 de broker 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, abogamos firmemente por un enfoque jerárquico multinivel 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 mejores prácticas 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 modelos de lenguaje grandes (LLM) que impulsan estos agentes, una jerarquía ayuda de forma espectacular a mantener los tamaños del contexto bajo control. Al segmentar el panorama de agentes, el agente de 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 costos y latencia prohibitivos.

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 de negocio

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

En una organización jerárquica, la comunicación fluye verticalmente (de los gerentes a los 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 tener capas y jerarquías 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 en 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", un "Agente de análisis de sentimientos"). Representan los colaboradores 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 en su dominio o capa específicos. Un broker de alto nivel delega una tarea a un "Sales Domain Broker", que a su vez delega a un "Opportunity Management Broker", que realiza la tarea a través de un "Opportunity Status Update Agent" (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 predecible y fiable. Puede presentar 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 broker.

El modelado de redes de agentes basadas en el organigrama humano conlleva el riesgo de requerir una re-arquitectura frecuente, particularmente en compañías que experimentan reorganizaciones 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 en 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 ampliable, las experiencias de desarrollador intuitivas y la creación de equipos de alto desempeño. 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 de negocio 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 y computación en nube. Hoy, Mariano se centra en el avance de las plataformas de IA, con especial atención a la gobernanza, la orquestación, el descubrimiento y la 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 en Salesforce, especializado en API y arquitectura de metadatos. 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 compañías como Fuego, BEA Systems, Oracle y TekGenesis, una compañía adquirida más tarde por MuleSoft, donde ha impulsado constantemente la arquitectura basada en plataforma, proporcionando una 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 avanzar en iniciativas de transformación de negocio, mejorando la seguridad y la resiliencia, promoviendo la excelencia de la arquitectura y liderando iniciativas de AIML entre varios dominios.