#LM13: Diseño y Arquitecturas de soluciones con Agentes Autónomos Colaborativos

¿Cómo se orquestan, armonizan, cooperan las nuevas soluciones de software que se implementan con Agentes autónomos?

La irrupción de los LLM y el crecimiento exponencial de la Inteligencia Artificial están marcando el inicio de una nueva era en el desarrollo de software: la de los agentes autónomos colaborativos.

Estos agentes, definidos por su capacidad para percibir, razonar, tomar decisiones, ejecutar acciones y, en muchos casos, aprender, están transformando la forma en que interactuamos con los sistemas digitales y automatizamos tareas complejas.

Este cambio de paradigma exige una revisión profunda de las arquitecturas tradicionales en la construcción del software empresarial.

Agentes Autónomos: ¿Qué aspectos hay que tener en cuenta a la hora de implementar un sistema colaborativo?

A diferencia de un LLM, un agente incorpora mecanismos de planificación, toma de decisiones, uso de herramientas externas e incluso retroalimentación para auto-mejorarse. Para ser considerado un "agente", un sistema de IA debe poder decidir qué herramienta usar y cuándo, evaluar múltiples soluciones propuestas y mantener un entendimiento contextual en interacciones prolongadas.

Con la incorporación de estos sistemas se abre un nuevo paradigma: la colaboración multiagente que implica que los agentes cooperan hacia un objetivo común (por ejemplo, mejorar la calidad del código fuente de una solución).

En este sistema de Agentes Autónomos colaborando entre sí hay que tener muy en cuenta los siguientes aspectos para definir los objetivos y la “arquitectura” de estos sistemas en función de los objetivos:

• Número, rol de agentes y estrategias (basadas en roles especializados, etc.)

• Estructura de comunicación (centralizada, peer-to-peer, etc.)

• Protocolos usados para la coordinación

• Tipo de orquestación

• Personalidad de los agentes

Vamos paso a paso a ver cada uno de ellos.

Roles especializados

Un error muy común es definir los roles de cada agente emulando los roles de un equipo humano.

Los nuevos agentes autónomos tienen otras características, otras habilidades, capacidades y limitaciones y, como tal, en nuestro papel de arquitectos de nuevos sistemas agénticos tenemos que tener un “pensamiento lateral” que nos permita eficientar el sistema. Por ejemplo, en un equipo de desarrollo de software tenderemos a tener agentes "especialistas" (devs, tester, analista funcional, etc.). ¿Emular a los humanos es el mejor esquema de agentes que podemos tener?

Echando un vistazo a las recomendaciones de las guías de ADK, AutoGen, CrewAI y LangGraph (los frameworks dominantes hoy día) coinciden en cuatro puntos importantes en el diseño general: (1) separar planificación, ejecución y validación reduce bucles de razonamiento; (2) los roles deben poder nacer y morir dinámicamente según la carga de trabajo; (3) la observabilidad y el tracking finos son indispensables para iterar; y (4) los protocolos de comunicación (ACP, A2A, etc.) deben negociarse desde el diseño inicial para impedir “lock-in” arquitectónico.

Hoy día hay una amplia discusión sobre si es bueno apoyarse en frameworks para la construcción de agentes o utilizar llamadas puras llamadas a los LLMs. Los partidarios de la segunda opción ponen especial foco en la trazabilidad y observabilidad de las respuestas que puede quedar “solapada” en ciertos frameworks. Lo que es innegable es que el uso de estos frameworks ayuda a escalar estos sistemas de forma más sencilla y rápida.

Ahondando en los principios básicos para definir roles y números de agentes, tenemos que considerar los siguientes principios:

• Función antes que figura. Un rol se define por la habilidad que aporta al sistema (p.ej. “Generador de código TypeScript con pruebas unitarias”) y por métricas medibles (latencia, precisión, coste de tokens), no por su parecido con un puesto humano.

• Acoplamiento mínimo – cohesión máxima. Cada rol gestiona un dominio de conocimiento o herramienta externa única; compartir demasiado en un solo agente ensancha el vector de error.

