Construcción de un sistema de respuesta a incidentes multiagente en AGNTCY

Hoy en día es fácil construir y desplegar un agente individual. Equipos de todos los tamaños lo están haciendo, y muchos ya ejecutan flujos de trabajo multi-agente encadenando varios agentes para llevar a cabo una tarea más amplia. El problema surge cuando se incorpora un nuevo agente: el flujo de trabajo debe editarse para integrarlo. A pequeña escala, esto es una molestia. A escala empresarial, generalmente requiere que los equipos acuerden una pila tecnológica común y una plataforma de despliegue, consensúen un formato de mensaje estándar para los agentes, y enruten cada nuevo agente a través de un cambio de código en el flujo de trabajo antes de que se pueda generar cualquier valor de negocio. Este es el conjunto de restricciones equivocado para imponer a los equipos.

La restricción correcta es la forma del mensaje. El protocolo Agent2Agent (A2A) ofrece a las organizaciones exactamente eso: un sobre común a través del cual los agentes pueden comunicarse, independientemente de la pila tecnológica o el despliegue. A partir de ahí, los agentes pueden comenzar a comunicarse entre sí utilizando una forma de mensaje acordada, y cada agente puede construirse con una pila tecnológica, lenguaje y framework completamente diferentes, y desplegarse en cualquier lugar de la organización.

Sin embargo, una forma de mensajería estándar con A2A es solo el punto de partida. Aún quedan muchas preguntas por responder, como:

• ¿Cómo pueden los agentes descubrirse dinámicamente entre sí?
• ¿Cómo se realiza la comunicación entre agentes de forma segura y controlada?
• ¿Cómo podemos observar las acciones que tienen lugar en el sistema multi-agente?
• ¿Cómo pueden los agentes demostrar su identidad entre sí a través de los límites organizacionales?

El proyecto AGNTCY propone respuestas a estas preguntas, y a continuación lo ponemos a prueba.

Construimos una Sala de Respuesta a Incidentes con cinco agentes que realiza análisis de causa raíz de incidentes de TI en un entorno empresarial simulado. Un Orquestador de Incidentes recibe una alerta, ya sea de un humano que activa un panel de control o de un sistema de monitoreo upstream, y se comporta como un ingeniero de guardia experimentado. Razona sobre dónde buscar. Consulta a especialistas. Correlaciona hallazgos, formula preguntas de seguimiento y sintetiza una conclusión.

Los agentes que construimos para nuestra Sala de Respuesta a Incidentes, con el Agente de Kubernetes incorporándose dinámicamente a la investigación

Tres agentes especialistas principales están conectados desde el inicio. Un Agente de Análisis de Registros identifica patrones de error y tiempos de inicio. Un Agente de Análisis de Cambios revisa los registros de cambios del sistema ITSM, compara despliegues sospechosos y correlaciona los cambios con la línea de tiempo del incidente. Un Agente de Conocimiento de TI respalda sus respuestas con un grafo Neo4j en tiempo real que ofrece una visión clara de los servicios desplegados, los equipos y las relaciones de dependencia, brindando al agente la mejor perspectiva posible sobre los servicios afectados y el radio de impacto.

En nuestra prueba, el sistema encontró la causa raíz: el registro de cambio CHG-2847 había reducido un tiempo de espera de conexión de 30 segundos a 3, provocando fallos en cascada. Reportó el hallazgo con un 95% de confianza, acompañado de una línea de tiempo completa, la lista de servicios afectados, citas de evidencia contra los sistemas fuente y un conjunto de pasos de remediación. El informe se entrega como salida tipada estructurada y se canaliza hacia un panel de operador humano. Agregar un paso de intervención humana donde un ingeniero aprueba la remediación sugerida y el agente aplica el cambio es una extensión natural; la salida estructurada está diseñada para soportarlo.

Esta investigación puede, por supuesto, resolverse mediante un único agente o un equipo de agentes que ejecutan un flujo de trabajo estático. Eso no es lo interesante. Lo interesante es cómo agentes independientes —pertenecientes a diferentes equipos, construidos sobre diferentes tecnologías, desplegados en infraestructuras distintas— se compusieron en tiempo de ejecución para lograrlo.

El componente que permite la composición de equipos multiagente es el Servicio de Directorio de Agentes (ADS) de AGNTCY. ADS es federado en lugar de centralizado: cada organización gestiona su propio directorio, y los directorios se interconectan a través de un protocolo de enrutamiento de contenido para formar lo que AGNTCY denomina el inventario de Internet de Agentes. Cada agente que una organización despliega se registra como un registro en el Open Agentic Schema Framework (OASF), un esquema extensible y versionado que captura las habilidades, el dominio, las características y las señales de evaluación del agente. El descubrimiento está basado en habilidades. OASF define una Taxonomía jerárquica de Habilidades de Agentes de IA, y los agentes consultan ADS por capacidad en lugar de por nombre.

