El mapa: 19 conceptos en siete grupos

Un mapa de metro: primero ves las líneas enteras, luego recorres estación por estación.

El curso recorre siete grupos. Primero, por qué dividir el trabajo entre agentes y qué pagas por ello. Luego, los tres papeles del sistema: el orchestrator que reparte y ensambla, los workers que hacen trabajos estrechos y los handoffs entre ellos. Después, tres formas de conectar agentes, tres modos de fallo que el multi-agent multiplica y, por último, la práctica: cuándo dividir y cuándo no.

Cómo leer cada concepto

Un pasaporte: los mismos campos para todos, así es fácil compararlos.

Cada concepto a partir de aquí tiene las mismas partes: su nombre en inglés (recuérdalo: así lo llaman los docs y los papers), una imagen de la vida, un diagrama y una ficha con campos como problema, idea, ejemplo, coste y relaciones. La idea central del curso: más agentes multiplican tanto la capacidad como las formas de romperse, así que divides solo cuando un agente de verdad no basta.

Specialization — 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.

Este es el concepto de Specialization. Un solo agente con un mandato demasiado amplio (todas las herramientas, todo tipo de tareas, un prompt gigante) tiene demasiadas formas de equivocarse en cada paso. Cuanto más crece el trabajo, más cae su fiabilidad.

Repartir el trabajo entre agentes especializados, cada uno con una tarea estrecha, puede hacer que todo el sistema sea más capaz y más fiable, igual que una cuadrilla de especialistas supera a un generalista desbordado. La especialización es la razón principal de ser del multi-agent.

Context & Tool Overload — el contexto y las herramientas sobrecargan a un solo agente

Un escritorio cubierto con todos los documentos y todas las herramientas de diez trabajos distintos: el trabajador gasta más esfuerzo ordenando el desorden que haciendo el trabajo.

Dos límites concretos empujan más allá de un solo agente: es Context & Tool Overload. Primero: la ventana de contexto de un agente se llena con todo de cada parte de la tarea, y un contexto sobrecargado degrada la calidad (el problema de la ingeniería de contexto). Segundo: un agente con todas las herramientas tiene que elegir de un menú enorme en cada turno, y cuanto más largo el menú, peor elige.

Dividir permite que cada agente lleve solo el contexto y las herramientas que necesita su tarea estrecha: limpio, enfocado, fiable.

Coordination Cost — la especialización es la ganancia, la coordinación es el precio

Un equipo de relevos es más rápido que un corredor que hace los cuatro tramos, pero solo porque los traspasos están ensayados; un testigo que se cae pierde la carrera.

La ganancia del multi-agent es la especialización: agentes estrechos que hacen bien una sola cosa. El precio es el Coordination Cost: 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 fallos.

Toda la disciplina consiste en capturar la ganancia de la especialización sin dejar que el coste de coordinación se la coma. Cuando la ganancia no supera al coste, un solo agente era la respuesta correcta.

Orchestrator — un coordinador que enruta el trabajo

Un contratista general en una obra: no pone los ladrillos ni cablea el cuadro eléctrico; divide el proyecto en tareas y manda cada una al especialista adecuado.

Este es el patrón Orchestrator (también llamado coordinador). Es el agente al mando: toma el objetivo global, lo divide en subtareas (descomposición) y enruta cada subtarea al agente especializado adecuado. No hace él mismo el trabajo especializado; su tarea es descomponer y dirigir.

Esto refleja la idea de plan-and-execute del curso de agentes, a mayor escala: un agente capaz planifica y delega, mientras los workers enfocados ejecutan las piezas.

Assembly — el orchestrator combina los resultados de los workers

Un editor encarga secciones a distintos redactores y luego las combina en un artículo coherente: las piezas vuelven y alguien las hace un todo.

La segunda tarea del orchestrator es Assembly (también llamado síntesis): reunir lo que devuelven los worker agents y combinarlo en un único resultado final coherente. Un orchestrator de investigación puede mandar subtemas a varios agentes y luego sintetizar sus hallazgos en una sola respuesta.

Este paso de reunir y combinar es donde los flujos de trabajo separados se convierten en una única salida, y hacerlo bien (resolver conflictos, eliminar duplicados) es tan importante como el reparto.

Coordination Layer — la capa de coordinación es la arquitectura real

Una orquesta no es un montón de solistas brillantes: es el director y la partitura decidiendo quién toca cuándo. La coordinación es la música.

