Orquestación de Flujos

Qué incluye este pack

Este pack reúne los ocho motores de workflow nivel-producción que los equipos IA usan cuando un prompt-en-loop deja de bastar. Cada uno resuelve el mismo trío — agendar, reintentar, observar — con ergonomía distinta. Elige por dónde ya vive tu equipo (Python, Node, no-code, JVM).

Todos open source y auto-alojables. La mayoría tiene tier SaaS, pero este pack documenta primero el path OSS.

Por qué importa la orquestación para agentes IA

Los prompts son deterministas la primera vez y cara o cruz después. Añade una acción real — llamar API, escribir DB, mandar Slack — y "falló una vez a las 3am" se vuelve evento semanal. Un motor de workflow resuelve tres cosas:

1. Idempotencia. Los steps pueden re-ejecutarse a salvo. Si la llamada LLM tuvo éxito pero el siguiente step crasheó, el retry no re-cobra la API.
2. Backoff y dead-letter. Steps fallidos reintentarán con backoff exponencial, luego caen en DLQ donde un humano inspecciona.
3. Observabilidad. Cada step queda registrado con inputs, outputs, latencia y costo. Cuando el agente hace algo raro puedes replayear el contexto exacto que vio.

Sin esto, tu agente es un Jupyter notebook con pasos extra. Con esto, es un servicio.

Instala en un comando

# Instala el pack completo (manifiestos para los 8 motores)
tokrepo install pack/workflow-orchestration

# O elige el que usa tu equipo
tokrepo install n8n
tokrepo install prefect
tokrepo install inngest

El manifiesto TokRepo te da puntos de partida Docker Compose / Helm más defaults agente-amigables (claves de idempotencia, políticas de retry, hooks de observabilidad). Usa tokrepo uninstall <slug> para retirar.

Trampas comunes

• Tratar retries como infinitos. Los counts default en la mayoría son 3–5. Si tu LLM provider tiene mala hora, quemas el presupuesto y aún fallas. Cap a 3 para llamadas LLM pagadas y rutea el fallo a un fallback más lento.
• Claves de idempotencia mal hechas. Error común: usar request_id que cambia por retry. Usa hash de input para que retries deduplicen contra la misma tarea lógica.
• Falta observabilidad de costo de tokens. Los orquestadores vanilla registran latencia pero no gasto LLM. Envuelve la llamada al modelo para emitir tokens_in / tokens_out / cost_usd por step, si no te pasas del presupuesto sin saber qué workflow lo hizo.
• Granularidad de scheduler equivocada. Motores cron-based (n8n, Activepieces) sufren con triggers sub-minuto. Si necesitas event-driven sub-segundo, usa Inngest, Trigger.dev o Temporal.
• Alojar el motor en el mismo nodo que el agente. Un agente desbocado te OOM-eará el orquestador. Corre el motor en nodo o contenedor separado con límites duros de memoria.

Cuándo este pack solo no basta

La orquestación es la capa de durabilidad. No te da el agente, ni el gateway LLM, ni el eval. Combina con:

• Python Agent Frameworks para el código del agente que corre dentro de cada step
• MCP Server Stack si quieres que los triggers del orquestador sean llamables por agentes IA vía MCP
• LLM Eval & Guardrails para meter un step de eval en cada workflow antes de que la salida llegue a producción

Juntos esos cuatro packs son el stack mínimo para cualquier workflow IA que dejes correr sin supervisión.