Patrones de orquestación de agentes
Agente único, pipeline secuencial, fleet en paralelo, arbitraje por jueces. Compromisos al usar cada uno en producción.
He puesto en producción cuatro patrones de orquestación durante el último año. Cada uno resuelve un problema distinto. Ninguno es la respuesta correcta para todo.
Agente único: una llamada al modelo, una respuesta. Sin orquestación. Úsalo cuando la tarea cabe en un prompt y el modelo es lo bastante listo. El 90 % de los problemas de "necesitamos un agente" son esto con pasos extra.
Pipeline secuencial: el modelo A produce, el B revisa, el C pule. El estado fluye en línea. Úsalo cuando cada etapa tiene un objetivo distinto y quieres que cada modelo se especialice. Compromiso: las latencias se acumulan. Tres etapas de 3 s son 9 s en total. Los usuarios lo notan.
Fleet en paralelo: N modelos atacan el mismo problema desde ángulos distintos, los resultados se fusionan. Úsalo cuando la diversidad de perspectiva supera la profundidad de un solo modelo. agent-fleet hace esto para code review (analista + crítico + research, todos ven el mismo diff, escriben tres informes, un paso de síntesis los fusiona). El coste se acumula pero la latencia sigue siendo de una sola etapa. Compromiso: la calidad de la síntesis pesa más que la calidad individual.
Arbitraje por jueces: los candidatos producen, un juez los rankea. Úsalo cuando "mejor de N" es el framing correcto. darwin-agents hace esto para evolución de prompts, el juez es un modelo distinto al de los productores. Compromiso: el sesgo del juez se convierte en un eje oculto. Si tu juez es GPT-5 y tus productores son Claude, obtienes las preferencias de GPT-5.
El error que veo una y otra vez en demos de startups de agentes: fleet en paralelo para un problema que pedía agente único. Tres modelos dando respuestas ligeramente distintas a "resume este artículo" no es mejor que uno solo. Es peor, porque ahora hay que fusionarlas y la fusión introduce ruido.
Heurística del coste de orquestación: cada modelo extra multiplica la factura por 2, la latencia por 1,5 y añade un modo de fallo nuevo. Si la versión simple funciona, usa la versión simple. Añade complejidad solo cuando puedas nombrar la mejora concreta.
El patrón en el que más confío para problemas nuevos: empieza con agente único, mide dónde falla, añade la mínima orquestación que aborda ese modo de fallo. La mayoría de proyectos se quedan en agente único o pipeline secuencial. El fleet en paralelo es para code review, investigación multi-perspectiva y problemas con forma de debate. El arbitraje por jueces es para optimización de calidad de prompts y grading de contenido.