En un sistema multi-agent, el valor y la dificultad se trasladan a la Coordination Layer: quién se ejecuta 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 que los rodea: 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 se gana o se pierde la fiabilidad.

Worker Agent — cada worker tiene un trabajo claro

Una cocina con un puesto para cada tarea (un cocinero en salsas, otro en la parrilla, otro en el emplatado), cada uno dominando su papel estrecho en vez de tropezar con todos.

Un Worker Agent es un agente especializado con un trabajo estrecho y bien definido: buscar en los docs, escribir el código, comprobar los datos, dar formato a la salida. Como su mandato es pequeño, su prompt está enfocado, sus herramientas son pocas y su comportamiento es predecible.

El orchestrator le entrega una subtarea clara, él hace esa única cosa y devuelve el resultado. Los workers estrechos son los bloques de construcción: cada uno lo bastante simple para hacerlo bien y confiar en él.

Per-agent Evals — a un agente estrecho es más fácil probarlo y confiar en él

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 estrecho es muchísimo más fácil de evaluar, depurar y en quien confiar que uno disperso. Con un trabajo claro, puedes escribirle evals: es la práctica de Per-agent Evals, pruebas para cada agente por separado. Ves exactamente dónde falla y lo arreglas 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 lo son por separado, y eso es mucho más fácil de lograr cuando cada uno hace una cosa bien delimitada.

Depth over Breadth — la profundidad en un trabajo supera a la amplitud en muchos

Un cirujano que solo hace una operación, miles de veces, supera 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 Depth over Breadth: un agente enfocado que hace una cosa una y otra vez es más fiable que uno amplio que hace muchas cosas de vez en cuando. Por eso se descompone: no para tener más agentes por tenerlos, sino para que cada uno sea lo bastante estrecho como para ser de verdad bueno en su pieza.

Si el trabajo de un worker sigue siendo demasiado amplio para ser fiable, la respuesta suele ser dividirlo más, no amontonarle más herramientas.

Handoff — pasar trabajo entre agentes

Un corredor de relevos pasando el testigo: el traspaso es una destreza propia, y un pase limpio, no solo corredores rápidos, es lo que gana la carrera.

Un Handoff es el momento en que un agente pasa trabajo a otro: del orchestrator a un worker, o de 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 es errónea por bueno que sea el agente. El traspaso es una parte de primera clase del diseño, no un detalle.

Clean Handoff — pasa contexto limpio y estructurado, no todo

Un buen briefing le da a la siguiente persona justo lo que necesita para su tarea, no la transcripción completa de cada conversación anterior para que se abra paso entre ella.

La tentación es pasarle a cada agente todo el historial hasta ese momento, pero eso recrea el problema del contexto sobrecargado dentro de cada agente. Mejor es la práctica del Clean Handoff: dar al agente receptor un resumen enfocado y estructurado de solo lo que necesita (los datos relevantes y la tarea concreta), no la manguera de datos en bruto.

Así el contexto de cada agente se mantiene ajustado y enfocado, que es justo lo que hizo valer la pena dividir.

Context Isolation — cada agente tiene su propio contexto limpio

Salas de trabajo separadas, cada una solo con los materiales del trabajo de esa sala, para que nadie se distraiga ni se confunda con el desorden de todas las demás tareas.

Un beneficio real del multi-agent es Context Isolation: cada agente trabaja en su propio contexto limpio, viendo solo lo que su trabajo exige, no el desorden acumulado de todo el sistema. Es parte de por qué dividir puede mejorar la fiabilidad: evita el context rot que se acumula en un solo agente de larga ejecución.

Pero solo obtienes ese beneficio si tus handoffs son disciplinados; si pasas todo a todos, has reconstruido el problema del agente único sobrecargado con pasos extra.

Sequential — un pipeline de etapas

Una cadena de montaje: cada puesto hace su parte y pasa el producto al 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 que redacta el borrador, luego uno que edita, luego uno que verifica los datos.

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 esencialmente un pipeline de especialistas, y cuando los pasos son fijos, es más fiable que un bucle que vuelve a decidir el orden cada vez.

Parallel — repartir en abanico y reunir

Mandar la misma pregunta de investigación a varios asistentes a la vez y luego reunir todos sus hallazgos: muchos trabajando a la vez, 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 un gather. Investigar cinco subtemas, procesar muchos elementos, obtener varias perspectivas independientes: todo eso es más rápido en paralelo que uno tras otro.