• Observabilidad nativa. Instrumenta cada agente con trazas estructuradas y paneles de métricas; esto permite despromover o escalar roles. Y, sobre todo, entender la importancia de cada uno en tu sistema.

• Evolución guiada por datos. Usa métricas de cobertura de tests, coste/tarea y ratio de intervenciones humanas para decidir cuándo fusionar o escindir roles.

Como ejemplo, dejamos por aquí algunos de los roles más usados y su taxonomía:

Estructura de comunicación entre agentes

Respecto a las estructuras de comunicación la clasificación suele darse en estos términos:

• Centralizada: Un agente central (orquestador) coordina y delega tareas a agentes subordinados. Es simple de diseñar y eficiente, pero introduce un punto único de fallo. Estos sistemas pueden ser poco resilientes.

• Descentralizada o Distribuida: No hay líder fijo; los agentes se comunican peer-to-peer. Ofrece robustez (el sistema sigue funcionando si un agente falla) y escalabilidad, aunque es más compleja de manejar.

• Jerárquica: Combina lo anterior con agentes en niveles. Reduce cuellos de botella al distribuir tareas, pero aún depende de agentes de nivel superior.

• Espacio Compartido (Blackboard): Los agentes interactúan leyendo y escribiendo en un almacén de información común, como una "pizarra". Facilita la coordinación en algunos escenarios, pero no es el enfoque típico en frameworks o LLM modernos que usan mensajes u objetos estructurados.

Protocolos de comunicación

Tal y como se recoge en este paper, los sistemas multi-agente más recientes convergen hacia cuatro estándares abiertos que cubren distintos niveles de interoperabilidad: MCP (herramientas), ACP (propósito general mediante REST), A2A (workflows y orquestación entre dominios) y ANP (mercados descentralizados). Seleccionar y combinar estos protocolos desde el diseño inicial recorta el tiempo medio de integración hasta un 30 % y evita el “vendor lock-in”.

Reproduzco esta tabla del propio paper que me ha parecido muy esclarecedora sobre las características de cada protocolo en cada caso:

La adopción secuencial (MCP → ACP → A2A → ANP) es la hoja de ruta más habitual según se van complejizando los sistemas y sus interacciones.

Tipos de Orquestación: Patrones Arquitectónicos Comunes

Perfecto, ya tengo los roles definidos, los protocolos de comunicación y compartición de resultados, etc. pero ¿cómo los orquesto entre ellos? Este es el punto esencial. Los frameworks proporcionan primitivas para componer sistemas de múltiples agentes y definen patrones de diseño recurrentes. Algunos patrones comunes para orquestar agentes:

• Coordinator/Dispatcher: Un agente central actúa como coordinador que administra varios agentes especialistas debajo de él. Su objetivo es encaminar cada petición entrante al agente especialista apropiado. En esta estructura jerárquica, el coordinador tiene una lista de sub_agents con descripciones claras de sus capacidades y delega dinámicamente según la naturaleza de la tarea (p. ej., un "Generador de Código" vs. un "Analizador de Seguridad"). Esto requiere definir con precisión el ámbito de responsabilidad de cada sub-agente para que el LLM del coordinador decida a quién transferir la consulta. El resultado es una arquitectura organizada y mantenible que enruta consultas al agente más competente.

• Pipeline Secuencial: Organiza múltiples agentes en una cadena fija de pasos, donde la salida de un agente alimenta la entrada del siguiente. Es útil para flujos de trabajo bien definidos (analizar requerimientos -> generar código -> probar código -> desplegar). En Google ADK, por ejemplo, se implementa con un SequentialAgent que encadena agentes hijos en orden predefinido. Los agentes comparten estado a través de un contexto común (escribiendo resultados en session.state). Un uso práctico sería una canalización donde un agente genera código, el siguiente lo toma para generar tests, y un tercero ejecuta los tests. Este patrón garantiza un orden determinista y facilita la evaluación de cada etapa por separado.

