Un agente que funciona solo es fácil. Un sistema donde varios agentes coordinan trabajo es donde la mayoría de la gente se pierde. Hay tres patrones que resuelven el 90% de los casos.
El problema de escalar agentes
Un solo agente con acceso a todas las herramientas y todo el contexto colapsa rápido. El contexto window se llena, las instrucciones se mezclan, y los errores se propagan sin control. La solución no es prompts más grandes, sino sistemas más pequeños bien coordinados.
Patrón 1: Orchestrator + Workers
El orchestrator recibe la tarea de alto nivel, la descompone y delega a workers especializados. Cada worker tiene un scope limitado y herramientas específicas.
Orchestrator: "Analiza este PR y escribe el reporte"
→ Worker A: revisa cambios de código (tools: Read, Bash/git)
→ Worker B: verifica tests (tools: Bash/npm test)
→ Worker C: redacta reporte (tools: Write)
El orchestrator recibe los outputs y los ensambla. Ningún worker necesita saber qué hacen los demás.
Patrón 2: Pipeline secuencial
Para procesos donde cada paso depende del anterior. Los datos fluyen de agente en agente, cada uno transformando el output del anterior.
Este patrón es simple pero poderoso para procesos ETL, pipelines de contenido, o cualquier workflow donde el orden importa. El riesgo es que un error en un paso bloquea todo el pipeline — hay que diseñar los handoffs con validación explícita.
Patrón 3: Parallel fan-out
Cuando tienes tareas independientes que se pueden ejecutar a la vez. El orchestrator las lanza en paralelo y espera todos los resultados antes de continuar.
La implementación con la API de Claude es directa: múltiples llamadas asíncronas con asyncio.gather() en Python o Promise.all() en JS. El contexto de cada agente es independiente, así que no hay riesgo de interferencia.
La regla práctica
Empieza con un agente. Cuando notes que el contexto window se llena o que el agente está mezclando preocupaciones distintas, es el momento de separar. Cada split debería tener una razón concreta — no abstracciones prematuras.