El articulo que realmente desbloqueo mi arquitectura multi-agente

Mi equipo ha estado disenando un sistema agentico recientemente. Construir un solo agente parecia manejable, pero en cuanto intentamos conectar varios, las preguntas empezaron a acumularse.

Que estructura de orquestacion usamos? Como se comunican los agentes? Como gestionamos la memoria del sistema?

Entonces encontre un articulo de Rohit Ghumare que cubria practicamente todo con lo que habia estado luchando. Aqui va un desglose de las ideas clave junto con mi propia experiencia.

Por que multi-agente

Como he mencionado en publicaciones anteriores, multi-agente no siempre es la respuesta. Pero pase todo el ano pasado fracasando en la gestion de contexto con un solo agente.

El problema: la ventana de contexto de un agente unico se llena rapido, y cuando lo hace, el agente empieza a olvidar. Peor aun, cuando un agente intenta manejar multiples dominios simultaneamente, su capacidad de juicio se degrada.

Multi-agente resuelve esto separando responsabilidades, pero introduce sobrecarga de coordinacion. Gestionar esa sobrecarga es el verdadero reto, y el articulo lo aborda directamente.

Tres patrones de orquestacion

Esta fue la seccion mas practica. En lugar de organizar por “que es mas impresionante”, el articulo se centra en cuando usar que.

Patron Supervisor

Un agente gestor descompone tareas, las distribuye a trabajadores y sintetiza los resultados.

• Ideal para: Tareas que se dividen claramente en subtareas, o cuando necesitas trazabilidad
• Escala optima: 3-8 trabajadores
• Cuidado: Todas las decisiones pasan por el supervisor, creando un posible cuello de botella

Patron Enjambre (Swarm)

Sin gestor central. Los agentes se comunican entre pares y se autoorganizan.

• Ideal para: Problemas que requieren perspectivas diversas, o donde la capacidad de respuesta en tiempo real importa
• Cuidado: Trabajo duplicado, bucles infinitos, convergencia suboptima. La depuracion es complicada

Patron Jerarquico (Hierarchical)

Extension recursiva del patron supervisor. Coordinador de alto nivel → gestores intermedios → trabajadores.

• Ideal para: Sistemas con mas de 10 agentes, o cuando estrategia y tactica necesitan separacion clara
• Cuidado: Los costes de tokens se disparan con cada capa de coordinacion

Desde mi experiencia personal, el patron supervisor ha sido el mas estable. La clave esta en la distribucion eficiente de trabajadores y la gestion de errores: si no lo haces bien, el propio supervisor se convierte en el punto de fallo.

Como se comunican los agentes

Si la orquestacion define la estructura, la comunicacion define como fluye realmente la informacion entre agentes.

• Estado compartido (Shared State): Todos los agentes leen y escriben en un unico objeto de estado. Simple de implementar, facil de depurar. La mayoria de equipos deberian empezar aqui
• Paso de mensajes (Message Passing): Comunicacion asincrona a traves de un bus de eventos. Usalo cuando necesites acoplamiento debil entre agentes
• Traspaso (Handoff): Paso explicito de baston con transferencia completa de contexto. Funciona bien para pipelines de orden fijo

Arquitectura de memoria para sistemas multi-agente

El problema central de memoria es sencillo: como compartir estado sin causar colisiones? El articulo lo descompone en tres patrones.

Memoria basada en sesiones (Session-Based)

Cada agente trabaja en un estado local aislado. Los cambios se fusionan en la memoria compartida solo al finalizar la sesion.

• Ideal para: Trabajadores paralelos que necesitan operar de forma independiente sin interferencias
• Funcionamiento: El agente toma una instantanea del estado compartido al inicio de la sesion, trabaja localmente y fusiona los deltas al final
• Ventaja: Procesamiento paralelo sin colisiones

Memoria de ventana (Window Memory)

Una ventana deslizante retiene solo los N intercambios mas recientes. Las entradas antiguas se comprimen en resumenes.

• Ideal para: Conversaciones largas donde necesitas preservar contexto sin quemar tokens
• Funcionamiento: Cuando la ventana se desborda, el tercio mas antiguo se resume y comprime
• Ventaja: Evita el crecimiento ilimitado del estado

Memoria episodica (Episodic Memory)

Almacena el historial de colaboracion de combinaciones especificas de agentes y lo usa para informar decisiones futuras.

• Ideal para: Equipos de agentes que colaboran frecuentemente y deben mejorar basandose en resultados anteriores
• Funcionamiento: Registra que combinaciones de agentes tuvieron exito o fracasaron en que tareas
• Ventaja: Permite decisiones como “esta combinacion funciono bien la ultima vez - usemosla de nuevo”

Consideraciones de produccion

Costes de tokens

• Supervisor + 4 trabajadores: ~1K para descomposicion + ~12K entre trabajadores + ~2K para sintesis = aproximadamente 15K tokens por tarea
• La misma tarea con un solo agente: unos 4K tokens. El coste de coordinacion es casi 4 veces mayor
• Optimizacion: Cachear instrucciones del supervisor, estructurar las salidas de los trabajadores, invocar trabajadores solo cuando sea necesario

Latencia

• A 2-5 segundos por llamada LLM, 4 agentes en serie suponen mas de 12 segundos. En paralelo, 3-4 segundos
• Las tareas independientes siempre deben ejecutarse en paralelo

Prevencion de propagacion de errores

• Timeouts: Obligatorios en cada capa
• Circuit breakers: Dejar de llamar a un agente tras N fallos consecutivos
• Degradacion elegante: Las funcionalidades principales deben funcionar aunque algunos agentes esten caidos
• Aislamiento de estado: El fallo de un trabajador nunca debe corromper el estado compartido

Si no puedes observarlo, no puedes arreglarlo. El monitorizacion es un requisito desde el dia uno.

Anti-patrones a evitar

• Sobre-orquestacion: Vincular agentes que podrian funcionar independientemente
• Agente todopoderoso: Si un agente lo hace todo, el multi-agente pierde sentido
• Ignorar costes: Desplegar sin monitorizacion de tokens lleva a facturas sorpresa
• Sin fallback: Asumir que todos los agentes estaran siempre disponibles

Conclusion

La conclusion del articulo se me quedo grabada:

Construir un agente. Identificar donde falla. Anadir un segundo agente en ese punto de ruptura. Anadir un supervisor si es necesario. Repetir.

Empece con un diseno jerarquico ambicioso y acabe simplificando a un supervisor con tres trabajadores. La leccion: primero construir una colaboracion estable entre dos agentes, y luego escalar desde ahi.

Si estas en medio del diseno de un sistema multi-agente, te recomiendo leer el articulo original.

Fuente: Building Effective Multi-Agent Systems