• Ejecución Paralela (Fan-Out/Gather): Permite lanzar varias subtareas en paralelo y luego recolectar sus resultados. Por ejemplo, lanzar varios agentes generadores de tests concurrentemente para diferentes módulos. Por seguir con el ejemplo, ADK lo soporta con ParallelAgent. El beneficio es acelerar el procesamiento de tareas independientes y aprovechar la escalabilidad, especialmente con múltiples recursos de cómputo. Este patrón debe manejar la sincronización de resultados y dependencias al recopilar la información.

• Descomposición Jerárquica de Tareas: Agentes que dividen un problema complejo en sub-problemas más manejables recursivamente. Un agente de alto nivel recibe una meta general ("desarrollar esta aplicación completa") y la divide, asignando subtareas a agentes hijos especializados, quienes pueden subdividir aún más. Esto está relacionado con sistemas HTN en IA clásica. La ventaja es que cada agente opera en un alcance reducido, lo que puede mejorar la calidad de sus resultados. El desafío clave es coordinar el ensamble final de todos los sub-resultados.

• Generator–Critic (Review/Critic): Involucra dos agentes en roles complementarios: un agente generador produce una solución y otro agente crítico o revisor evalúa esa salida, señalando errores o mejoras. El generador refina su trabajo basado en la retroalimentación. Se inspira en técnicas de debate o reflexión. Por seguir con el ejemplo, en desarrollo de software, un agente escribe código y otro lo revisa buscando defectos, sugiriendo cambios. Algunos estudios sugieren que este enfoque de "pensar por pares" mejora la calidad del resultado final.

• Iterative Refinement: Un agente (o equipo) aplica un ciclo de iteración sobre una solución hasta alcanzar cierto criterio de calidad. Genera una salida inicial, la evalúa (posiblemente con un crítico o pruebas), la ajusta y repite. Es útil para problemas abiertos donde la primera respuesta no es óptima. En refactorización de código, por ejemplo, un agente propone un cambio, lo verifica con pruebas unitarias y ajusta si falla, repitiendo hasta que los tests pasen. Es análogo a la optimización iterativa. Frameworks como ADK proporcionan agentes de tipo LoopAgent para esto, manteniendo estado entre iteraciones.

• Human-in-the-Loop: Los agentes realizan su trabajo pero en ciertos hitos piden aprobación o input de un desarrollador humano. Por ejemplo, solicitar confirmación antes de aplicar un parche de código. Este patrón equilibra eficiencia con control, permitiendo a un arquitecto revisar decisiones de alto impacto. Muchas compañías lo adoptarán inicialmente para ganar confianza en los agentes antes de la autonomía total.

Estos patrones no son excluyentes y pueden (y deben) combinarse. Una arquitectura puede tener un coordinador que ejecuta un pipeline secuencial, invocando un sub-agente crítico y permitiendo iteraciones (refinamiento). La arquitectura final depende del caso de uso y cómo se balancean las ventajas con la complejidad.

Personalidad de los agentes

Quizás esta parte del diseño de sistemas multiagente es la que más me sorprende, y que descuidamos a buen seguro. Tuve la suerte de cruzarme con este paper: Personality-Driven Decision-Making in LLM-Based Autonomous Agents . El estudio demuestra de forma empírica que inyectar rasgos de personalidad OCEAN mediante “prompt-engineering” altera de manera estable, aunque no determinista, la planificación y la selección de tareas en agentes autónomos.

¿Y qué es esto del marco OCEAN? En psicología de la personalidad, OCEAN es el acrónimo que nombra los cinco grandes rasgos que describen la mayor parte de las diferencias estables entre individuos: Openness to Experience, Conscientiousness, Extraversion, Agreeableness y Neuroticism. Estos rasgos se modelan como dimensiones y constituyen el marco empírico dominante desde finales de los años 80, para los experimentos del comportamiento humano.

Básicamente el experimiento coge las tareas de 500 agendas con tres modelos (GPT-4o, GPT-4o-Mini y GPT-3.5-Turbo), los autores verifican que rasgos como Conscientiousness y Extraversion provocan cambios estadísticamente significativos en la prioridad asignada a tareas laborales o sociales, respectivamente, sobre todo en los modelos “razonadores”.

