Curso exprés · No. 29
Un solo agente afronta un objetivo en un bucle. Algunos problemas son más grandes que eso: demasiadas herramientas, demasiadas destrezas distintas, demasiado para sostener en un solo contexto. Los sistemas multi-agent reparten el trabajo entre agentes especializados coordinados por un orchestrator. Bien hechos, son más fiables y escalables; hechos por reflejo, multiplican cada modo de fallo. Aquí va cuándo muchos agentes superan a uno, y cómo conectarlos.
Solo lo esencial · Una imagen por idea · Fiabilidad sobre magia
Antes de conectar agentes entre sí, entiende el problema que resuelve. Los sistemas multi-agent existen por una razón concreta, y recurrir a ellos sin esa razón es justo como salen mal.
Un agente que lo hace todo no hace bien nada
Un solo trabajador al que le piden ser el arquitecto, el fontanero, el electricista y el inspector, frente a una pequeña cuadrilla de especialistas que cada uno hace una cosa bien.
Un solo agente con un mandato demasiado amplio —todas las herramientas, toda clase de tareas, un prompt gigante— tiene demasiadas formas de equivocarse en cada paso. A medida que el trabajo crece, su fiabilidad cae. Repartir el trabajo entre agentes especializados, cada uno con una tarea acotada, puede hacer el sistema entero más capaz y más fiable, igual que una cuadrilla de especialistas le gana a un generalista desbordado. La especialización es la razón central por la que existe el multi-agent.
El contexto y las herramientas sobrecargan a un solo agente
Un escritorio amontonado con todos los documentos y todas las herramientas de diez trabajos distintos: el trabajador gasta más esfuerzo en ordenar el desorden que en hacer el trabajo.
Dos límites concretos empujan más allá de un solo agente. La ventana de contexto de un agente se llena con todo lo de cada parte de la tarea, y un contexto sobrecargado degrada la calidad (el problema de la ingeniería de contexto). Y un solo agente que sostiene todas las herramientas tiene que elegir dentro de un menú gigante en cada turno, algo que hace peor cuantas más haya. Dividir permite que cada agente cargue solo el contexto y las herramientas que su tarea acotada necesita: limpio, enfocado, fiable.
La especialización es el objetivo, y el coste es la coordinación
Un equipo de relevos es más rápido que un corredor haciendo cuatro postas, pero solo porque los relevos están practicados; un testigo que se cae pierde la carrera.
La ganancia del multi-agent es la especialización: agentes acotados que cada uno hace una cosa bien. El coste es la coordinación: ahora algo tiene que repartir el trabajo, enrutarlo, pasar contexto entre agentes y ensamblar los resultados, y esa coordinación es en sí misma una fuente de complejidad y de fallo. Toda la disciplina consiste en capturar la ganancia de la especialización sin que el coste de la coordinación se la coma. Cuando la ganancia no supera al coste, un solo agente era la respuesta correcta.
Un agente que lo hace todo no hace bien nada: demasiado contexto, demasiadas herramientas. Muchos agentes especializados pueden ser más capaces, pero el precio es la coordinación, que debe valer la ganancia.
La forma más común de un sistema multi-agent tiene un coordinador en su centro. Entender el orchestrator es casi todo lo que hace falta para entender cómo se conectan estos sistemas.
Un coordinador que enruta el trabajo
Un jefe de obra en un solar: no pone los ladrillos ni cablea el cuadro, sino que divide el proyecto en tareas y envía cada una al especialista adecuado.
El orchestrator (o coordinador) es el agente al mando: toma el objetivo global, lo descompone en subtareas y enruta cada subtarea al agente especializado adecuado. No hace el trabajo especializado él mismo; su tarea es la descomposición y la dirección. Esto refleja la idea de plan-and-execute del curso de agentes, llevada a mayor escala: un agente capaz planifica y delega, mientras workers enfocados ejecutan las piezas.
Ensambla los resultados de los workers
Un editor encarga secciones a distintos redactores y luego las combina en un solo artículo coherente: las piezas vuelven, y alguien las hace un todo.
La segunda tarea del orchestrator es el ensamblaje: reunir lo que devuelven los worker agents y combinarlo en un resultado final coherente. Un orchestrator de investigación podría enviar subtemas a varios agentes y luego sintetizar sus hallazgos en una sola respuesta. Este paso de recopilar y combinar es donde los flujos separados de trabajo se vuelven una sola salida, y hacerlo bien (resolver conflictos, descartar duplicados) es tan importante como el reparto.
La capa de coordinación es la verdadera arquitectura
Una orquesta no es un montón de solistas brillantes: es el director y la partitura decidiendo quién toca y cuándo. La coordinación es la música.
En un sistema multi-agent, el valor y la dificultad se trasladan a la capa de coordinación: quién se ejecuta y cuándo, con qué entrada y cómo se combinan los resultados. Los agentes individuales se llevan la atención, pero que el sistema funcione lo decide la orquestación a su alrededor: el enrutamiento, el paso de contexto, el manejo de errores. Como con los agentes individuales, el modelo es la parte fácil; la estructura a su alrededor es donde la fiabilidad se gana o se pierde.
El orchestrator descompone el objetivo, enruta cada subtarea a un worker especializado y ensambla sus resultados. La capa de coordinación —no los agentes individuales— es la verdadera arquitectura.
Los agentes que dirige el orchestrator son más útiles cuando cada uno es acotado. La disciplina de mantener a los workers enfocados es lo que hace al sistema entero fiable y testeable.
Cada worker tiene una tarea clara
Una cocina con una estación para cada tarea —un cocinero en salsas, otro en la parrilla, otro en el emplatado—, cada uno dominando su papel acotado en lugar de chapucear todos.
Un worker agent es un agente especializado con una tarea acotada y bien definida: buscar en la documentación, escribir el código, verificar los hechos, formatear la salida. Como su mandato es pequeño, su prompt es enfocado, sus herramientas son pocas y su comportamiento es predecible. El orchestrator le pasa una subtarea clara, hace esa única cosa y devuelve el resultado. Los workers acotados son los bloques de construcción: cada uno lo bastante simple como para acertarlo y confiar en él.
Los agentes acotados son más fáciles de testear y de confiar
Puedes inspeccionar a fondo el trabajo de un solo especialista porque su tarea es pequeña y definida, mucho más fácil que auditar a un generalista que hace un poco de todo.
Un agente acotado es muchísimo más fácil de evaluar, depurar y confiar que uno desparramado. Con una sola tarea clara, puedes escribirle evaluaciones, ver exactamente dónde falla y arreglarlo de forma aislada: el mismo argumento de fiabilidad del curso de agentes, aplicado a cada pieza. Un sistema multi-agent es fiable solo si sus workers son individualmente fiables, y eso es mucho más fácil de lograr cuando cada uno hace una cosa bien acotada.
La profundidad en una tarea le gana a la amplitud en muchas
Un cirujano que solo hace una operación, miles de veces, le gana a un generalista que la intenta de vez en cuando: el enfoque produce una fiabilidad que la amplitud no puede.
El principio que recorre todo esto es que la profundidad le gana a la amplitud: un agente enfocado haciendo una cosa repetidamente es más fiable que uno amplio haciendo muchas de vez en cuando. Por eso descompones: no para tener más agentes porque sí, sino para que cada uno sea lo bastante acotado como para ser genuinamente bueno en su pieza. Si la tarea de un worker sigue siendo demasiado amplia para ser fiable, la respuesta suele ser dividirla más, no amontonarle más herramientas.
Los worker agents son especialistas acotados —una tarea clara, un prompt enfocado, pocas herramientas— lo que hace a cada uno testeable y digno de confianza. La profundidad en una tarea le gana a la amplitud en muchas.
Los agentes valen solo tanto como lo que se pasan entre sí. Cómo se mueven el trabajo y el contexto entre ellos —de forma limpia o desordenada— decide si el sistema se mantiene coherente o se degrada en ruido.
Un handoff pasa el trabajo entre agentes
Un corredor de relevos pasando el testigo: el intercambio es una destreza en sí mismo, y un pase limpio —no solo corredores rápidos— es lo que gana la carrera.
Un handoff es el momento en que un agente le pasa el trabajo a otro: el orchestrator a un worker, o un agente directamente al siguiente. Lo que se pasa es la subtarea y el contexto necesario para hacerla. Los handoffs son donde ocurren muchos fallos del multi-agent: si el agente receptor no recibe lo que necesita, o recibe una versión confusa, su salida está mal por bueno que sea el agente. El intercambio es una parte de primera clase del diseño.
Pasa contexto limpio y estructurado, no todo
Un buen briefing le da a la siguiente persona exactamente lo que necesita para su tarea, no la transcripción entera de cada conversación anterior por la que vadear.
La tentación es pasarle a cada agente todo el historial hasta el momento, pero eso recrea el problema del contexto sobrecargado dentro de cada agente. Mejor es un handoff limpio: darle al agente receptor un resumen enfocado y estructurado de justo lo que necesita —los hechos relevantes y la tarea concreta— y no el chorro en bruto. Esto mantiene el contexto de cada agente ceñido y enfocado, que es exactamente lo que hizo que dividir mereciera la pena en primer lugar.
El context isolation mantiene a los agentes enfocados
Salas de trabajo separadas, cada una solo con los materiales para la tarea de esa sala, de modo que nadie se distraiga ni se confunda con el desorden de todas las demás tareas.
Un beneficio real del multi-agent es el context isolation: cada agente trabaja en su propio contexto limpio, viendo solo lo que su tarea requiere, no el lío acumulado del sistema entero. Esto es parte de por qué dividir puede mejorar la fiabilidad: evita la pudrición de contexto que se acumula en un solo agente de larga duración. Pero solo obtienes ese beneficio si tus handoffs son disciplinados; pásaselo todo a todos y habrás reconstruido el problema del agente único sobrecargado con pasos de más.
Los handoffs pasan el trabajo entre agentes, y son donde el multi-agent suele fallar. Pasa un resumen limpio y estructurado de justo lo necesario, para que cada agente conserve el contexto enfocado que dividir pretendía darle.
Los sistemas multi-agent se conectan en unas pocas formas recurrentes. Conocer las tres principales —y cuándo encaja cada una— es casi todo lo que hace falta saber para estructurar la coordinación.
Sequential: una tubería de etapas
Una cadena de montaje: cada estación hace su parte y pasa el producto a la siguiente, en un orden fijo, hasta que sale terminado al final.
El patrón sequential encadena agentes en un orden fijo: la salida del agente A alimenta al agente B, cuya salida alimenta al agente C. Un agente de borrador, luego un agente de edición, luego un agente de verificación de hechos. Es la forma multi-agent más simple y la más predecible, ideal cuando el trabajo tiene etapas naturales que deben ocurrir en orden. Es en esencia una tubería de especialistas, y cuando los pasos son fijos, es más fiable que un bucle que redecide el orden cada vez.
Parallel: abrir en abanico y reunir
Enviar la misma pregunta de investigación a varios asistentes a la vez y luego recopilar todos sus hallazgos juntos: muchos trabajando simultáneamente, los resultados fusionados al final.
El patrón parallel ejecuta varios agentes al mismo tiempo sobre piezas independientes y luego reúne sus resultados: un fan-out seguido de una reunión. Investigar cinco subtemas, procesar muchos elementos, obtener varias perspectivas independientes: todo es más rápido hecho en paralelo que uno tras otro. El orchestrator reparte el trabajo, los workers se ejecutan simultáneamente y los resultados se combinan. El parallel brilla cuando las piezas no dependen unas de otras y la velocidad importa.
Hierarchical: orchestrators de orchestrators
Un organigrama de empresa: un gerente dirige a jefes de equipo, que dirigen cada uno a sus propios workers; coordinación anidada en capas para una tarea demasiado grande para un solo nivel.
El patrón hierarchical anida la coordinación: un orchestrator superior delega en sub-orchestrators, cada uno gestionando sus propios workers. Esto afronta tareas genuinamente grandes y complejas descomponiéndolas en capas, como hace una organización. Es la forma más potente y la más compleja —más coordinación, más sitios donde fallar—, así que recurres a ella solo cuando la tarea es genuinamente lo bastante grande como para necesitar descomposición anidada. La mayoría de los sistemas se las arreglan con sequential o parallel; la jerarquía es para los pocos que no.
El sequential encadena agentes en una tubería fija; el parallel abre en abanico trabajo independiente y lo reúne; el hierarchical anida orchestrators para tareas grandes. Usa la forma más simple que el trabajo realmente necesita.
El multi-agent es seductor y a menudo se usa de más. Más agentes no solo añaden capacidad: multiplican las formas en que el sistema puede romperse, e ignorar eso es como estos sistemas fallan en silencio.
Más pasos componen más error
Un relevo más largo con más handoffs tiene más oportunidades de que se caiga el testigo: cada intercambio extra es otro sitio donde toda la carrera puede fallar.
Un solo agente ya tiene éxito solo una fracción de las veces a lo largo de una cadena larga (el problema de la fiabilidad del curso de agentes), y el multi-agent alarga la cadena: más agentes, más handoffs, más pasos, cada uno capaz de fallar y pasar su error aguas abajo. La fiabilidad se multiplica a lo largo de la cadena, así que añadir agentes puede bajar el éxito global a menos que cada pieza y cada handoff sean sólidos. Más agentes es más superficie para el fallo compuesto, no automáticamente más capacidad.
La coordinación tiene su propia sobrecarga y coste
Una reunión para coordinar cinco equipos puede costar más que el propio trabajo: pasado un punto, coordinar pesa más que hacer.
Cada agente son sus propias llamadas al modelo, su propia latencia, su propio coste, y la orquestación añade más por encima. Un sistema multi-agent puede ser mucho más lento y más caro que un solo agente para la misma tarea, a veces sin ser mejor en nada. La sobrecarga de coordinación es real: enrutamiento, handoffs, ensamblaje, reintentos. Si la ganancia de especialización no supera claramente este coste y latencia añadidos, el agente único más simple era la mejor decisión de ingeniería.
Es más difícil de rastrear y depurar
Rastrear un solo paquete es fácil; seguir un fallo a través de una red de almacenes, camiones y traspasos es una tarea distinta y mucho más difícil.
Cuando algo sale mal en un sistema multi-agent, encontrar dónde es mucho más difícil que en un solo agente: el fallo podría estar en cualquier worker, cualquier handoff o la orquestación misma. La observabilidad —rastrear una petición a través de los agentes, registrar cada handoff— se vuelve esencial y más difícil. Este coste de depuración es una parte real del precio. Un sistema que no puedes rastrear es un sistema que no puedes arreglar de forma fiable, y el multi-agent hace el rastreo genuinamente más difícil.
Más agentes multiplican los modos de fallo: más pasos que componen error, sobrecarga y coste de coordinación reales, y un rastreo mucho más difícil. El multi-agent por reflejo baja la fiabilidad, no la sube.
El multi-agent es una herramienta potente para el problema correcto y un error caro para el equivocado. Usarlo bien es sobre todo contención: dividir solo cuando un solo agente genuinamente no puede.
Divide solo cuando un agente genuinamente no puede
No formas un comité para responder una pregunta simple: traes a un equipo solo cuando la tarea es genuinamente demasiado grande para una persona capaz.
Lo predeterminado debería ser un solo agente, y recurres al multi-agent solo cuando uno genuinamente no puede con la tarea: demasiadas destrezas distintas, demasiadas herramientas, demasiado contexto para sostener de forma coherente. Si un solo agente bien construido puede hacerlo, la versión multi-agent solo añade coste, latencia y modos de fallo sin ganancia. La pregunta nunca es «¿podría dividir esto?» —casi cualquier cosa puede dividirse—, sino «¿se queda un solo agente realmente corto aquí?».
Mantén cada agente acotado y cada handoff limpio
Una cuadrilla bien llevada tiene papeles claramente definidos y handoffs practicados: la estructura, no las heroicidades, es lo que la hace fiable.
Cuando sí vas a multi-agent, las dos disciplinas que lo hacen funcionar son: mantener cada worker acotado (una tarea clara, pocas herramientas, testeable de forma aislada) y mantener cada handoff limpio (un resumen enfocado de justo lo necesario, no el historial entero). La mayoría de los fallos multi-agent se rastrean hasta un worker demasiado amplio o un handoff demasiado confuso. Acierta esos dos, con un orchestrator claro y el patrón más simple que encaje, y el sistema se mantiene fiable a medida que escala.
- ¿Puede un solo agente hacer esto de verdad o genuinamente se rompe bajo la carga? - ¿Hay un orchestrator claro que descomponga, enrute y ensamble? - ¿Es cada worker acotado —una tarea, pocas herramientas, testeable por sí solo? - ¿Son limpios los handoffs —un resumen enfocado, no todo el historial volcado? - ¿Qué patrón encaja —sequential, parallel o hierarchical— y es el más simple que funciona? - ¿Supera la ganancia al coste —más pasos, latencia, gasto y rastreo más difícil?
- multi-agent / orchestrator — repartir el trabajo entre agentes, coordinados por un director.
- worker agent / especialización — un agente acotado con una tarea clara; profundidad sobre amplitud. - handoff / context isolation — pasar el trabajo limpiamente; cada agente en su propio contexto enfocado. - sequential / parallel / hierarchical — tubería, abrir-en-abanico-y-reunir, coordinación anidada. - fan-out — repartir el trabajo para ejecutar varios agentes a la vez. - coordination overhead — el coste, la latencia y la complejidad añadidos de la orquestación. - compounding error — más pasos y handoffs multiplicando la probabilidad de fallo.
- Recurres al multi-agent solo cuando un agente genuinamente no puede. - Un orchestrator claro descompone, enruta y ensambla el trabajo. - Cada worker es acotado —testeable y digno de confianza por sí solo. - Los handoffs son limpios, pasando contexto enfocado y manteniendo ceñida la ventana de cada agente. - Usas el patrón más simple que encaja y puedes rastrear un fallo a través de los agentes.
El multi-agent es deliberado: divide solo cuando un agente realmente no puede, dale un orchestrator claro, mantén cada worker acotado y cada handoff limpio, y usa el patrón más simple, porque cada agente que añades multiplica el coste y los modos de fallo.