El articulo que de verdad me ayudo a disenar mi arquitectura multi-agente

Mi equipo ha estado disenando un sistema agentico ultimamente. Armar un solo agente ya lo teniamos mas o menos controlado, pero cuando quisimos conectar varios, las dudas empezaron a crecer mucho mas de lo esperado.

Que estructura de orquestacion usamos? Como se comunican los agentes entre si? Como manejamos la memoria del sistema?

Fue entonces cuando encontre un articulo de Rohit Ghumare que cubria practicamente todo lo que me tenia trabado. Les comparto 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 correcta. Pero pase todo el ano pasado fracasando en el manejo de contexto con un solo agente.

El problema: la ventana de contexto de un agente unico se llena rapido, y cuando eso pasa, el agente empieza a perder el hilo. Ademas, cuando un agente intenta manejar multiples dominios a la vez, su capacidad de juicio se degrada.

Multi-agente resuelve esto separando responsabilidades, pero a cambio mete sobrecarga de coordinacion. Manejar esa sobrecarga es el verdadero reto, y el articulo lo aborda de frente.

Tres patrones de orquestacion

Esta fue la seccion mas practica. En vez de organizar por “que se ve mas padre”, el articulo se enfoca en cuando usar que cosa.

Patron Supervisor

Un agente gestor descompone tareas, las reparte entre trabajadores y sintetiza los resultados.

• Ideal para: Tareas que se dividen claramente en subtareas, o cuando necesitas rastreabilidad
• Escala optima: 3-8 trabajadores
• Ojo: Todas las decisiones pasan por el supervisor, lo que puede crear un 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 respuesta en tiempo real importa mucho
• Ojo: Trabajo duplicado, loops infinitos, convergencia suboptima. El debugging se pone dificil

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 la estrategia y la tactica necesitan separacion clara
• Ojo: Los costos de tokens se disparan con cada capa de coordinacion

Desde mi experiencia, el patron supervisor ha sido el mas estable. La clave esta en distribuir bien a los trabajadores y manejar errores correctamente: si no lo haces bien, el supervisor mismo se vuelve el punto de falla.

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 mismo objeto de estado. Simple de implementar, facil de depurar. La mayoria de los equipos deberian arrancar por 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 estafeta 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 directo: 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 terminar la sesion.

• Ideal para: Trabajadores paralelos que necesitan operar independientemente sin estorbarse
• Como funciona: El agente toma una foto del estado compartido al inicio de la sesion, trabaja local y fusiona los cambios al final
• Ventaja: Procesamiento paralelo sin colisiones

Memoria de ventana (Window Memory)

Una ventana deslizante solo retiene los N intercambios mas recientes. Lo viejo se comprime en resumenes.

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

Memoria episodica (Episodic Memory)

Almacena el historial de colaboracion de combinaciones especificas de agentes y lo usa para tomar mejores decisiones despues.

• Ideal para: Equipos de agentes que colaboran seguido y deben mejorar con base en resultados anteriores
• Como funciona: Registra que combinaciones de agentes tuvieron exito o fracasaron en que tareas
• Ventaja: Permite decisiones como “esta combinacion funciono bien la vez pasada - usemosla otra vez”

Consideraciones de produccion

Costos 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: como 4K tokens. El costo de coordinacion es casi 4 veces mayor
• Optimizacion: Cachear instrucciones del supervisor, que las salidas de los trabajadores sean datos estructurados, invocar trabajadores solo cuando se necesite

Latencia

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

Prevencion de propagacion de errores

• Timeouts: Obligatorios en cada capa
• Circuit breakers: Dejar de llamar a un agente despues de N fallas consecutivas
• Degradacion elegante: Las funcionalidades principales deben jalar aunque algunos agentes esten caidos
• Aislamiento de estado: La falla de un trabajador nunca debe contaminar el estado compartido

Si no lo puedes ver, no lo puedes arreglar. El monitoreo es requisito desde el dia uno.

Anti-patrones a evitar

• Sobre-orquestacion: Conectar agentes que podrian funcionar solos
• Agente todopoleroso: Si un agente lo hace todo, el multi-agente no tiene sentido
• Ignorar costos: Desplegar sin monitoreo de tokens lleva a sustos en la factura
• Sin fallback: Asumir que todos los agentes siempre van a estar disponibles

Conclusion

La conclusion del articulo se me quedo grabada:

Construir un agente. Identificar donde truena. Agregar un segundo agente en ese punto de quiebre. Agregar un supervisor si hace falta. Repetir.

Empece con un diseno jerarquico ambicioso y termine simplificando a un supervisor con tres trabajadores. La leccion: primero lograr que dos agentes colaboren de forma estable, y despues escalar desde ahi.

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

Fuente: Building Effective Multi-Agent Systems