En nuestra ejecución, el Orquestador de Incidentes contaba inicialmente con tres especialistas realizando la investigación inicial. Tras la primera ronda de correlación, determinó que el servicio afectado estaba desplegado en Kubernetes. El Orquestador de Incidentes emitió una consulta basada en habilidades contra ADS, obtuvo un Agente de Kubernetes como respuesta e incorporó al agente a la investigación como cuarto especialista. Ningún archivo de flujo de trabajo hacía referencia a ese agente. Nadie actualizó la configuración para que esto funcionara. La investigación se compuso a sí misma en tiempo de ejecución, en función de lo que el problema realmente requería.

Cada agente del sistema tiene una identidad de carga de trabajo, una identidad criptográfica emitida al inicio derivada del entorno en el que se ejecuta el agente, en lugar de un secreto que este lleva consigo. La implementación utiliza SPIFFE, un marco para identificar y proteger las comunicaciones entre servicios. Un servidor SPIRE actúa como autoridad de certificación, firmando identidades de corta duración (SVIDs), y un agente SPIRE en cada nodo realiza la atestación de carga de trabajo —una serie de verificaciones del entorno de la carga de trabajo— antes de entregarle un SVID. En la práctica, esto significa que ningún agente puede suplantar a otro presentando un encabezado HTTP o un token robado de un archivo de configuración.

Una vez que un agente ha obtenido su identidad de carga de trabajo, lo que se le permite hacer —por ejemplo, qué herramientas puede invocar y con qué otros agentes puede comunicarse— puede gestionarse desde un sistema IAM centralizado, en lugar de estar codificado de forma fija dentro de las imágenes de los agentes. Los equipos de seguridad redactan las políticas. Los equipos de aplicaciones construyen los agentes.

El punto de aplicación en este sistema es la capa de transporte SLIM de AGNTCY (Mensajería Interactiva Segura de Baja Latencia). SLIM reemplaza el HTTP directo entre agentes con una capa de mensajería autenticada. No existe un socket de un agente a otro. Cada mensaje viaja por un canal autenticado; la identidad se verifica por mensaje desde el emisor atestado por SPIFFE antes de que el mensaje llegue al destino.

El Control de Acceso Basado en Tareas (TBAC) aplica una política que regula el uso de herramientas por parte de los agentes. Cuando el Orquestador solicitó al Agente de Análisis de Cambios que utilizara su herramienta rollback_change, TBAC lo denegó, lo registró y mostró el evento de denegación en el panel de Respuesta a Incidentes en tiempo real. El modelo del Agente de Análisis de Cambios nunca tuvo la oportunidad de invocar la herramienta. La llamada fue rechazada en la capa de transporte antes de que el código del agente de destino llegara a ejecutarse.

La razón por la que TBAC importa más que la autorización por llamada es que autorizar la invocación de una herramienta en un sistema multiagente no es una cuestión de llamada única. Es una cuestión de cadena de identidad. El dato relevante para la decisión de política es la secuencia completa de identidades de agentes y mensajes que condujeron a la llamada: quién la inició, quién la retransmitió, con qué contexto, sobre qué herramienta y con qué parámetros. Esa es la capa en la que los equipos de seguridad aprobarán (o no) los sistemas multiagente en la fase de adquisición, y es la capa en la que la mayoría de los equipos no ha realizado ningún trabajo.

Visualización del descubrimiento en tiempo de ejecución con el Servicio de Directorio de Agentes y el envío de mensajes A2A a través de la capa de mensajería segura SLIM

Transmitimos cada verificación de identidad, decisión de política, llamada a herramienta y hallazgo del agente a un panel en vivo a través de WebSocket. Un operador humano puede observar el desarrollo de la investigación en tiempo real, correlacionar cualquier decisión con la identidad que la tomó e intervenir. El mismo flujo de eventos constituye el registro de auditoría.

La versión más compleja del problema es lo que ocurre cuando no se poseen todos los agentes del sistema. Aun así, se necesita visibilidad sobre el alcance completo de lo sucedido, en qué orden y por qué, tanto para operar el sistema como para evaluar y mejorar los agentes con el tiempo. El SDK de Observabilidad de AGNTCY aborda esto instrumentando tanto a los propios agentes como a los protocolos entre ellos, SLIM y A2A. La telemetría que emite es compatible con OTel y admite la recomposición de trazas entre los límites de los agentes, de modo que una sola investigación produce una única traza incluso cuando sus especialistas fueron creados, desplegados y operados por equipos distintos.

El IAM empresarial existente te lleva la mayor parte del camino en identidad. SPIFFE/SPIRE es un framework que lleva años funcionando en producción para microservicios, y funcionó para agentes sin modificaciones. Si tu equipo de plataforma ya ejecuta SPIRE, o tiene alguna estrategia de identidad de cargas de trabajo implementada, no necesitas una nueva infraestructura de identidad para comenzar a asegurar sistemas multi-agente. La pregunta más difícil sobre identidad es delegar la identidad del usuario a través de una cadena de agentes, pero para la autenticación entre agentes, las herramientas existentes están listas.

