Tres patrones cubren el 90% de los casos reales: paralelo independiente (todos al mismo tiempo, sin dependencias), pipeline (La entrega de A a B, que entrega a C) y fan-out (uno activa muchos que convergen en un resultado). Entender las diferencias entre ellos — especialmente el costo oculto de agent teams — es lo que separa a quienes diseña sistemas de quien solo usa subagentes.
↑ Tres topologías: cada una tiene distintos casos de uso, costos y latencia.
Contenido detallado
⚡ Paralelo independiente
El patrón más simple y potente cuando los trabajos no dependen uno del otro. Tienes N tareas que pueden ejecutarse al mismo tiempo, cada una en su propio subagente, y el maestro recopila los resultados al final. Ningún subagente necesita esperar a otro: el tiempo total es el de más lento, no la suma de todos.
📐 La regla de los 10+ archivos
Heurística práctica: si el trabajo exige leer 10 o más archivos — o revisar 10 o más capítulos, PDF, o cualquier unidad de trabajo: probablemente estás ante un candidato para paralelizar. Por encima de ese volumen, el costo de hacerlo en secuencia supera la sobrecarga de orquestarlo.
# vs
10 archivos en paralelo (uno por subagente): ~4 min
Maestro identifica N trabajos independientes
Verifica: "¿cada job puede ejecutarse sin conocer el resultado de los demás?" Si es así, es candidato.
Se activan todos a la vez
Cada subagente abre su propia ventana. Todos se ejecutan al mismo tiempo, sin cola.
Recopila los informes
El maestro espera a que todos terminen y sintetiza. Solo ves el resultado final, claro.
N trabajos sin dependencias entre sí que se ejecutan al mismo tiempo, cada uno en su propio subagente.
Es el patrón que produce aumentos reales de velocidad: el tiempo total es mayor, no la suma. Saber identificar cuándo aplicarlo es la habilidad central de este módulo.
independencia · ejecución simultánea · tiempo del más lento · regla de los 10+ archivos.
🔗 Pipeline: A → B → C
Cuando el resultado de un agente es la entrada del siguiente, tienes un pipeline. Aquí no hay paralelismo: el flujo es secuencial por necesidad. La ventaja no es la velocidad, sino especialización. Cada etapa tiene un agente enfocado solo en eso, con herramientas e instrucciones propias. Investigar es diferente de redactar; redactar es diferente de revisar.
✓ Usa pipeline cuando
- ✓La salida de A es la entrada de B (dependencia real)
- ✓Cada etapa necesita herramientas diferentes
- ✓El orden importa (investigación → borrador → revisión)
- ✓Quieres separar claramente las responsabilidades
✗ No uses pipeline cuando
- ✗Los trabajos son independientes (desperdicio de latencia)
- ✗La dependencia es falsa: solo quieres serializar
- ✗La tarea es lo bastante simple para un solo agente
📊 Ejemplo canónico: investigación → borrador → revisión
Cada agente puede usar Haiku, Sonnet o Opus según la complejidad de la etapa.
Cadena de agentes en la que la salida de uno se convierte en la entrada del siguiente. Secuencial por dependencia.
La especialización por etapa supera a un único agente generalista. Separar responsabilidades reduce errores y facilita los ajustes finos.
dependencia real · especialización por etapa · pipeline ≠ paralelo · el orden importa.
📡 Fan-out: uno envía a muchos, uno recopila
Fan-out es paralelo con convergencia explícita: el director lanza N subagentes y luego sintetiza sus informes en un único resultado. Es el patrón de la «demo de las 5 personas»: cada subagente usa una perspectiva distinta, pero todos entregan su trabajo al mismo director, que compone la visión final.
🎯 Qué diferencia el fan-out del paralelismo puro
Paralelismo puro
Jobs diferentes que no necesitan combinarse. Ej.: compilar 15 módulos.
Fan-out
Múltiples perspectivas sobre el mismo objeto, sintetizadas en un informe. Ej.: 5 personas revisan el mismo libro.
💡 Fan-out por 15 capítulos
¿Necesitas revisar un libro de 15 capítulos? Fan-out: 1 subagente por capítulo, todos trabajando al mismo tiempo. El maestro recopila 15 informes y produce el resumen editorial. Sin fan-out, leerías 15 capítulos en serie en el mismo contexto, agotándolo antes del capítulo 10.
Variante del paralelismo en la que el maestro converge explícitamente los resultados de N subagentes en una única salida.
Es el patrón para obtener diversidad de perspectivas (múltiples enfoques, revisión adversarial, cobertura completa). La síntesis final es lo que aporta valor.
convergencia explícita · múltiples perspectivas · síntesis final · fan-out ≠ paralelo sin coordinación.
💬 Subagente × Agent Teams: el costo oculto
Agent teams son cuando varios agentes conversan entre sí; cada mensaje de un agente a otro cuesta tokens. Un subagente normal no conversa: recibe instrucciones, trabaja de forma aislada y entrega un informe. En agent teams, la conversación en sí tiene un costo — y ese costo puede superar el valor entregado si no se controla.
✓ Subagente (predeterminado)
- ✓Recibe un briefing, trabaja de forma aislada
- ✓Costo: solo el trabajo realizado
- ✓Predecible: 1 tarea → 1 costo
- ✓Contexto del maestro protegido
⚠️ Agent Teams — cuidado
- !Los agentes conversan entre sí: cada turno = costo
- !El costo puede crecer geométricamente
- !Es difícil auditar qué se decidió y dónde
- !¿El valor lo justifica? Mide antes de adoptar
⚠️ Costo ~15× — no por los agentes, sino por la conversación
Un sistema multiagente bien hecho cuesta ~15× más que uno de agente único. La mayor parte de ese costo no corresponde al trabajo de los agentes: es la sobrecarga de coordinación: prompts de briefing repetidos, contexto compartido, mensajes de estado. Usa equipos de agentes solo cuando el resultado lo justifique claramente. Si tienes dudas, usa subagentes normales.
La distinción entre subagentes que trabajan aislados (baratos) y agent teams, donde los agentes conversan entre sí (costo por turno).
La diferencia afecta directamente el costo de la sesión. Si la entiendes mal, puede llevar a sesiones 10× más caras sin un resultado proporcionalmente mejor.
turno de conversación = costo · aislamiento vs. comunicación · ~15× de sobrecosto · medir antes de adoptar.
🧱 La regla de los 10+ archivos y el muro de contexto
Existe un punto de inflexión en el que continuar en el mismo contexto se vuelve contraproducente. Lo llamamos límite de contexto: el punto en que el modelo empieza a perder información anterior, mezclar datos de distintos archivos o confundirse con las referencias cruzadas. La regla práctica: al superar los 10 archivos, piensa en dividir.
📏 Señales de la pared de contexto
- 1 El modelo "olvida" un archivo que mencionaste 5 archivos atrás.
- 2 La respuesta mezcla nombres de archivos diferentes.
- 3 El tiempo de respuesta aumenta sin que el trabajo sea más complejo.
- 4 La barra de contexto del maestro supera el 60% — señal de alerta.
💡 Jobs independientes por unidad de trabajo
Traducción práctica: «15 capítulos de un libro» = 15 jobs independientes. «20 archivos de código para auditar» = 20 jobs. «8 informes de ventas para analizar» = 8 jobs. Cada job se convierte en un subagente. El maestro nunca lee los archivos — solo lee los informes de los subagentes.
El umbral práctico (10+ archivos) a partir del cual un único contexto empieza a degradarse y se vuelve necesario dividirlo en subagentes.
Sin esta heurística, usas subagentes demasiado tarde, después de que el contexto ya se degradó. Con ella, decides antes de que aparezca el problema.
límite de contexto · regla de 10+ · tareas por unidad · el director lee informes, no archivos.
📚 Tareas independientes: el caso de los 15 capítulos
El ejemplo de los 15 capítulos es la mejor ilustración práctica del patrón. Tienes un libro con 15 capítulos y quieres saber: "¿dónde está el argumento más débil?". Hacerlo en un único contexto significa leer los 15 capítulos en serie: el modelo empieza a mezclar los primeros capítulos con los últimos. Con 15 subagentes en paralelo, cada uno lee un capítulo y entrega un informe de 1 página. El maestro lee 15 informes de 1 página y los sintetiza.
1 subagente / capítulo
15 ventanas abiertas simultáneamente. Cada una lee 1 capítulo con total concentración.
15 informes de 1 pág.
Cada subagente devuelve una evaluación concisa de su capítulo.
Maestro sintetiza
Lee 15 páginas (no 15 capítulos) e identifica el argumento más débil.
📊 Qué cambia en el contexto del maestro
Sin subagentes
Contexto saturado, lectura degradada
Con 15 subagentes
Maestro tiene libertad para razonar
Aplicación concreta del paralelismo independiente: 1 subagente por unidad de trabajo (capítulo, archivo, informe), todos en paralelo.
Muestra el beneficio real en la práctica: el maestro recibe 15 resúmenes de 1 página en vez de procesar 15 capítulos directamente. Mayor calidad y velocidad.
1 sub por unidad · informe = resumen destilado · el maestro lee poco · contexto protegido.
🗺️ Cómo elegir la topología adecuada
Hay una secuencia de tres preguntas para llegar a la topología correcta. Respóndelas en orden: la primera respuesta «sí» determina el patrón. Si ninguna aplica, probablemente basta con un solo agente.
¿Los trabajos son independientes entre sí?
Si sí → Paralelismo independiente (o fan-out si necesitas sintetizar).
¿La salida de un job es la entrada del siguiente?
Si sí → Pipeline (cadena A → B → C).
¿Los agentes tendrían que conversar entre sí?
Si sí → Agent Teams (costo +). Solo si el valor lo justifica. Si no, rediseña la arquitectura como paralelo + síntesis.
💡 La regla de oro
Si puedes dividir el problema en partes que no necesitan conversar, usa el paralelismo. Si la salida de una parte es la entrada de la siguiente, usa un pipeline. Si las partes necesitarían debatir, piénsalo muy bien antes de usar agent teams y considera si un maestro bien instruido no lo resolvería a menor costo.
El marco de 3 preguntas para elegir entre paralelo, pipeline, fan-out o agent teams.
Saber elegir la topología adecuada marca la diferencia entre un sistema elegante y barato y uno lento y costoso. Es la habilidad de diseño central de la Trilha 3.
independencia → paralelo · dependencia → pipeline · conversación → agent teams (costo +) · un maestro bien instruido como alternativa.
Ejemplo real: tabla estándar → caso de uso
La tabla de abajo asigna los cuatro patrones a casos concretos. Úsala como referencia rápida al diseñar un sistema. Para cada caso, la columna «¿Por qué?» presenta el argumento decisivo.
| Estándar | Caso de uso | ¿Por qué? | Costo relativo |
|---|---|---|---|
| En paralelo | Auditar 20 archivos de código | Archivos independientes, sin dependencias entre sí | Bajo ✓ |
| Pipeline | Investigación → borrador → revisión del artículo | La salida de cada etapa se convierte en la entrada de la siguiente | Medio |
| Fan-out | 5 personas revisan el mismo libro | Múltiples perspectivas, convergencia explícita | Medio |
| Fan-out | 15 capítulos analizados en paralelo | Cada capítulo es independiente, con una síntesis al final | Medio |
| Agent Teams | Negociación entre agentes especialistas | Los agentes necesitan intercambiar información entre sí | Alto ⚠️ |
| Agente único | Responder 1 pregunta sobre 1 archivo | El overhead de orquestación no se justifica | Mínimo ✓ |
---
name: chapter-auditor
description: Revisa um único capítulo de texto em busca
de argumentos fracos, inconsistências e lacunas.
Use quando o maestro precisar auditar um capítulo
isolado (padrão fan-out de N capítulos).
tools: Read # só lê o arquivo do capítulo
model: haiku # rápido e barato por capítulo
---
You are a critical editor. You receive ONE chapter.
Identify: weakest argument, factual gaps, unclear sections.
Return a structured report: 3 bullets max. Be blunt.
Prompts listos (copia y pega)
Tres prompts para que identifiques y uses topologías en la práctica. El patrón: describe el problema, señala la dependencia (o su ausencia) y pide la topología adecuada.
Tenho 20 arquivos de código para auditar. Cada um é
independente dos outros. Qual topologia de subagentes
devo usar? Justifique e mostre como estruturar o briefing
do maestro para disparar todos em paralelo.
Use fan-out: dispare 1 subagente por capítulo para revisar
os 15 capítulos em paralelo. Cada sub deve retornar um
relatório de no máximo 3 bullets: argumento mais fraco,
lacuna factual, seção confusa. Sintetize no final.
Monte um pipeline de 3 agentes para criar um artigo:
Agente A: pesquisa e extrai 10 fontes sobre [tema].
Agente B: recebe as fontes de A e escreve o rascunho.
Agente C: recebe o rascunho de B e revisa para publicação.
Use Haiku em A, Sonnet em B e C.
Pantalla simulada: fan-out de 5 capítulos
Aquí está la terminal con un fan-out de 5 capítulos en marcha. El director inició 5 subagentes al mismo tiempo; cada uno lee 1 capítulo con Haiku. Observa: el contexto del director está en 9% — todo el trabajo pesado de lectura está en las ventanas de los subagentes.
↑ Recreación ilustrativa del terminal. 5 capítulos en paralelo con Haiku; el maestro usa Sonnet y el contexto queda casi intacto.
Ejercicio
Tres problemas a continuación. Para cada uno, elige la topología correcta (paralelo, pipeline, fan-out o agente único) y justifica en 1 frase por qué descartaste las otras.
Problema 1
Tienes 30 informes de ventas mensuales de distintas sucursales. Quieres identificar qué sucursal tuvo la mayor caída del margen en los últimos 3 meses. Cada informe es un PDF independiente de ~20 páginas.
Problema 2
Quieres crear una publicación de blog de alta calidad sobre un tema técnico. El flujo natural es: primero investigar fuentes confiables, luego escribir el borrador con base en las fuentes y, después, revisar el borrador final.
Problema 3
Creaste una landing page y quieres recibir comentarios desde 4 perspectivas diferentes: conversión (copywriter), SEO (especialista en búsquedas), accesibilidad (auditor WCAG) y diseño (diseñador UX).
✅ Criterio de verificación
- →Problema 1: Fan-out (30 PDFs independientes → 30 subagentes → síntesis). Paralelismo puro si no hubiera que converger.
- →Problema 2: Pipeline (investigación → borrador → revisión son dependencias reales; la salida de cada etapa alimenta la siguiente).
- →Problema 3: Fan-out (4 perspectivas independientes sobre el mismo objeto → convergencia en un informe de comentarios).
Si justificaste por qué NO usaste equipos de agentes en los tres casos, lo hiciste perfecto.
Ejemplo resuelto — Problema 1
Topología: Fan-out. ¿Por qué? 30 PDFs independientes — cada subagente lee 1 PDF y devuelve «sucursal X, caída del Y% en el mes Z». El maestro recopila 30 líneas e identifica la mayor caída. Descarté el pipeline porque no hay dependencia entre los PDF. Descarté los agent teams porque los agentes no necesitan intercambiar información entre sí.
✅ Resumen del módulo
Fin de la Ruta 3 — siguiente paso:
Ruta 4 — Avanzado y cross-ambiente: arquitectura multiagente a escala, comparación de modelos por función, seguridad y subagentes en Codex.