Arquitectura agéntica D2D: cómo funcionan los agentes de dominio a dominio

Los agentes de IA autónomos ya no son solo demos. Los equipos de seguridad en producción están desplegando pipelines multiagente que abarcan la detección de amenazas, el triaje, la remediación y los informes, todo sin que una persona pulse «aprobar» entre un paso y otro. El patrón que hace que esto funcione a escala es la arquitectura agéntica Domain-to-Domain (D2D).

¿Qué es D2D?

D2D es un patrón de arquitectura en el que los agentes de IA se acotan a dominios (por ejemplo, monitorización de red, triaje de identidades o gestión de vulnerabilidades) y se comunican mediante un protocolo estructurado entre dominios, en lugar de a través de un monolito central o de una cola de prompts compartida. Piensa en microservicios, pero para agentes de IA que razonan y actúan.

La idea clave: cada agente de dominio es dueño de su contexto, sus herramientas y su frontera de decisión. La coordinación entre dominios se hace mediante contratos de mensajes explícitos, no mediante estado compartido. Eso es lo que hace que los sistemas D2D sean auditables, componibles y sorprendentemente robustos ante los fallos.

Los tres tipos de nodo principales

Nodo coordinador

El coordinador es el orquestador: guarda el contexto de la misión y descompone los objetivos en subtareas asignadas a los nodos worker. No ejecuta directamente. Su trabajo es:

• Aceptar objetivos de alto nivel de un operador humano o de un sistema aguas arriba
• Enrutar las subtareas al dominio worker adecuado
• Seguir el estado de las tareas y las cadenas de dependencias
• Agregar los resultados y decidir si la misión está completa o necesita replanificarse
• Activar los nodos killer cuando un worker está atascado, desbocado o produciendo una salida mala

Un coordinador suele ser un modelo más grande y capaz de razonar (de nivel Claude Opus), porque tiene que manejar la ambigüedad y replanificar ante fallos parciales. Aquí importa menos la latencia que la corrección.

Nodo worker

Los workers son los especialistas. Cada nodo worker:

• Es dueño de un único dominio (por ejemplo, «agente de consultas al SIEM», «agente de enriquecimiento de CVE», «agente de notificaciones a Slack»)
• Tiene un conjunto de herramientas acotado: solo las relevantes para su dominio
• Acepta mensajes de tarea estructurados del coordinador
• Devuelve resultados estructurados (con estado, evidencias y puntuaciones de confianza)
• Emite latidos (heartbeats) para que el coordinador pueda detectar bloqueos

Los workers suelen ser modelos más pequeños y rápidos (de nivel Haiku): son baratos de ejecutar y fáciles de paralelizar. La restricción de dominio es lo que los hace seguros: un worker de monitorización de red literalmente no puede llamar a tu API de facturación.

Nodo killer

El nodo killer es la válvula de seguridad, y a menudo la parte menos valorada de la arquitectura. Su trabajo es terminar los workers que están atascados en bucles, superan su presupuesto o producen salidas que no pasan una comprobación de seguridad. Un nodo killer bien diseñado:

• Vigila los tiempos de espera de los latidos de los workers
• Vigila los excesos sobre el presupuesto de tokens
• Ejecuta la validación de la salida (comprobaciones de esquema, detectores de alucinaciones, guardarraíles de políticas)
• Envía una señal KILL al coordinador, que reenruta o escala a revisión humana

Sin un nodo killer, un agente desbocado que entra en un bucle de llamadas a una API agotará tu presupuesto y producirá basura. Con uno, el peor caso es una replanificación ordenada.

Por qué D2D funciona en seguridad

Los flujos de trabajo de seguridad son exactamente el caso de uso para el que se construyó D2D:

• El aislamiento por dominios se corresponde con las fronteras de seguridad: tu agente de EDR y tu agente de IAM en la nube no deberían compartir contexto ni credenciales
• La auditabilidad viene de serie: cada mensaje entre dominios es un artefacto estructurado y registrado
• El radio de impacto está acotado: un nodo worker solo puede actuar dentro de su dominio
• El escalado a una persona es explícito: el coordinador sabe cuándo parar y preguntar

Cómo es el archivo de cada agente

En una implementación D2D típica, cada agente se define con tres archivos:

1. Manifiesto del agente (manifest.yaml): declara el nombre del agente, su dominio, su lista de herramientas, el modelo, el presupuesto de tokens y el intervalo de latido
2. Prompt del sistema (system.md): el rol del agente, sus restricciones, el esquema de salida y las reglas de escalado
3. Definiciones de herramientas (tools.json o tools.ts): la superficie exacta de API que el agente puede llamar, con esquemas de entrada y salida

El coordinador tiene además una tabla de enrutamiento (routing.yaml) que asigna tipos de tarea a dominios worker, y un esquema de misión que define cómo es una misión completada.

Lo siguiente en esta serie

En el próximo artículo recorreremos un despliegue D2D concreto para un centro de operaciones de seguridad: los archivos de manifiesto reales, la lógica de enrutamiento del coordinador y cómo se conectan los nodos killer a PagerDuty para escalar a una persona.