El descubrimiento dinámico de agentes es la nueva inversión en infraestructura. Esta es la pieza que no tiene un equivalente directo en los stacks empresariales existentes. Si quieres que los agentes se compongan en equipos en tiempo de ejecución basándose en capacidades en lugar de flujos de trabajo codificados, necesitas algo como el Agent Directory Service de AGNTCY. Cada agente que tu organización despliega se registra, y otros agentes lo consultan por habilidad.

Para mensajería segura entre agentes, recurre a SLIM. Cifrado de extremo a extremo, autenticado, con identidad verificada por mensaje, está diseñado específicamente para agentes y disponible en el repositorio GitHub de SLIM de AGNTCY. Si estás en una etapa más temprana y solo quieres que los agentes se comuniquen entre sí, un sistema Pub/Sub o una cola de mensajes te permite comenzar, pero tendrás que añadir autenticación y cifrado por tu cuenta. SLIM te proporciona esas primitivas por defecto.

La autorización detallada de herramientas es el trabajo de políticas que todo equipo empresarial debería planificar ahora. Autorizar si un agente puede invocar una herramienta no es suficiente. La verdadera pregunta de política es qué parámetros puede configurar, qué valores pueden tomar esos parámetros y bajo qué condiciones se permite la llamada. Un agente podría tener permiso para invocar una herramienta restart_service, pero solo en entornos que no sean de producción. Podría tener permiso para consultar registros, pero nunca con un rango de tiempo superior a 24 horas. Podría tener permiso para revertir cambios, pero solo entre las 9 a.m. y las 5 p.m. con un aprobador humano en el proceso. TBAC avanza en esta dirección, y esta es la capa que determinará si tu equipo de seguridad aprueba los sistemas multi-agente a escala o los bloquea en la fase de adquisición.

La respuesta a incidentes es el caso de uso que elegimos, pero el patrón subyacente al desarrollo —agentes especialistas independientes que se componen en tiempo de ejecución en torno a una tarea, sobre un sustrato compartido de descubrimiento, identidad, política y observabilidad— se aplica en cualquier situación donde un problema requiera múltiples especialistas trabajando con diferentes sistemas y tipos de datos para correlacionar evidencia en una decisión estructurada con un registro de auditoría. Tres breves ilustraciones, extraídas del núcleo comercial B2C y B2B, que comparten esta forma:

Resolución de problemas con pedidos y gestión de excepciones en el cumplimiento. Un orquestador clasifica un problema con un pedido, como fallo de pago, discrepancia de inventario, excepción de envío, bloqueo por fraude o validación de dirección. Los especialistas consultan el sistema de gestión de pedidos, el proveedor de pagos, la plataforma antifraude, el almacén, el transportista y el historial del cliente. El resultado es una ruta de resolución con pasos de acción y referencias a los sistemas de origen. Investigación multisistema activada por eventos, con salida estructurada.

Devoluciones, reembolsos y resolución de disputas. Un orquestador clasifica una devolución o disputa. Los especialistas obtienen el historial de compras y pagos, señales de fraude y abuso, evaluación del estado del artículo a partir de imágenes y texto, estado del envío, interpretación de políticas y viabilidad de reversión del pago con el procesador. El resultado es una decisión estructurada con referencias suficientemente sólidas para defenderse en un contracargo o una revisión regulatoria. El esquema de autorización por cadena de identidad mencionado anteriormente aplica directamente: otorgar issue_refund a un agente debe considerar el importe, la antigüedad y el patrón de disputas previas, no solo la solicitud en sí.

Configuración-Precio-Cotización (CPQ) y orquestación de mesa de negociación. Un orquestador gestiona la complejidad de un acuerdo: los especialistas validan la configuración del producto, evalúan las reglas de precios y la política de descuentos, analizan el crédito del cliente y las condiciones de pago, verifican la viabilidad del cumplimiento y revisan los términos legales, cada uno gestionado hoy por equipos separados con sistemas independientes. El resultado es una cotización estructurada con los pasos de aprobación que requiere. El patrón se extiende desde la investigación activada por eventos hasta la orquestación proactiva en torno a cualquier tarea que cruce límites entre equipos.

Los componentes utilizados aquí son todos de código abierto y están disponibles en el GitHub de AGNTCY. La Sala de Respuesta a Incidentes puede ser reproducida por cualquier equipo dispuesto a invertir en las capas de descubrimiento, identidad, políticas y observabilidad (y la más compleja de esas inversiones, la identidad, es una que la mayoría de las empresas ya han realizado). Estamos encantados de guiar a los equipos a través de la arquitectura, las decisiones y los compromisos en detalle.