Cosa sono Loop e Graph in osFoundry e quando usare l'uno o l'altro?

Sono le 18:40 e l'assistente AI ti ha appena detto che i test che fallivano sono stati sistemati. Li lanci tu. Due sono ancora rossi. Potresti incollare di nuovo l'output e chiedere ancora, oppure affidare il lavoro a qualcosa che si ferma solo quando il test runner gli dà ragione. La mattina dopo una collega del marketing ti fa una domanda diversa: una cosa del genere potrebbe controllare tre siti della concorrenza ogni giorno feriale prima che lei arrivi?

Entrambi i lavori stanno nello stesso angolo di osFoundry, sotto due voci di menu vicine: Loop e Graph.

Due modi per far lavorare gli agenti senza stargli dietro

Un Loop è un modo riutilizzabile per far lavorare un team di agenti verso un obiettivo. Mette insieme una rosa di agenti, un obiettivo scritto a parole semplici, un modo per verificare se l'obiettivo è raggiunto, limiti rigidi (quanti round, quanti fallimenti di fila prima di arrendersi) e, se vuoi, un trigger come una pianificazione. Lavora a round, valuta ogni round rispetto all'obiettivo e si ferma da solo. Un Graph è un programma di workflow salvato, per quando il percorso non è fisso: può diramarsi in base a un risultato, rifare una parte finché non passa, distribuire il lavoro a più agenti contemporaneamente, fermarsi per un'approvazione umana e chiamare altri graph. Tutti e due si trovano nella barra laterale principale dell'app desktop di osFoundry, prima Loop e subito sotto Graph, e la distinzione in una riga che dà l'app stessa è quella da ricordare: un Loop segue sempre lo stesso percorso, un Graph decide il suo percorso strada facendo.

Cosa vedi mentre un Loop è in esecuzione

Questa è una sessione Loop già conclusa (i test e i nomi dei file sono dati di esempio). Le parti da conoscere:

• La colonna delle sessioni a sinistra. Ogni esecuzione di un Loop è una sessione a sé, con uno stato sotto. Qui "Verified" significa che l'ultimo round ha superato il controllo, non che l'AI l'ha detto.
• La striscia dei round in cima alla colonna centrale. "Round 3 of 4", più il controllo usato ("Runs npm test — a zero exit code means done") e un contatore dei fallimenti di verifica consecutivi, che è ciò che ferma un loop che non va da nessuna parte.
• La scheda Rounds. Una riga per round con quanti criteri ha soddisfatto ("1 of 3 met", "2 of 3 met", "3 of 3 met"). Apri un round per vedere esattamente quali criteri sono passati.
• L'inspector a destra, con le schede Goal, Trigger e Hooks.
• Pause e Cancel sopra i pannelli, per quando vuoi che si fermi subito e non al controllo successivo.

Caso 1: uno sviluppatore che vuole i test davvero verdi

Chi: uno sviluppatore che lavora da solo, a fine giornata, con una suite JavaScript rossa e un assistente che continua a cantare vittoria.

Apri Loop e premi New session. La finestra New loop run elenca loop pronti all'uso, e cercando "JS suite" trovi Get the JS suite green. Prima di avviarlo, la scheda a destra ti dice come si comporta: Who runs it (un agente debugger che guida tre specialisti di test), How it stops (al massimo 4 round, si ferma dopo 3 fallimenti di fila) e How it grades itself (esegue npm test, e solo un exit code zero vale come finito).

In Start it scegli Run once now invece di Just add it, selezioni il progetto e la cartella in cui devono lavorare gli agenti e premi Run it now. Poi apri la scheda Rounds e guardi. Nell'esecuzione di esempio, il primo round ha soddisfatto uno dei tre test, il secondo due e il terzo tutti e tre; a quel punto il loop si è fermato da solo e la sessione è stata segnata come Verified.

Quello che ottieni non è un messaggio in chat che dice di aver risolto, ma un registro round per round di quale test è passato e quando, valutato dal tuo test runner. Nella stessa lista ci sono loop per suite Python, Go, Rust e Java, errori di tipo, lint e test instabili.

Caso 2: chi fa marketing e vuole un report sulla concorrenza ogni giorno feriale

Chi: una persona del marketing o del prodotto che controlla a mano i siti dei concorrenti e non scrive codice.

Nella stessa finestra New loop run, la sezione in alto si chiama "Start here — these need nothing set up", e lì c'è Watch the competitors, perché cerca solo sul web e non tocca mai i tuoi file. In Goal for this run scrivi chi tenere d'occhio e cosa cercare (per esempio prezzi, nuove funzionalità e assunzioni), scegli Run once now e premi Run it now. Il primo report elenca solo ciò che è cambiato, con data e fonte su ogni riga, e le affermazioni di un'azienda su se stessa sono segnate come non verificate.

