El sistema multi-agente como dominio compuesto
Diseñamos sistemas multi-agente como composiciones de dominios, no como sumas de agentes. La diferencia importa cuando hay varios agentes operando sobre la misma empresa con responsabilidades cruzadas: un SDR digital que cualifica leads, un agente legal que valida contratos, un procesador documental que genera la propuesta. Si cada agente vive como una isla con su propio vocabulario y su propio estado, las inconsistencias aparecen en producción a las pocas semanas.
El cuerpo de teoría que mejor resuelve esto no es nuevo. Es Domain-Driven Design, propuesto por Eric Evans hace más de dos décadas. Aplicado a sistemas multi-agente, ofrece el marco preciso: cada agente como bounded context, los aggregates como dueños de estado, la traducción explícita cuando dos agentes se comunican. Esta es la arquitectura que aplicamos cuando un cliente pasa de un agente a tres o cuatro.
Bounded contexts: cada agente como contexto delimitado
Un bounded context es una frontera explícita dentro de la cual un modelo de dominio mantiene coherencia. La palabra "cliente" significa exactamente una cosa dentro de ese contexto, con un conjunto definido de atributos, reglas y operaciones. Otro bounded context puede llamar "cliente" a algo parcialmente distinto — y debe.
Aplicado a agentes IA: cada agente vive dentro de su propio bounded context. El SDR digital tiene un modelo de Lead: campos para cualificación, ICP fit, intención de compra. El agente legal tiene un modelo de Cliente enfocado en personalidad jurídica, jurisdicción y términos contractuales. El procesador documental tiene un modelo de Cliente centrado en datos fiscales y dirección de entrega.
Las tres entidades pueden corresponder a la misma persona del mundo real. Pero cada agente razona sobre los atributos relevantes a su contexto, con su lenguaje y sus reglas. Forzar un modelo único para los tres es la raíz de la mayoría de los sistemas multi-agente que se atascan.
Aggregates: quién posee qué estado
Un aggregate, en DDD, es el límite de consistencia dentro del cual un cambio es transaccional. Un Order y sus OrderLine forman un aggregate: no existen líneas sin pedido, las invariantes se verifican juntas, los cambios se persisten como una unidad.
En sistemas multi-agente, el aggregate define qué agente puede modificar qué entidad y bajo qué reglas. El SDR digital puede modificar el Lead en su contexto, pero no toca el Cliente del agente legal. El agente legal puede crear y modificar contratos, pero no toca el ICP del lead.
Cuando un agente necesita un cambio fuera de su aggregate, no escribe directamente — emite una solicitud al agente dueño, que valida con sus reglas. Esto convierte la coordinación entre agentes en una serie de operaciones controladas, no en concurrencia caótica sobre los mismos datos.
Sin aggregates explícitos, dos agentes pueden escribir contradicciones sobre la misma entidad en cuestión de segundos. Con aggregates explícitos, cada cambio pasa por su dueño y queda registrado.
Lenguaje ubicuo: vocabulario consistente dentro del contexto
El lenguaje ubicuo es la disciplina de que el código, los prompts del agente, la documentación y la conversación del equipo usen las mismas palabras para los mismos conceptos — dentro de un bounded context.
Aplicado a agentes IA, el lenguaje ubicuo afecta directamente al system prompt y a las descripciones de tools. Un agente legal cuyo prompt habla de "obligaciones", "prestaciones" y "contraprestación" razona con coherencia. El mismo agente cuyo prompt mezcla "contrato", "acuerdo", "deal" y "oferta" como si fueran sinónimos toma decisiones incoherentes.
La inversión en lenguaje ubicuo paga el doble en sistemas con IA generativa. El modelo razona con las palabras que recibe; palabras precisas producen razonamientos precisos; palabras ambiguas producen alucinaciones contextuales.
Anti-corruption layer: la traducción entre agentes
La pieza más útil de DDD en sistemas multi-agente es el anti-corruption layer (ACL). Cuando dos bounded contexts se comunican, la ACL traduce explícitamente entre sus modelos para que ninguno contamine al otro.
En sistemas multi-agente, la ACL es la capa que toma una entrega del SDR digital — "este lead está cualificado y listo para propuesta" — y la traduce al modelo del agente que recibe — "crea un cliente en estado preliminar con estos atributos comerciales y fiscales". La traducción es código, no es un agente más. Es determinista, auditable y testeable con stubs.
Sin ACL, los agentes terminan importando vocabulario unos de otros — el SDR digital empieza a hablar de "obligaciones contractuales" porque su contraparte legal lo hace, y a las semanas el cualificador está razonando sobre conceptos que no le tocan. Con ACL, cada agente mantiene su semántica y la traducción ocurre fuera de cualquiera de ellos.
Patrones de comunicación entre agentes
Tres patrones que aplicamos según el tipo de coordinación:
Orquestación. Un agente director coordina explícitamente a los demás: invoca al SDR para cualificar, al legal para validar, al documental para generar propuesta. El director conoce a todos; los demás solo conocen su contexto. Útil cuando el flujo es lineal y predecible.
Coreografía vía eventos. Cada agente emite eventos cuando completa una acción significativa (LeadCualificado, ContratoValidado, PropuestaGenerada). Otros agentes se suscriben a los eventos relevantes y reaccionan. No hay director central. Útil cuando el flujo es complejo, ramificado o evoluciona con el tiempo.
Request-response sobre puerto. El agente A invoca al agente B como si fuera una tool más. La invocación pasa por una ACL que traduce parámetros y resultado. Útil para consultas síncronas puntuales.
La elección depende del flujo de negocio, no de modas. La orquestación es más simple de razonar pero introduce un punto único de coordinación. La coreografía es más resiliente pero exige observabilidad cuidada para diagnosticar incidentes.
Anti-patrones que DDD previene
Tres errores frecuentes en sistemas multi-agente que esta disciplina corta de raíz:
El "agente que lo sabe todo" — un agente único intenta cubrir cualificación, contratos, documentos y soporte. El prompt crece a miles de tokens; las decisiones se confunden entre dominios; añadir un nuevo caso de uso obliga a tocar el sistema entero. Romper en bounded contexts devuelve foco a cada agente y mantiene el coste manejable.
El "estado compartido sin dueño" — varios agentes escriben sobre la misma entidad en HubSpot sin coordinación. La integridad se rompe en pocas semanas. Aggregates explícitos definen quién manda sobre qué.
El "lenguaje contaminado" — el equipo usa los mismos términos para cosas distintas porque "así lo decimos siempre". El modelo del LLM, alimentado con esa ambigüedad, decide con criterios incoherentes. La inversión en lenguaje ubicuo dentro de cada contexto resuelve este problema antes de que se manifieste.
Un caso real: cuatro agentes en una empresa de servicios profesionales
Un cliente nuestro opera con cuatro agentes IA sobre HubSpot y un ERP propio:
- SDR digital — cualifica leads entrantes contra ICP.
- Agente legal asistente — valida que las propuestas cumplen requisitos contractuales y de jurisdicción.
- Procesador documental — genera propuestas comerciales a partir de plantillas y datos del cliente.
- Customer success agent — vigila salud de clientes activos y detecta señales de churn temprano.
Cada agente vive en su bounded context, con su modelo de entidades y su prompt operando con vocabulario ubicuo. El estado se posee según aggregates explícitos: el SDR es dueño del Lead, el legal del Contrato, el documental de la Propuesta, el customer success del EstadoSalud. Las comunicaciones inter-agente pasan por ACLs implementadas como código Java, no como agentes adicionales.
Resultado a doce meses: cero incidentes por modelos divergentes de "cliente", añadir un quinto agente (gestión de cobros) tardó tres semanas porque tenía su bounded context bien delimitado, y el coste medio de operación por agente bajó cuando los prompts dejaron de mezclar dominios.
Cómo lo construimos en producción
En proyectos multi-agente serios, el primer entregable no es código. Es un mapa de contextos: qué agentes existen o existirán, qué entidades viven en cada contexto, qué ACLs traducen entre ellos, qué patrón de comunicación usa cada cruce. Ese mapa es el equivalente a un context map de DDD clásico, adaptado a sistemas con IA.
Sobre ese mapa, cada agente se construye con su dominio puro, su system prompt con vocabulario ubicuo y sus tools acotadas a su aggregate. Las ACLs se implementan como código Java, Python o TypeScript — no como agentes intermedios. La arquitectura es ejecutable desde el primer commit, auditable, testeable.
Detrás de cada uno de estos sistemas hay un equipo de desarrolladores que cree que diseñar sistemas multi-agente es un ejercicio de arquitectura de dominio antes que un ejercicio de prompt engineering. La elegancia del modelo importa menos que la claridad de los contextos sobre los que razona. Sistemas multi-agente que escalan, no orquestaciones que se rompen al cuarto agente.
Si tu empresa ya tiene un agente IA en producción y estás evaluando añadir más, podemos auditar el sistema actual y entregarte el context map antes de que el segundo agente entre en conflicto con el primero.
