¿Qué son Loop y Graph en osFoundry y cuándo conviene usar cada uno?

Son las 6:40 de la tarde y el asistente de IA te acaba de decir que los tests que fallaban ya están arreglados. Los ejecutas tú. Dos siguen en rojo. Puedes pegarle la salida otra vez y volver a preguntar, o pasarle el trabajo a algo que solo se detiene cuando el test runner le da la razón. A la mañana siguiente, una compañera de marketing te hace otra pregunta: ¿puede algo parecido revisar tres webs de la competencia cada día laborable antes de que ella llegue?

Los dos trabajos viven en el mismo rincón de osFoundry, en dos entradas de menú vecinas: Loop y Graph.

Dos formas de ejecutar agentes sin tener que vigilarlos

Un Loop es una forma reutilizable de poner a un equipo de agentes a trabajar hacia un objetivo. Reúne una plantilla de agentes, un objetivo escrito con palabras normales, una forma de comprobar si ese objetivo se cumple, límites estrictos (cuántas rondas, cuántos fallos seguidos antes de rendirse) y, si quieres, un disparador como una programación horaria. Trabaja por rondas, evalúa cada ronda contra el objetivo y se detiene solo. Un Graph es un programa de flujo de trabajo guardado para cuando el camino no está fijado: puede bifurcarse según un resultado, repetir una parte hasta que pase, repartir trabajo entre varios agentes a la vez, pausarse para que una persona apruebe y llamar a otros graphs. Los dos están en la barra lateral principal de la app de escritorio de osFoundry, Loop primero y Graph justo debajo, y la distinción de una línea que da la propia app es la que vale la pena recordar: un Loop siempre sigue el mismo camino, un Graph decide su camino sobre la marcha.

Lo que ves mientras se ejecuta un Loop

Esta es una sesión de Loop ya terminada (los tests y nombres de archivo son datos de ejemplo). Lo que conviene conocer:

• La barra de sesiones a la izquierda. Cada ejecución de un Loop es su propia sesión, con un estado debajo. "Verified" aquí significa que la última ronda pasó la comprobación, no que la IA lo dijera.
• La franja de rondas arriba en la columna central. "Round 3 of 4", más la comprobación que usa ("Runs npm test — a zero exit code means done") y un contador de fallos de verificación seguidos, que es lo que detiene un loop que no va a ninguna parte.
• La pestaña Rounds. Una fila por ronda con cuántos criterios cumplió ("1 of 3 met", "2 of 3 met", "3 of 3 met"). Abre una ronda para ver exactamente qué criterios pasaron en ella.
• El inspector a la derecha, con las pestañas Goal, Trigger y Hooks.
• Pause y Cancel encima de los paneles, para cuando quieres que pare ya y no en la siguiente comprobación.

Caso 1: un desarrollador que quiere los tests realmente en verde

Quién: un desarrollador independiente al final del día, con una suite de JavaScript en rojo y un asistente que no deja de cantar victoria.

Abres Loop y pulsas New session. El diálogo New loop run lista loops ya preparados, y al buscar "JS suite" aparece Get the JS suite green. Antes de lanzarlo, la tarjeta de la derecha te cuenta cómo se comporta: Who runs it (un agente depurador que dirige a tres especialistas en tests), How it stops (como máximo 4 rondas, se detiene tras 3 fallos seguidos) y How it grades itself (ejecuta npm test, y solo un código de salida cero cuenta como terminado).

En Start it eliges Run once now en lugar de Just add it, seleccionas el proyecto y la carpeta donde deben trabajar los agentes, y pulsas Run it now. Después abres la pestaña Rounds y miras. En la ejecución de ejemplo, la ronda uno cumplió uno de tres tests, la ronda dos cumplió dos y la ronda tres los tres; en ese momento el loop se detuvo solo y la sesión quedó marcada como Verified.

Lo que te queda no es un mensaje de chat que asegura haberlo arreglado, sino un registro ronda a ronda de qué test pasó y cuándo, evaluado por tu propio test runner. En la misma lista hay loops para suites de Python, Go, Rust y Java, errores de tipos, lint y tests inestables.

Caso 2: alguien de marketing que quiere un informe de la competencia cada día laborable

Quién: una persona de marketing o producto que revisa a mano las webs de la competencia y no programa.

En el mismo diálogo New loop run, la sección de arriba se llama "Start here — these need nothing set up", y ahí está Watch the competitors, porque solo busca en la web y nunca toca tus archivos. Escribes a quién vigilar y qué buscar en Goal for this run (por ejemplo, precios, funciones nuevas y contrataciones), eliges Run once now y pulsas Run it now. El primer informe solo lista lo que cambió, con fecha y fuente en cada línea, y lo que una empresa dice de sí misma aparece marcado como no verificado.