Per renderlo ricorrente, apri la scheda Trigger e premi Add a schedule. La finestra Run this on a schedule offre dei preset (Every 30 min, Hourly, Daily 09:00, Weekdays 09:00), mostra la riga cron e le prossime tre esecuzioni, e fa due domande pratiche: cosa fare se un'esecuzione è ancora in corso quando tocca alla successiva (Skip it, oppure Wait, then run) e cosa fare se il computer era in standby (Up to an hour late, Up to 12 hours late o However late).

Dopo Save schedule, la scheda Trigger mostra "On a schedule" con l'orario della prossima esecuzione. Lei si ritrova un report pronto ogni mattina dal lunedì al venerdì, senza aprire un terminale. Le pianificazioni girano mentre l'app desktop è aperta, ed è a questo che serve l'impostazione di recupero.

Caso 3: un team lead il cui workflow deve diramarsi

Chi: un responsabile che vuole che ogni file di una modifica grande venga revisionato separatamente, poi un unico report unificato, con un via libera umano prima di qualsiasi cosa irreversibile.

Qui un Loop non ha più la forma giusta. Un Loop ripete lo stesso piano a ogni round, mentre il responsabile ha bisogno di un revisore per file, poi di un passaggio di merge e a volte di una pausa per l'approvazione. Questo è un Graph.

Apri Graph e premi il pulsante più accanto alla lista. Create a Graph offre due strade: Start with a working graph (un programma sicuro ed eseguibile che poi adatti) oppure Choose a starter. Gli starter sono esempi completi di schemi comuni, ognuno con una breve nota su quando usarlo. Review each item, then merge esegue un agente per elemento in parallelo e poi un unico passaggio di merge. Triage and route classifica un input una volta e lo manda a esattamente uno specialista. Propose, ask, then apply elabora una modifica, si ferma ad aspettare la risposta di una persona e agisce solo con un sì.

Il programma in sé è codice, non un diagramma drag-and-drop, perché diramazioni e retry limitati sono vero flusso di controllo. Di solito lasci che Maestro o un agente lo scriva o lo modifichi, e gestisci ciò che conta ogni giorno in Configure session: Maximum agents at once, un avviso sui token, un Hard token ceiling, l'input predefinito e quale agente e modello usa ogni passaggio.

Quando parte, il pannello di esecuzione ha tre schede. Run mostra i passaggi in diretta e puoi usare Pause, Resume o Cancel. Se il graph arriva a un passaggio di approvazione, una scheda ti chiede Approve o Decline, e il resto del lavoro in parallelo va avanti mentre aspetta. Changes elenca i file che l'esecuzione ha creato o modificato, e alcune di queste modifiche si possono annullare. History elenca le esecuzioni precedenti, così un'esecuzione fallita e quella che l'ha sistemata stanno una accanto all'altra. Il responsabile ottiene una revisione ripetibile le cui esecuzioni e modifiche ai file si possono ispezionare in seguito. I graph si possono leggere nel browser, ma per eseguirli serve l'app desktop.

Dove Loop e Graph si passano il testimone

Nessuna delle due funzioni lavora da sola. Gli agenti nel Team roster di un Loop arrivano da Agent team e Agent Registry, e il loop stesso è un preset riutilizzabile che puoi versionare in osStudio, quindi alzare una soglia di qualità o un limite di retry lascia uno storico invece di una modifica silenziosa. Un Graph riceve un identificatore stabile quando viene creato proprio perché loop e altri graph possano chiamarlo: un Loop pianificato può quindi avviare un Graph con diramazioni alle 9:00. In Message, loop e graph possono essere membri di un canale accanto a persone e singoli agenti, così i loro aggiornamenti arrivano nella stanza abituale del team. Per approfondire la parte di pianificazione, vedi pianificare agenti con cron e i trigger degli agenti.

Le domande di chi inizia

Un Loop non è solo un cron job?
No. La pianificazione è solo una parte opzionale. Un Loop è un team più un obiettivo più un controllo, con limiti di round, e tiene un registro dei criteri soddisfatti in ogni round. Puoi eseguirne uno una volta a mano e non dargli mai un trigger.

Se anche un Loop può eseguire agenti in parallelo, perché dovrei usare Graph?
Il parallelismo non è la differenza. Scegli Graph quando il passo successivo dipende dal risultato del precedente: indirizzare a uno specialista, ripetere solo la parte che è fallita, aspettare il sì di una persona o chiamare un altro workflow. Se ogni esecuzione segue gli stessi passi, un Loop è più semplice.

Un loop può girare all'infinito e bruciarmi il budget API?
Ogni loop pronto all'uso ha un tetto di round e si ferma dopo un numero fisso di fallimenti consecutivi, e la scheda mostra entrambi prima di partire. I graph hanno Maximum agents at once e un Hard token ceiling nelle impostazioni di sessione.

Devo scrivere codice?
Per i Loop no: ne scegli uno e imposti obiettivo e trigger nelle finestre di dialogo. Il programma di un Graph è codice, ma puoi partire da uno starter, lasciare che Maestro o un agente lo modifichi e cambiare input, limiti e agenti per passaggio senza toccare il programma.

Puoi provarli entrambi nell'app desktop da osfoundry.io/it/download.