Es ist 18:40 Uhr, und der KI-Assistent hat dir gerade gemeldet, dass die fehlschlagenden Tests repariert sind. Du lässt sie selbst laufen. Zwei sind immer noch rot. Du könntest die Ausgabe wieder einfügen und noch einmal fragen, oder du gibst die Aufgabe an etwas ab, das erst aufhört, wenn der Test-Runner zustimmt. Am nächsten Morgen fragt eine Kollegin aus dem Marketing etwas ganz anderes: Kann so etwas auch an jedem Werktag drei Websites der Konkurrenz prüfen, bevor sie ins Büro kommt?
Beide Aufgaben liegen in derselben Ecke von osFoundry, unter zwei benachbarten Menüpunkten: Loop und Graph.
Zwei Wege, Agenten laufen zu lassen, ohne danebenzusitzen
Ein Loop ist eine wiederverwendbare Art, ein Agententeam auf ein Ziel hinarbeiten zu lassen. Er bündelt eine Besetzung aus Agenten, ein in normalen Worten formuliertes Ziel, eine Prüfung, ob das Ziel erreicht ist, feste Grenzen (wie viele Runden, wie viele Fehlschläge in Folge, bevor er aufgibt) und optional einen Auslöser wie einen Zeitplan. Er arbeitet in Runden, bewertet jede Runde am Ziel und hört von selbst auf. Ein Graph ist ein gespeichertes Workflow-Programm für Fälle, in denen der Weg nicht feststeht: Er kann je nach Ergebnis verzweigen, einen Teil wiederholen, bis er besteht, Arbeit gleichzeitig auf mehrere Agenten verteilen, für eine menschliche Freigabe pausieren und andere Graphs aufrufen. Beide stehen in der Hauptseitenleiste der osFoundry-Desktop-App, Loop zuerst und Graph direkt darunter, und die Ein-Satz-Unterscheidung der App selbst ist die, die man sich merken sollte: Ein Loop nimmt immer denselben Weg, ein Graph entscheidet seinen Weg unterwegs.
Was man sieht, während ein Loop läuft
Das ist eine Loop-Session nach dem Ende (Tests und Dateinamen sind Beispieldaten). Was man kennen sollte:
- Die Session-Leiste links. Jeder Loop-Lauf ist eine eigene Session mit einem Status darunter. "Verified" heißt hier, dass die letzte Runde die Prüfung bestanden hat, nicht dass die KI es behauptet.
- Der Rundenstreifen oben in der mittleren Spalte. "Round 3 of 4", dazu die verwendete Prüfung ("Runs npm test — a zero exit code means done") und ein Zähler für Prüf-Fehlschläge in Folge. Der stoppt einen Loop, der nicht vorankommt.
- Der Rounds-Tab. Eine Zeile pro Runde mit der Zahl der erfüllten Kriterien ("1 of 3 met", "2 of 3 met", "3 of 3 met"). Öffnet man eine Runde, sieht man genau, welche Kriterien darin bestanden wurden.
- Der Inspector rechts mit den Tabs Goal, Trigger und Hooks.
- Pause und Cancel über den Panels, wenn er sofort aufhören soll und nicht erst bei der nächsten Prüfung.
Anwendungsfall 1: ein Entwickler, der die Tests wirklich grün haben will
Wer: ein Solo-Entwickler am Ende des Tages mit einer roten JavaScript-Suite und einem Assistenten, der ständig den Sieg verkündet.
Du öffnest Loop und klickst auf New session. Der Dialog New loop run listet fertige Loops auf, und die Suche nach "JS suite" findet Get the JS suite green. Vor dem Start zeigt die Karte rechts, wie er sich verhält: Who runs it (ein Debugger-Agent, der drei Test-Spezialisten anleitet), How it stops (höchstens 4 Runden, Abbruch nach 3 Fehlschlägen in Folge) und How it grades itself (führt npm test aus, und nur Exit-Code null zählt als fertig).
Unter Start it wählst du Run once now statt Just add it, suchst das Projekt und den Ordner aus, in dem die Agenten arbeiten sollen, und klickst auf Run it now. Dann öffnest du den Rounds-Tab und schaust zu. Im Beispiellauf erfüllte Runde eins einen von drei Tests, Runde zwei zwei und Runde drei alle drei. An diesem Punkt hielt der Loop von selbst an, und die Session wurde als Verified markiert.
Am Ende hast du keine Chatnachricht, die einen Fix behauptet, sondern ein Protokoll Runde für Runde, welcher Test wann bestanden hat, bewertet von deinem eigenen Test-Runner. In derselben Liste gibt es Loops für Python-, Go-, Rust- und Java-Suites, Typfehler, Lint und flaky Tests.
Anwendungsfall 2: eine Marketerin, die werktags einen Konkurrenzbericht will
Wer: jemand aus Marketing oder Produkt, der Konkurrenz-Websites von Hand prüft und nicht programmiert.
Im selben Dialog New loop run heißt der oberste Abschnitt "Start here — these need nothing set up", und dort steht Watch the competitors, weil er nur im Web sucht und deine Dateien nie anfasst. In Goal for this run trägst du ein, wen du beobachten willst und worauf du achtest (zum Beispiel Preise, neue Features und Stellenanzeigen), wählst Run once now und klickst auf Run it now. Der erste Bericht listet nur, was sich geändert hat, mit Datum und Quelle in jeder Zeile, und Aussagen eines Unternehmens über sich selbst sind als unbestätigt markiert.
Damit er regelmäßig läuft, öffnest du den Trigger-Tab und klickst auf Add a schedule. Der Dialog Run this on a schedule bietet Vorlagen (Every 30 min, Hourly, Daily 09:00, Weekdays 09:00), zeigt die Cron-Zeile und die nächsten drei Ausführungszeiten und stellt zwei praktische Fragen: was passieren soll, wenn ein Lauf noch aktiv ist, während der nächste fällig wird (Skip it oder Wait, then run), und was, wenn der Rechner im Ruhezustand war (Up to an hour late, Up to 12 hours late oder However late).
Nach Save schedule zeigt der Trigger-Tab "On a schedule" mit der nächsten Ausführungszeit. Sie hat dann jeden Werktagmorgen einen Bericht, ohne je ein Terminal zu öffnen. Zeitpläne laufen, solange die Desktop-App offen ist, und genau dafür gibt es die Nachhol-Einstellung.
Anwendungsfall 3: ein Teamlead, dessen Workflow verzweigen muss
Wer: eine Teamleitung, die jede Datei einer großen Änderung einzeln reviewen lassen will, danach einen zusammengeführten Bericht, und vor allem Unumkehrbaren eine menschliche Freigabe.
Hier passt ein Loop nicht mehr. Ein Loop wiederholt in jeder Runde denselben Plan, die Teamleitung braucht aber einen Reviewer pro Datei, dann einen Merge-Schritt und manchmal eine Pause für die Freigabe. Das ist ein Graph.
Du öffnest Graph und klickst auf das Plus neben der Liste. Create a Graph bietet zwei Wege: Start with a working graph (ein sicheres, lauffähiges Programm, das du dann anpasst) oder Choose a starter. Die Starter sind ausgearbeitete Beispiele für gängige Muster, jeweils mit einem kurzen Hinweis, wann man sie nimmt. Review each item, then merge lässt gleichzeitig einen Agenten pro Element laufen und danach einen einzigen Merge-Durchgang. Triage and route klassifiziert eine Eingabe einmal und schickt sie an genau einen Spezialisten. Propose, ask, then apply erarbeitet eine Änderung, wartet auf die Antwort eines Menschen und handelt nur bei einem Ja.
Das Programm selbst ist Code, kein Drag-and-drop-Diagramm, denn Verzweigungen und begrenzte Wiederholungen sind echter Kontrollfluss. Meist lässt man Maestro oder einen Agenten ihn schreiben oder anpassen und verwaltet das, was im Alltag zählt, in Configure session: Maximum agents at once, eine Token-Warnung, ein Hard token ceiling, die Standardeingabe und welcher Agent und welches Modell jeden Schritt übernimmt.
Beim Ausführen hat der Run-Bereich drei Tabs. Run zeigt die Schritte live, und du kannst Pause, Resume oder Cancel drücken. Erreicht der Graph einen Freigabeschritt, fragt eine Karte nach Approve oder Decline, und die übrige parallele Arbeit läuft weiter, während er wartet. Changes listet die Dateien, die der Lauf erstellt oder bearbeitet hat, und manche davon lassen sich rückgängig machen. History listet frühere Läufe, sodass ein fehlgeschlagener Lauf und der Wiederholungslauf, der das Problem gelöst hat, nebeneinander stehen. Die Teamleitung hat am Ende ein wiederholbares Review, dessen Läufe und Dateiänderungen sich später alle nachvollziehen lassen. Graphs kann man im Browser ansehen, zum Ausführen braucht es aber die Desktop-App.
Wo Loop und Graph sich die Arbeit übergeben
Keine der beiden Funktionen arbeitet allein. Die Agenten im Team roster eines Loops kommen aus Agent team und Agent Registry, und der Loop selbst ist ein wiederverwendbares Preset, das du in osStudio versionieren kannst. Wer eine Qualitätsschwelle oder ein Retry-Limit anhebt, hinterlässt also eine Historie statt einer stillen Änderung. Ein Graph bekommt beim Erstellen eine stabile Kennung, gerade damit Loops und andere Graphs ihn aufrufen können. Ein geplanter Loop kann also um 9:00 einen verzweigenden Graph anstoßen. In Message können Loops und Graphs neben Menschen und einzelnen Agenten Mitglieder eines Channels sein, sodass ihre Updates im üblichen Raum des Teams landen. Mehr zur Zeitplanung findest du unter Agenten per Cron planen und Agent-Trigger.
Fragen, die Einsteiger stellen
Ist ein Loop nicht einfach ein Cronjob?
Nein. Ein Zeitplan ist nur ein optionaler Teil davon. Ein Loop ist ein Team plus ein Ziel plus eine Prüfung, mit Rundenlimits, und er führt Buch darüber, welche Kriterien jede Runde erfüllt hat. Du kannst ihn einmal von Hand starten und ihm nie einen Auslöser geben.
Wenn ein Loop auch Agenten parallel laufen lassen kann, wozu brauche ich dann Graph?
Parallelität ist nicht der Unterschied. Nimm Graph, wenn der nächste Schritt vom Ergebnis des vorherigen abhängt: an einen bestimmten Spezialisten weiterleiten, nur den fehlgeschlagenen Teil wiederholen, auf das Ja eines Menschen warten oder einen anderen Workflow aufrufen. Wenn jeder Lauf dieselben Schritte geht, ist ein Loop einfacher.
Kann ein Loop endlos laufen und mein API-Budget verbrennen?
Jeder fertige Loop hat eine Rundenobergrenze und hört nach einer festen Zahl von Fehlschlägen in Folge auf, und die Karte zeigt beides vor dem Start. Graphs haben Maximum agents at once und ein Hard token ceiling in ihren Session-Einstellungen.
Muss ich Code schreiben?
Für Loops nicht: Du wählst einen aus und legst Ziel und Auslöser in Dialogen fest. Das Programm eines Graphs ist Code, aber du kannst mit einem Starter beginnen, Maestro oder einen Agenten daran arbeiten lassen und Eingaben, Limits und Agenten pro Schritt ändern, ohne das Programm anzufassen.
Beides kannst du in der Desktop-App ausprobieren, zu finden unter osfoundry.io/de/download.