El trabajo aporta un marco de medición cuantitativa que permite evaluar el impacto de la personalidad inducida en tiempo de decisión y abre la puerta a agentes más eficaces por ejemplo para usarlos para ciber-defensa o simulación humana

Es decir, si le damos una personalidad propia a cada uno de nuestros agentes mediante prompt y no solo objetivos y tareas podremos influir en un mejor o peor rendimiento del sistema.

Recopilando que es gerundio: Mejores prácticas de diseño.

• Definir roles claros y límites de cada agente: Cada agente debe tener un área de responsabilidad bien definida (en su descripción/prompt) para evitar solapamientos y facilitar delegación correcta. También puedes considerar si quieres introducir rasgos de personalidad en tu agente para aumentar su precisión en las tareas a abordar.

• Comunicación estructurada, con fallback a lenguaje natural: Intercambiar información en formatos estructurados siempre que sea posible. Lenguaje natural para flexibilidad, añadiendo mecanismos de verificación (confirmación de entendimiento).

• Mantener un registro y estado compartido cuando corresponda: Usar un estado central o memoria compartida (base de conocimiento, session.state, databases vectoriales) para contrarrestar la falta de memoria global y ayudar a auditar decisiones. El patrón "blackboard" puede ser útil.

• Implementar loops de verificación cruzada: Incorporar agentes críticos o pasos de validación interna mejora confiabilidad. Tras una acción significativa, otro agente revisa el resultado. Puede requerirse que "dos agentes tienen que estar de acuerdo". Este principio aumenta la calidad a costa de más cómputo.

• Human-in-the-loop para decisiones finales: Al menos inicialmente, mantener al humano en control de decisiones irreversibles (aprobar un merge, confirmar un despliegue). Crea confianza y permite medir desempeño del agente vs criterio humano. La autonomía puede aumentarse con el tiempo en áreas de bajo riesgo.

• Iterar y aprender de los agentes: Tratar a los agentes como componentes evolutivos. Monitorizar resultados y métricas (sugerencias aceptadas, falsos positivos). Ajustar prompts, cambiar modelos, añadir conocimiento. Mejoran con prompt engineering, afinación y feedback, similar a mentoring para un miembro junior.

• Seguridad y aislamiento: Aplicar principios de sandboxing a agentes que ejecutan acciones. Ejecutar código en entorno aislado. Cuidar credenciales y limitar permisos al mínimo necesario. Vigilar entrada de datos no confiables (prompt injection), quizás usando agentes "guardianes".

• Alineación con objetivos de negocio: Vincular tareas de agentes con métricas de valor para la organización. Asegurate que no se vuelvan curiosidades tecnológicas. Si aportan valor real, es más fácil justificar su mantenimiento.

Adoptar una arquitectura multiagente implica repensar la forma de abordar problemas, pasando a ecosistemas de entidades inteligentes colaborando. Esto trae ventajas claras en especialización, paralelismo y robustez. No obstante, impone retos de orquestación, comunicación y control que demandan nuevos enfoques de ingeniería, desde protocolos estándar hasta estrategias de validación.

Estamos en las primeras etapas de este paradigma. Muchas organizaciones comenzarán con uno o dos agentes en roles asistidos, evaluando rendimiento y ganando confianza. Estudios recientes señalan esta transición de modelos aislados a sistemas colaborativos como un paso clave hacia una inteligencia colectiva artificial en aplicaciones del mundo real.

Para CTOs y arquitectos, es valioso explorar e invertir en estas arquitecturas ahora. Adoptarlas implica cultivar habilidades para entrenar, depurar y colaborar con agentes. Las organizaciones que integren fluidamente agentes en sus procesos estarán mejor posicionadas para escalar esfuerzos, mantener la calidad y responder más rápido a demandas cambiantes, respaldado por evidencia académica y práctica.

Es un campo en rápida evolución, y los próximos meses traerán más aprendizajes, estándares y herramientas. La invitación es a comenzar el camino ahora, de forma informada y estratégica.