Orchestration
La orquestación es el patrón por encima del agente único: pipeline (secuencia fija), supervisor (un agente comanda N) o swarm (N agentes se autoorganizan). Define quién habla con quién, cuándo y en qué orden.
Qué es
La orquestación coordina múltiples agentes (o múltiples etapas de un agente) en un flujo mayor. Mientras los agent frameworks tratan el loop interno de un agente, la orquestación trata el meta-loop: quién entra, quién sale, cuánto dura, dónde se persiste el estado.
La pregunta que responde la orquestación no es 'qué hace este agente', sino 'cómo conversa este agente con el siguiente'. Sin orquestación, cada agente se vuelve una isla y el único pegamento entre ellos es copiar y pegar texto.
Los tres patrones clásicos
Tres patrones cubren el 90% de los casos reales. La elección entre ellos depende de quién decide el siguiente paso:
pipeline: secuencia fija. Cada etapa recibe la salida de la anterior; el orden se conoce en tiempo de diseño. Buena para ETL con LLM, preprocesamiento, o cualquier caso donde la división del trabajo es clara.
supervisor: un agente (el supervisor) mira el estado y decide a qué subagente llamar ahora. La estructura existe, pero el camino se decide en runtime. Bueno para flujos con ramas dependientes del contexto.
swarm: N agentes se coordinan por mensajes, sin dueño central. Más flexible, más difícil de auditar; reservado para exploración o tareas mal definidas.
pipeline A -> B -> C -> D
orden fijo, costo predecible, fácil de auditar
supervisor A (decide) -> B o C -> A (decide de nuevo)
rama dinámica, costo variable, el supervisor es punto único de falla
swarm A <-> B <-> C <-> D
sin dueño, más caro, más difícil de reproducirEstado y checkpoint: cómo sobrevivir a las fallas
Los agentes son flaky por naturaleza: las APIs externas caen, los modelos devuelven malas respuestas, los timeouts ocurren a mitad del flujo. Sin checkpoint, una falla de 5 minutos significa empezar de cero, con el prompt gastado y el dinero quemado.
El checkpoint es el acto de persistir el estado del flujo en un almacenamiento durable después de cada etapa, con un ID único. Cuando la ejecución se reinicia (por un crash, un deploy o una reanudación manual), el runtime lee el último checkpoint y continúa desde donde quedó, sin repetir trabajo ya hecho.
Temporal y Prefect modelan esto como un workflow durable: cada función puede ser async, y el runtime sabe reejecutar desde el punto de falla. LangGraph expone el mismo concepto como thread_id con persistencia en Redis o Postgres.
from temporalio import workflow, activity
from datetime import timedelta
@activity.defn
async def extract(pdf_url: str) -> dict:
return {'text': '...'}
@activity.defn
async def summarize(text: str) -> str:
return 'resumen'
@workflow.defn
class ReportFlow:
@workflow.run
async def run(self, pdf_url: str) -> str:
# Cada execute_activity se vuelve un paso persistido por Temporal;
# si el worker cae a mitad, el workflow se reanuda desde el punto de falla
# sin repetir la actividad ya concluida.
extracted = await workflow.execute_activity(
extract,
pdf_url,
start_to_close_timeout=timedelta(minutes=2),
)
return await workflow.execute_activity(
summarize,
extracted['text'],
start_to_close_timeout=timedelta(minutes=2),
)Pipeline con LangGraph: supervisor + subagentes
LangGraph permite modelar supervisor y pipeline en el mismo grafo: cada nodo es una función (o un subagente), y cada arista condicional lleva la lógica de 'qué nodo ahora'. El grafo es suficientemente determinístico para auditar y suficientemente flexible para reaccionar al estado.
En el ejemplo de abajo, un orquestador decide entre llamar a 'researcher' o a 'writer' según el estado; cada uno de ellos es un subagente con su propio loop interno.
import { StateGraph, END } from '@langchain/langgraph';
type S = { messages: any[]; stage: 'pending' | 'researched' | 'written' };
async function orchestrator(s: S) {
if (s.stage === 'pending') return 'researcher';
if (s.stage === 'researched') return 'writer';
return END;
}
const graph = new StateGraph<S>({ channels: { messages: [], stage: 'pending' } })
.addNode('orchestrator', orchestrator)
.addNode('researcher', async (s) => ({ ...s, stage: 'researched' as const }))
.addNode('writer', async (s) => ({ ...s, stage: 'written' as const }))
.addEdge('__start__', 'orchestrator')
.addConditionalEdges('orchestrator', (s) => s.stage,
{ researcher: 'researcher', writer: 'writer', written: END, [END]: END })
.addEdge('researcher', 'orchestrator')
.addEdge('writer', 'orchestrator')
.compile({ checkpointer: redisCheckpointer });Dónde la orquestación se encuentra con el resto del sistema
- colas y workers: la orquestación convierte llamadas largas en jobs asíncronos; cada etapa se vuelve un worker
- idempotencia por diseño: un checkpoint sin idempotencia significa reejecutar y duplicar efectos secundarios
- observabilidad: cada etapa emite métricas, logs y spans; sin eso, depurar multiagente es adivinar
- human-in-the-loop: en flujos críticos, el supervisor pausa y espera aprobación antes de la siguiente etapa
Limitaciones
- el orquestador es un lugar donde se acumulan malas decisiones; un supervisor mal calibrado se vuelve un loop infinito
- el checkpoint tiene costo: cada persistencia agrega latencia y acoplamiento a una base de datos
- el swarm y el supervisor flexible son difíciles de reproducir; el mismo prompt puede dar flujos distintos
- el tooling todavía es joven: Temporal es sólido para código determinístico, pero el soporte para LLM dentro de él es reciente
conexiones en el mapa
- Agent frameworksse coordina conOrchestration
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
Estudia antes
pon a prueba lo que entendiste
Cargando preguntas…