Qué es aquí realmente un flujo de trabajo
La mayoría de las herramientas de «flujo de trabajo» en el espacio de la IA son cadenas de prompts con una capa fina encima. El constructor de ToRun es un grafo acíclico dirigido (DAG) de pasos tipados: conectas invocaciones de modelo, llamadas a herramientas, ramas condicionales, bucles y subflujos en un grafo, y el motor los ejecuta en orden de dependencia, en paralelo donde el grafo lo permite.
Cada paso es una entidad de primera clase con su propia configuración: el tipo de paso (llamada a LLM, búsqueda web, ejecución de código, generación de imagen, recuperación, transformación, etc.), su esquema de entrada, su política de error (fallar rápido, reintentar con espera, saltar a la alternativa), un tope de presupuesto de ejecución por paso y un tiempo límite.
El enrutado de modelo dentro de cada paso de LLM pasa por la misma tubería de capacidades que todo lo demás en ToRun. Declaras lo que necesitas — salida estructurada, visión, uso de herramientas, razonamiento, una ventana de contexto de al menos N tokens — y el ejecutor resuelve el modelo que mejor encaja entre los proveedores disponibles en ese momento. Si tu proveedor preferido devuelve un 5xx, la cadena de reserva toma el relevo automáticamente.
Ejecutores con calidad primero y qué significa en la práctica
Cuando ejecutas un flujo, el ejecutor elige deliberadamente modelos de nivel de calidad en lugar de la opción más barata. Hay dos razones: las automatizaciones producen artefactos (informes, contenido generado, código) que nadie revisa de inmediato, así que los errores de calidad se acumulan en silencio; y a volumen moderado la diferencia de coste es menor que el precio de una mala salida que exige repetir la ejecución o corregir a mano.
En la práctica esto significa que un flujo de «resumir investigación y redactar un informe» preferirá un modelo de razonamiento capaz para el resumen y un modelo de texto de alta calidad para la redacción, en lugar de correr hacia el suelo en precio. Puedes anularlo por paso si sabes que ahí basta un modelo ligero.
La facturación es como en el resto de ToRun: cada invocación de modelo dentro de un flujo escribe exactamente un registro con una instantánea de precio congelada. Una ejecución que llame a tres modelos distintos en cinco pasos produce cinco registros. Puedes auditar el coste exacto de cada ejecución, desglosado por paso, después del hecho — incluso meses más tarde, cuando los precios del proveedor ya se hayan movido.
Depurar una ejecución
Cada ejecución de flujo produce un trazado estructurado. El trazado muestra el DAG con cada nodo anotado: hora de inicio, hora de fin, modelo resuelto, recuento de tokens de entrada y salida, llamadas a herramientas realizadas y el error, si lo hubo. En los pasos de LLM puedes desplegar el prompt exacto enviado y la respuesta cruda recibida.
Si un paso falla, el trazado te dice si el error vino de la llamada al modelo (error del proveedor, desbordamiento de contexto, rechazo por política de contenido), de una herramienta posterior (tiempo de espera de red, fallo de validación de esquema) o de tu propia lógica condicional. No tienes que añadir registro: se captura a nivel de infraestructura en cada ejecución.
Cualquier ejecución puede repetirse con la misma entrada, lo que hace directo reproducir un fallo.
Un pequeño ejemplo: flujo semanal de inteligencia competitiva
Imagina un flujo que lanzas cada lunes por la mañana:
- Paso de búsqueda web — busca cobertura reciente de un conjunto de palabras clave de competidores y devuelve una lista de URLs y extractos.
- Paso de recuperación — trae los últimos cuatro informes de una base de conocimiento para establecer el contexto de partida.
- Paso de resumen (LLM) — destila los resultados de búsqueda en hallazgos estructurados: funciones nuevas, cambios de precio, anuncios destacados.
- Paso de redacción (LLM) — escribe un informe interno breve en un estilo de casa consistente, fundamentado en los hallazgos resumidos.
- Paso de entrega — publica el informe en un endpoint webhook configurado.
El grafo tiene una dependencia natural: el paso 3 depende del 1 y del 2 (que pueden correr en paralelo), el 4 depende del 3, el 5 depende del 4. El ejecutor lo hace así sin ninguna configuración explícita de paralelismo: lee las aristas.