Fan-out / fan-in
El patrón más común: un orquestador distribuye (fan-out) tareas a N subagentes y luego reúne (fan-in) los resultados. Ejemplo clásico: analizar 5 módulos del codebase en paralelo y consolidarlos en un único informe.
La clave del fan-out/in es que todas las tareas distribuidas son independientes. El fan-in es el momento en que el padre lee todos los resultados y los sintetiza. Si un subagente falla, los demás no se ven afectados.
En 1 frase: fan-out distribuye el trabajo, fan-in reúne los resultados. El patrón más básico y poderoso.
Pipeline secuencial
Cuando las tareas dependen unas de otras, usa un pipeline: el Agent A analiza, pasa el resultado al Agent B, que planifica y se lo pasa al Agent C, que ejecuta. Cada agente tiene un alcance claro y recibe el output del anterior como input. Es como una línea de montaje.
Ejemplo de pipeline
Agente 1 (Análisis): "Lee src/ y enumera todos los problemas de rendimiento" → Agente 2 (Plan): "Dados estos problemas, crea un plan de corrección priorizado" → Agente 3 (Ejecución): "Ejecuta las 3 primeras correcciones del plan"
En 1 frase: pipeline = tareas encadenadas en las que el output de una alimenta el input de la siguiente.
Explora, Planifica, Ejecuta
Un pipeline específico es muy eficaz: Explora (un agente de solo lectura mapea el codebase y entiende la estructura), Plan (otro agente recibe el mapa y crea un plan detallado de cambios), Ejecuta (un tercer agente con acceso de escritura implementa el plan). Cada fase usa el tipo de agente más adecuado.
En 1 frase: Explore-Plan-Execute separa el análisis, la planificación y la acción en agentes especializados.
Specialist agents
En lugar de un único agente generalista, crea agentes especialistas: uno solo para pruebas, otro solo para documentación y otro para seguridad. Cada uno recibe un system prompt enfocado en su dominio, lo que mejora la calidad del resultado. Es como tener un equipo donde cada persona tiene su especialidad.
Agente: Pruebas
"Eres especialista en testing. Ejecuta las pruebas, analiza los errores y sugiere correcciones."
Agente: Seguridad
"Eres security reviewer. Analiza el código en busca de vulnerabilidades del OWASP Top 10."
Agente: Docs
"Eres technical writer. Actualiza la documentación para reflejar los cambios recientes."
En 1 frase: los agentes especialistas con prompts enfocados ofrecen mejores resultados que un agente generalista que hace de todo.
Manejo de errores distribuido
En sistemas multi-agent, los fallos son inevitables. Los patrones de resiliencia incluyen: retry con backoff (volver a lanzar el subagente con un prompt ajustado), fallback (si el especialista falla, lo intenta un generalista), y circuit-breaker (si 3+ subagentes fallan en la misma tarea, detenerse y escalar el problema a una persona).
En 1 frase: retry, fallback y circuit-breaker garantizan resiliencia en un sistema de múltiples agentes.
Control de costos
Cada subagente consume tokens. Estrategias de control: limitar max_tokens por subagente, usar modelos más pequeños (Haiku) para tareas sencillas como lint o formatting, y medir el ROI antes de paralelizar. Si 5 subagentes cuestan $2 pero te ahorran 30 minutos, vale la pena. Si cuestan $2 y te ahorran 2 minutos, no.
En 1 frase: controla los costos limitando los tokens, usando modelos más pequeños y midiendo si el paralelismo compensa.
🧾 Resumen del módulo
Siguiente módulo:
4.4 — Git con IA: commits semánticos, staging inteligente y conflictos de merge.