Para que sea recurrente, abres la pestaña Trigger y pulsas Add a schedule. El diálogo Run this on a schedule ofrece opciones predefinidas (Every 30 min, Hourly, Daily 09:00, Weekdays 09:00), muestra la línea cron y las tres próximas ejecuciones, y hace dos preguntas prácticas: qué hacer si una ejecución sigue en marcha cuando toca la siguiente (Skip it, o Wait, then run) y qué hacer si el ordenador estaba en reposo (Up to an hour late, Up to 12 hours late o However late).

Tras Save schedule, la pestaña Trigger muestra "On a schedule" con la hora de la próxima ejecución. Ella acaba teniendo un informe esperándola cada mañana de lunes a viernes, sin abrir una terminal. Las programaciones se ejecutan mientras la app de escritorio está abierta, y para eso sirve el ajuste de recuperación.

Caso 3: un líder de equipo cuyo flujo tiene que bifurcarse

Quién: un responsable que quiere que cada archivo de un cambio grande se revise por separado, luego un informe unificado, y una aprobación humana antes de cualquier cosa irreversible.

Aquí un Loop deja de tener la forma adecuada. Un Loop repite el mismo plan en cada ronda, mientras que este responsable necesita un revisor por archivo, después un paso de fusión y, a veces, una pausa para aprobar. Eso es un Graph.

Abres Graph y pulsas el botón más junto a la lista. Create a Graph ofrece dos caminos: Start with a working graph (un programa seguro y ejecutable que luego ajustas) o Choose a starter. Los starters son ejemplos resueltos de patrones comunes, cada uno con una breve nota de cuándo usarlo. Review each item, then merge ejecuta un agente por elemento a la vez y después una única pasada de fusión. Triage and route clasifica una entrada una vez y la envía exactamente a un especialista. Propose, ask, then apply prepara un cambio, se detiene a esperar la respuesta de una persona y solo actúa si la respuesta es sí.

El programa en sí es código, no un diagrama de arrastrar y soltar, porque las bifurcaciones y los reintentos acotados son flujo de control de verdad. Lo normal es dejar que Maestro o un agente lo escriba o lo ajuste, y tú gestionas lo que importa en el día a día desde Configure session: Maximum agents at once, un aviso de tokens, un Hard token ceiling, la entrada por defecto y qué agente y modelo usa cada paso.

Cuando se ejecuta, el panel de ejecución tiene tres pestañas. Run muestra los pasos en directo y puedes usar Pause, Resume o Cancel. Si el graph llega a un paso de aprobación, una tarjeta te pide Approve o Decline, y el resto del trabajo en paralelo sigue mientras espera. Changes lista los archivos que la ejecución creó o editó, y algunos de esos cambios se pueden deshacer. History lista las ejecuciones anteriores, así que una ejecución fallida y la que lo arregló quedan una al lado de la otra. El responsable termina con una revisión repetible cuyas ejecuciones y cambios en archivos se pueden inspeccionar más tarde. Los graphs se pueden leer en el navegador, pero para ejecutarlos hace falta la app de escritorio.

Dónde se pasan el testigo Loop y Graph

Ninguna de las dos funciones trabaja sola. Los agentes del Team roster de un Loop vienen de Agent team y Agent Registry, y el propio loop es un preset reutilizable que puedes versionar en osStudio, así que subir un umbral de calidad o un límite de reintentos deja historial en lugar de un cambio silencioso. Un Graph recibe un identificador estable al crearse precisamente para que loops y otros graphs puedan llamarlo, lo que significa que un Loop programado puede lanzar un Graph con bifurcaciones a las 9:00. En Message, loops y graphs pueden ser miembros de un canal junto a personas y agentes sueltos, así que sus novedades llegan a la sala habitual del equipo. Para ver la parte de programación con más detalle, consulta programar agentes con cron y disparadores de agentes.

Preguntas habituales de quien empieza

¿Un Loop no es más que un cron job?
No. La programación es solo una parte opcional. Un Loop es un equipo más un objetivo más una comprobación, con límites de rondas, y guarda un registro de qué criterios cumplió cada ronda. Puedes ejecutarlo una vez a mano y no ponerle nunca un disparador.

Si un Loop también puede ejecutar agentes en paralelo, ¿para qué necesito Graph?
El paralelismo no es la diferencia. Usa Graph cuando el siguiente paso depende del resultado del anterior: enviar a un especialista concreto, reintentar solo la parte que falló, esperar el sí de una persona o llamar a otro flujo. Si cada ejecución sigue los mismos pasos, un Loop es más sencillo.

¿Puede un loop ejecutarse para siempre y fundirse mi presupuesto de API?
Todos los loops ya preparados tienen un tope de rondas y se detienen tras un número fijo de fallos seguidos, y la tarjeta muestra ambos antes de empezar. Los graphs tienen Maximum agents at once y un Hard token ceiling en los ajustes de sesión.

¿Tengo que escribir código?
Para los Loops, no: eliges uno y defines el objetivo y el disparador en diálogos. El programa de un Graph es código, pero puedes partir de un starter, dejar que Maestro o un agente lo edite, y cambiar entradas, límites y agentes por paso sin tocar el programa.

Puedes probar los dos en la app de escritorio desde osfoundry.io/es/download.