El orchestrator reparte el trabajo, los workers corren a la vez y los resultados se combinan. 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 trabajadores; coordinación anidada en capas para un trabajo demasiado grande para un solo nivel.

El patrón Hierarchical anida la coordinación: un orchestrator superior delega en sub-orchestrators, cada uno con sus propios workers. Esto maneja tareas realmente grandes y complejas descomponiéndolas por capas, como hace una organización.

Es la forma más potente y la más compleja (más coordinación, más lugares donde fallar), así que solo recurres a ella cuando la tarea es de verdad tan grande como para necesitar descomposición anidada. A la mayoría de los sistemas les basta con sequential o parallel; la jerarquía es para los pocos que no.

Compounding Error — más pasos acumulan más error

Un relevo más largo, con más traspasos, tiene más ocasiones de dejar caer el testigo: cada intercambio extra es otro lugar donde puede fallar toda la carrera.

Este es el concepto de Compounding Error. Un solo agente ya solo tiene éxito una fracción de las veces a lo largo de una cadena larga (el problema de 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 acumulado, no automáticamente más capacidad.

Coordination Overhead — la coordinación tiene su propio sobrecoste

Una reunión para coordinar a cinco equipos puede costar más que el propio trabajo: pasado cierto punto, coordinar pesa más que hacer.

Esto es Coordination Overhead. Cada agente son sus propias llamadas al modelo, su propia latencia, su propio coste, y la orquestación suma más encima: enrutamiento, handoffs, ensamblaje, reintentos. Un sistema multi-agent puede ser mucho más lento y caro que un solo agente para la misma tarea, a veces sin ser mejor.

Si la ganancia de especialización no supera con claridad este coste y latencia añadidos, el agente único más simple era la mejor decisión de ingeniería.

Multi-agent Tracing — es más difícil de rastrear y depurar

Seguir un paquete es fácil; rastrear un fallo a través de una red de almacenes, camiones y traspasos es un trabajo distinto 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 puede estar en cualquier worker, en cualquier handoff o en la propia orquestación. Por eso la observabilidad se vuelve esencial: la práctica de Multi-agent Tracing, que consiste en rastrear una petición a través de los agentes y registrar cada handoff.

Este coste de depuración es parte real del precio. Un sistema que no puedes rastrear es un sistema que no puedes arreglar con fiabilidad, y el multi-agent hace el rastreo de verdad más difícil.

Single Agent by Default — divide solo cuando un agente de verdad no puede con ello

No formas un comité para responder una pregunta sencilla: traes un equipo solo cuando el trabajo es de verdad demasiado grande para una sola persona capaz.

Este es el principio de Single Agent by Default. Lo predeterminado debe ser un solo agente, y recurres al multi-agent solo cuando uno de verdad no puede con el trabajo: demasiadas destrezas distintas, demasiadas herramientas, demasiado contexto para sostenerlo con coherencia. 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 se puede dividir), sino "¿se queda corto de verdad un agente aquí?"

Mantén cada agente estrecho y cada handoff limpio

Una cuadrilla bien dirigida tiene papeles claramente definidos y traspasos ensayados: la estructura, no las hazañas heroicas, es lo que la hace fiable.

Cuando sí vas a multi-agent, las dos disciplinas que lo hacen funcionar son: mantener cada worker estrecho (un trabajo claro, pocas herramientas, comprobable de forma aislada) y mantener cada handoff limpio (un resumen enfocado de justo lo necesario, no todo el historial). La mayoría de los fallos del multi-agent se deben a un worker demasiado amplio o a un handoff demasiado confuso. Acierta en esas dos cosas, con un orchestrator claro y el patrón más simple que encaje, y el sistema se mantiene fiable al crecer.

Cómo encaja todo

El mapa de metro completo: ahora puedes ver dónde se cruzan las líneas.

Empiezas con un agente. Si no puede con ello, aparece un orchestrator: elige un patrón (sequential, parallel o hierarchical) y reparte trabajo a workers estrechos mediante handoffs limpios, y luego ensambla los resultados. Cada agente y cada handoff suman sobrecoste y error acumulado: si la ganancia es menor que el coste, vuelve a un solo agente. Y el rastreo muestra exactamente dónde se rompió algo.