# Cuando un solo agente no basta Curso exprés sobre sistemas multi-agent: cuándo repartir el trabajo entre agentes especializados coordinados por un orchestrator, y cuándo eso es peor que un solo agente. 19 conceptos (Specialization, Orchestrator, Worker Agent, Handoff, Context Isolation, Sequential, Parallel, Hierarchical, Compounding Error, Coordination Overhead y más), cada uno con su nombre en inglés, un diagrama, una ficha y un ejemplo. Al final: una hoja de referencia de una página con todos los conceptos. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/multi-agent-express --- ## 1. Por qué dividir en muchos 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. ### 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. _Diagram: Siete grupos de conceptos: los capítulos 1–7 los siguen._ ### 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. _Diagram: Izquierda: un agente para todo, con muchos puntos de fallo. Derecha: una cuadrilla donde cada uno hace una sola cosa._ #### Specialization (agentes especializados) - **Problema:** Un agente con un mandato amplio (todas las herramientas, un prompt gigante) comete errores con frecuencia. - **Idea:** Repartir el trabajo en agentes estrechos que hacen bien una sola cosa. - **Ejemplo:** En vez de un "agente para todo": un investigador, un programador, un verificador de datos y un formateador. - **Coste:** Ahora hace falta **coordinación**: algo tiene que repartir el trabajo y ensamblarlo. - **Relaciones:** La razón para usar **Orchestrator** y **Worker Agent**; el precio es **Coordination Cost**. ### 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. _Diagram: Un agente: una ventana atiborrada de todo y un menú de doce herramientas. Tras dividir, cada uno tiene una ventana pequeña y tres herramientas._ #### Context & Tool Overload (demasiado contexto, demasiadas herramientas) - **Qué es:** Dos límites de un solo agente: una ventana de contexto sobrecargada y un menú de herramientas demasiado largo. - **Por qué importa:** Un contexto sobrecargado baja la calidad, y un menú largo empeora la elección de herramienta en cada turno. - **Ejemplo:** Un agente de soporte guarda en su ventana facturación, documentación técnica y todo el historial, y además veinte herramientas. - **Ojo:** Primero prueba a estrechar las herramientas y limpiar el contexto de ese único agente: a veces basta. - **Relaciones:** Se arregla con **Context Isolation** y **Worker Agents** estrechos. ### 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. _Diagram: Una balanza: el multi-agent compensa solo cuando la ganancia de especialización pesa más que el coste de coordinación._ #### Coordination Cost (el precio de la coordinación) - **Qué es:** Todo lo necesario para que los agentes trabajen juntos: repartir, enrutar, pasar, ensamblar. - **Por qué importa:** La coordinación es en sí misma una fuente de complejidad y de fallos. - **Ejemplo:** Un relevo gana a un solo corredor solo si los traspasos del testigo están ensayados. - **Ojo:** Si pesa más que la ganancia, el multi-agent empeoró el sistema en vez de mejorarlo. - **Relaciones:** Se concreta en **Coordination Overhead** y **Compounding Error**. > **La pregunta de encuadre:** "¿Es esto de verdad demasiado para un solo agente (demasiadas herramientas, destrezas o contexto) como para que la especialización ayude más de lo que cuesta la coordinación?" > 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, y tiene que valer la ganancia. ## 2. El patrón del orchestrator La forma más común de un sistema multi-agent tiene un coordinador en el centro. Entender el orchestrator es entender casi todo sobre cómo se conectan estos sistemas. ### 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. _Diagram: El orchestrator divide el objetivo en subtareas y entrega cada una a su worker. No hace el trabajo de los especialistas._ #### Orchestrator (coordinador, orchestrator–worker) - **Problema:** Un objetivo grande que exige destrezas distintas no se puede entregar sin más a un agente estrecho. - **Idea:** Un agente líder divide el objetivo en subtareas y enruta cada una al worker adecuado. - **Ejemplo:** Un orchestrator de investigación reparte subtemas entre varios agentes investigadores. - **Coste:** Un agente más y una capa más donde algo puede romperse. - **Cuándo usarlo:** El trabajo se divide de verdad en piezas que necesitan destrezas o herramientas distintas. - **Relaciones:** **Plan-and-execute** a mayor escala; dirige a los **Worker Agents** mediante **Handoffs**; combina los resultados con **Assembly**. ### 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. _Diagram: Los hallazgos de tres workers se encuentran en el orchestrator: resuelve conflictos, quita duplicados y produce una sola respuesta._ #### Assembly (síntesis, combinar resultados) - **Qué es:** El paso en que el orchestrator convierte las salidas de los workers en un solo resultado. - **Por qué importa:** Sin un buen ensamblaje no obtienes una respuesta, sino un montón de piezas que no coinciden. - **Ejemplo:** Tres agentes investigaron tres subtemas; el orchestrator escribe un solo informe sin repeticiones. - **Ojo:** El ensamblaje se trata como un detalle, pero los conflictos y los duplicados afloran justo aquí. - **Relaciones:** La segunda mitad de **Orchestrator**; el paso final de **Parallel**. ### 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. _Diagram: Sobre los agentes está la capa de coordinación: enrutamiento, paso de contexto, ensamblaje, manejo de errores. Ella decide si el sistema funciona._ #### Coordination Layer (orquestación) - **Qué es:** El código y las reglas alrededor de los agentes: quién se ejecuta cuándo, con qué entrada, cómo se combinan los resultados. - **Por qué importa:** Que el sistema funcione se decide aquí, no en los agentes individuales. - **Ejemplo:** Agentes excelentes, pero un worker recibe la entrada equivocada y todo el sistema produce basura. - **Ojo:** Pulir los prompts de los agentes y dejar la coordinación al azar. - **Relaciones:** Incluye **Orchestrator**, **Handoff** y **Assembly**; se depura con **Multi-agent Tracing**. > **La pregunta del orchestrator:** "¿Hay un coordinador claro que descompone el objetivo, enruta cada pieza al agente adecuado y ensambla los resultados, o la coordinación ocurre por accidente?" > El orchestrator descompone el objetivo, enruta cada subtarea a un worker especializado y ensambla sus resultados. La capa de coordinación, y no los agentes individuales, es la arquitectura real. ## 3. Workers especializados Los agentes que dirige el orchestrator son más útiles cuando cada uno es estrecho. La disciplina de mantener a los workers enfocados es lo que hace fiable y comprobable a todo el sistema. ### 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. _Diagram: Un worker: entra una subtarea del orchestrator, dentro hay un prompt enfocado y un par de herramientas, y sale un resultado._ #### Worker Agent (agente especialista) - **Qué es:** Un agente con un trabajo estrecho, un prompt corto y pocas herramientas. - **Cómo funciona:** Recibe una subtarea clara del orchestrator, la hace y devuelve el resultado. - **Ejemplo:** Un agente que busca en la documentación, uno que programa, uno que verifica datos y uno que da formato. - **Ojo:** Poco a poco el worker recoge "un par de herramientas más" y vuelve a ser un generalista. - **Relaciones:** Dirigido por **Orchestrator**; comprobado con **Per-agent Evals**; sigue **Depth over Breadth**. ### 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. _Diagram: Cada worker tiene sus propios evals. Cuando uno falla, ves exactamente cuál, y lo arreglas sin tocar el resto._ #### Per-agent Evals (pruebas para cada worker) - **Qué es:** Un conjunto de pruebas aparte para cada worker, no solo para todo el sistema. - **Cómo hacerlo:** Para cada trabajo estrecho, sus propios ejemplos de "entrada → salida esperada" y una comprobación del resultado. - **Ejemplo:** Fallan los evals del verificador de datos: arreglas su prompt y dejas en paz a los demás agentes. - **Ojo:** Probar solo la salida final del sistema: cuando falla, no sabes qué agente tiene la culpa. - **Relaciones:** Funciona solo si cada **Worker Agent** es estrecho; complementa a **Multi-agent Tracing**. ### 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. #### Depth over Breadth (lo estrecho gana a lo amplio) - **Qué es:** Un agente estrecho que hace una cosa es más fiable que uno amplio que hace muchas. - **Por qué importa:** Ese es el sentido de la descomposición: no el número de agentes, sino lo estrechos que son. - **Ejemplo:** Un agente de "investigar y escribir el informe" no deja de fallar: se divide en "investigar" y "escribir". - **Ojo:** Arreglar un worker poco fiable con más herramientas: eso lo hace más amplio, no mejor. - **Relaciones:** La base de **Specialization** y **Worker Agent**. > **La pregunta del worker:** "¿Es el trabajo de cada agente lo bastante estrecho como para probarlo y confiar en él por sí solo, o algún worker sigue haciendo demasiado para ser fiable?" > Los worker agents son especialistas estrechos (un trabajo claro, un prompt enfocado, pocas herramientas), lo que hace a cada uno comprobable y digno de confianza. La profundidad en un trabajo supera a la amplitud en muchos. ## 4. Handoffs y contexto Los agentes valen lo que valga lo que se pasan entre sí. Cómo se mueven el trabajo y el contexto entre ellos, limpia o desordenadamente, decide si el sistema se mantiene coherente o se degrada en ruido. ### 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. _Diagram: Un handoff lleva la subtarea y el contexto del agente A al agente B. Un handoff confuso significa un resultado erróneo, incluso con un B fuerte._ #### Handoff (pasar trabajo entre agentes) - **Qué es:** El momento en que el trabajo y el contexto pasan de un agente a otro. - **Cómo funciona:** Orchestrator → worker, o agente → siguiente agente: la subtarea más el contexto que necesita. - **Ejemplo:** Un agente de investigación entrega a un agente redactor los datos que encontró y la tarea "escribe la sección". - **Ojo:** Un gran agente con mala entrada da un mal resultado: se culpa al agente, pero el fallo estaba en el handoff. - **Relaciones:** Hazlo como un **Clean Handoff**; hace posible **Context Isolation**; cada handoff es un paso de **Compounding Error**. ### 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. _Diagram: Arriba: al agente B le vuelcan todo el historial: otra vez sobrecargado. Abajo: un breve resumen de datos y la tarea: el contexto de B se mantiene limpio._ #### Clean Handoff (un briefing enfocado) - **Problema:** Pasar todo el historial sobrecarga el contexto del siguiente agente. - **Idea:** Pasar un resumen estructurado y corto: los datos necesarios + la tarea concreta. - **Ejemplo:** En vez de 40 turnos de conversación: "datos: …; tarea: escribe la sección de precios, en menos de 300 palabras". - **Coste:** Alguien tiene que decidir qué importa, y puede dejar caer por accidente algo necesario. - **Cuándo usarlo:** En cada handoff, por defecto. - **Relaciones:** La forma correcta de hacer un **Handoff**; es lo que entrega **Context Isolation**. ### 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. _Diagram: Tres salas: en cada una, el agente ve solo su propia tarea y sus materiales. Si le das todo a todos, vuelves a un solo agente sobrecargado._ #### Context Isolation (contextos separados y limpios) - **Qué es:** Cada agente trabaja en su propia ventana limpia, con solo su tarea dentro. - **Por qué importa:** No se acumula context rot como ocurre en un solo agente de larga ejecución. - **Ejemplo:** El agente revisor ve solo el borrador y los criterios, no los registros de búsqueda ni los intentos fallidos de código. - **Ojo:** Solo funciona con handoffs limpios; "todo para todos" lo destruye. - **Relaciones:** La respuesta a **Context & Tool Overload**; se apoya en **Clean Handoff**. > **La pregunta del handoff:** "En cada handoff, ¿paso un resumen limpio y enfocado de justo lo que necesita el siguiente agente, o vuelco todo el historial y recreo el problema del contexto sobrecargado?" > Los handoffs pasan trabajo entre agentes, y es 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 la división pretendía darle. ## 5. Sequential, parallel, hierarchical 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 hay que saber para estructurar la coordinación. ### 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. _Diagram: Un pipeline secuencial: borrador → edición → verificación de datos. El orden es siempre el mismo._ #### Sequential (pipeline, cadena de agentes) - **Problema:** El trabajo tiene etapas que deben ocurrir estrictamente en orden. - **Idea:** Una cadena de agentes: la salida de uno es la entrada del siguiente. - **Ejemplo:** Agente de borrador → agente de edición → agente de verificación de datos. - **Coste:** Más lento que parallel; un error en una etapa temprana viaja por toda la cadena. - **Cuándo usarlo:** Los pasos son fijos y dependen unos de otros. La forma más simple. - **Relaciones:** Como **Pipe-and-Filter** de los patrones de arquitectura; cada unión es un **Handoff**. ### 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. _Diagram: Fan-out: el orchestrator reparte cinco subtemas y los workers corren a la vez. Gather: los resultados se fusionan en uno._ #### Parallel (fan-out / gather) - **Problema:** Muchas piezas independientes, y hacerlas una a una tarda demasiado. - **Idea:** Entregar las piezas a varios agentes a la vez y luego reunir los resultados. - **Ejemplo:** Investigar cinco subtemas en paralelo y fusionar los hallazgos en un solo informe. - **Coste:** Más llamadas al modelo a la vez; el ensamblaje debe resolver conflictos entre resultados. - **Cuándo usarlo:** Las piezas no dependen unas de otras y la velocidad importa. - **Relaciones:** El último paso es **Assembly**; **Orchestrator** reparte en abanico y reúne. ### 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. _Diagram: Un orchestrator superior dirige a sub-orchestrators, y estos dirigen a sus propios workers. Tres capas de coordinación._ #### Hierarchical (orchestrators anidados) - **Problema:** La tarea es tan grande que un solo orchestrator no puede repartirla y mantenerla unida. - **Idea:** Un orchestrator superior delega en sub-orchestrators, cada uno con sus propios workers. - **Ejemplo:** Un gran proyecto de investigación: el agente superior lo divide en áreas, y cada área tiene su propio coordinador e investigadores. - **Coste:** La forma más compleja: más coordinación, más lugares donde fallar. - **Cuándo usarlo:** Solo cuando la tarea necesita de verdad descomposición anidada. Rara vez. - **Relaciones:** **Orchestrator** anidado dentro de sí mismo; dentro de cada capa, **Sequential** o **Parallel**. > **La pregunta del patrón:** "¿Encaja este trabajo en un pipeline fijo (sequential), en piezas independientes que corren a la vez (parallel) o en capas anidadas de coordinación (hierarchical), y estoy usando el más simple que encaja?" > Sequential encadena agentes en un pipeline fijo; parallel reparte en abanico el trabajo independiente y lo reúne; hierarchical anida orchestrators para tareas grandes. Usa la forma más simple que el trabajo realmente necesite. ## 6. Los modos de fallo multiplicados El multi-agent seduce y a menudo se usa de más. Más agentes no solo suman capacidad: multiplican las formas en que el sistema puede romperse, e ignorarlo es como estos sistemas fallan en silencio. ### 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. _Diagram: Un ejemplo ilustrativo: si cada paso tiene éxito el 95 % de las veces, una cadena de 10 pasos solo tiene éxito en torno al 60 %._ #### Compounding Error (error que se multiplica por la cadena) - **Qué es:** Las probabilidades de éxito se multiplican paso a paso, así que una cadena larga falla más. - **Por qué importa:** Cada agente nuevo y cada handoff es un multiplicador más por debajo de 1. - **Ejemplo:** 95 % por paso son cerca del 86 % en tres pasos y cerca del 60 % en diez. - **Ojo:** Suponer que más agentes siempre significa más capacidad. - **Relaciones:** Crece con cada **Handoff**; por eso **Sequential** se mantiene corto y **Hierarchical** es raro. ### 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. _Diagram: El mismo trabajo, pero la versión multi-agent añade encima enrutamiento, handoffs, ensamblaje y reintentos: más latencia y gasto._ #### Coordination Overhead (el coste extra de la orquestación) - **Qué es:** Llamadas extra al modelo, latencia y dinero gastados en enrutamiento, handoffs, ensamblaje y reintentos. - **Por qué importa:** El sistema puede volverse más lento y caro que un solo agente, sin volverse mejor. - **Ejemplo:** Una pregunta sencilla pasa por un orchestrator y tres workers en vez de por una sola llamada. - **Ojo:** No medir el coste y la latencia antes y después de dividir. - **Relaciones:** La forma concreta de **Coordination Cost**; un argumento a favor de **Single Agent by Default**. ### 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. _Diagram: Una traza de una petición: orchestrator, handoffs, agentes, ensamblaje. Se ve que falló el agente de código._ #### Multi-agent Tracing (observabilidad entre agentes) - **Qué es:** Un registro del camino de una petición por cada agente y cada handoff. - **Cómo hacerlo:** Un ID de petición compartido, un registro de cada handoff (qué se pasó, qué volvió), tiempo y coste por paso. - **Ejemplo:** La respuesta es errónea: la traza muestra que el agente de código recibió contexto incompleto en el handoff. - **Ojo:** Sin traza, el fallo está "en algún lugar del sistema", y arreglarlo a ciegas es casi imposible. - **Relaciones:** Cómo depuras la **Coordination Layer**; junto con **Per-agent Evals** muestra quién tiene la culpa. > **La pregunta del coste:** "¿Supera aquí la ganancia de especialización con claridad al coste multiplicado (más pasos que acumulan error, más latencia y gasto, rastreo más difícil), o estoy añadiendo agentes por reflejo?" > Más agentes multiplican los modos de fallo: más pasos que acumulan error, un sobrecoste de coordinación real y un rastreo mucho más difícil. El multi-agent por reflejo baja la fiabilidad, no la sube. ## 7. Usarlo bien El multi-agent es una herramienta potente para el problema adecuado y un error caro para el equivocado. Usarlo bien es sobre todo contención: dividir solo cuando un solo agente de verdad no puede con ello. ### 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í?" _Diagram: Empieza con un agente. Si le cuesta, estrecha sus herramientas y ajusta su contexto. Solo si eso sigue sin bastar: multi-agent._ #### Single Agent by Default (empieza con un agente) - **Qué es:** Empezar con un agente y dividir solo cuando de verdad no puede con ello. - **Por qué importa:** Los agentes extra añaden coste, latencia y modos de fallo sin ganancia. - **Ejemplo:** Un agente se pierde entre 20 herramientas: primero déjale las 5 que necesita, y solo entonces piensa en dividir. - **Ojo:** Preguntarse "¿se puede dividir esto?": casi todo se puede. - **Relaciones:** El contrapeso de **Coordination Overhead** y **Compounding Error**; la salida hacia **Orchestrator**, solo cuando de verdad hace falta. ### 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. #### Antes de pasarte a multi-agent - **¿Puede un solo agente hacer esto de verdad**, o se rompe de verdad bajo la carga? - **¿Hay un orchestrator claro** que descompone, enruta y ensambla? - **¿Es estrecho cada worker**: un trabajo, pocas herramientas, comprobable 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? #### Señales de que orquestas bien - Recurres al multi-agent **solo cuando un agente de verdad no puede con ello**. - Un **orchestrator** claro descompone, enruta y ensambla el trabajo. - Cada **worker es estrecho**: comprobable y digno de confianza por sí solo. - **Los handoffs son limpios**: pasan contexto enfocado y mantienen ajustada 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. ### 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. _Diagram: La cadena de conceptos del curso: de un agente al orchestrator, el patrón, los handoffs y los workers, y el coste que tira de vuelta hacia un solo agente._ ## Hoja de referencia: los 19 conceptos ### Por qué dividir - **Specialization** (agentes especializados): Agentes estrechos que hacen bien una sola cosa: la razón principal del multi-agent. - **Context & Tool Overload** (demasiado contexto, demasiadas herramientas): La ventana de un agente está atiborrada y su menú de herramientas es demasiado largo. - **Coordination Cost** (el precio de la coordinación): Repartir, enrutar, pasar, ensamblar: cuesta, y tiene que compensar. ### Orchestrator - **Orchestrator** (coordinador): Un agente líder divide el objetivo en subtareas y las entrega a los workers. - **Assembly** (síntesis): Combinar las salidas de los workers en un resultado: resolver conflictos, quitar duplicados. - **Coordination Layer** (orquestación): Quién se ejecuta cuándo, con qué entrada, cómo se combinan los resultados: la arquitectura real. ### Workers - **Worker Agent** (agente especialista): Un trabajo estrecho, un prompt corto, pocas herramientas. - **Per-agent Evals** (pruebas para cada worker): Prueba cada worker por separado: ve quién falló y arréglalo de forma aislada. - **Depth over Breadth** (lo estrecho gana a lo amplio): Un worker demasiado amplio para ser fiable: divídelo más, no le añadas herramientas. ### Handoffs - **Handoff** (pasar trabajo): El momento en que una subtarea y su contexto pasan de un agente a otro. - **Clean Handoff** (un briefing enfocado): Un resumen corto: los datos necesarios + la tarea, no todo el historial. - **Context Isolation** (contextos separados y limpios): Cada agente tiene su propia ventana limpia: sin context rot. ### Patrones - **Sequential** (pipeline): A → B → C en orden fijo. El más simple y predecible. - **Parallel** (fan-out / gather): Piezas independientes a la vez, luego reunir. Para ir rápido. - **Hierarchical** (orchestrators anidados): Orchestrators de orchestrators. El más potente y complejo: rara vez. ### Modos de fallo - **Compounding Error** (el error se multiplica): El éxito se multiplica por paso: más agentes, una cadena más larga, más fallos. - **Coordination Overhead** (coste extra): Enrutamiento, handoffs, ensamblaje, reintentos: más latencia y dinero. - **Multi-agent Tracing** (observabilidad entre agentes): Registra cada handoff para encontrar exactamente dónde se rompió. ### Práctica - **Single Agent by Default** (empieza con un agente): Divide solo cuando un agente bien construido de verdad no puede con ello. > El multi-agent es deliberado: divide solo cuando un agente de verdad no puede con ello, dale un orchestrator claro, mantén cada worker estrecho 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. Fin del curso exprés · 7 capítulos · 19 conceptos Lo siguiente es la práctica: toma una tarea que te tienta dividir entre agentes y primero intenta que la haga un solo agente bien construido: estrecha sus herramientas, ajusta su contexto. Si de verdad no puede con ella, descomponla: un orchestrator claro, dos o tres workers estrechos, handoffs limpios, el patrón más simple que encaje. Luego rastrea una ejecución de punta a punta y mira dónde caen de verdad el coste y los errores. La disciplina hace clic en el momento en que sientes cuánto cuesta la coordinación y la reservas para cuando la especialización de verdad compensa. Pero mantén una idea por encima de las demás: más agentes multiplican tanto la capacidad como los modos de fallo. Divide solo cuando un agente no basta, y cuando lo hagas, la estructura que los rodea es todo el juego.