Was ein Workflow hier tatsächlich ist
Die meisten „Workflow“-Werkzeuge im KI-Umfeld sind Prompt-Ketten in dünner Verpackung. Der Baukasten von ToRun ist ein gerichteter azyklischer Graph (DAG) typisierter Schritte: Du verbindest Modellaufrufe, Werkzeugaufrufe, bedingte Verzweigungen, Schleifen und Unter-Workflows zu einem Graphen, und die Laufzeit führt sie in Abhängigkeitsreihenfolge aus, parallel dort, wo der Graph es zulässt.
Jeder Schritt ist eine vollwertige Einheit mit eigener Konfiguration: Schrittart (LLM-Aufruf, Websuche, Codeausführung, Bildgenerierung, Abruf, Transformation usw.), Eingabeschema, Fehlerpolitik (schnell scheitern, mit Wartezeit erneut versuchen, zum Fallback springen), eine Ausführungsbudgetgrenze je Schritt und ein Zeitlimit.
Das Modell-Routing innerhalb jedes LLM-Schritts läuft durch dieselbe Fähigkeits-Pipeline wie alles andere auf ToRun. Du erklärst, was du brauchst — strukturierte Ausgabe, Sehen, Werkzeugnutzung, Schlussfolgern, ein Kontextfenster von mindestens N Token — und der Runner löst das passendste Modell aus den zur Ausführungszeit verfügbaren Anbietern auf. Gibt dein Erstwunsch-Anbieter einen 5xx zurück, übernimmt automatisch die Fallback-Kette.
Qualitätsorientierte Runner und was das praktisch heißt
Wenn du einen Workflow ausführst, wählt der Runner bewusst Modelle der Qualitätsstufe statt der günstigsten Option. Dafür gibt es zwei Gründe: Automatisierungen erzeugen Artefakte (Berichte, generierte Inhalte, Code), die ein Mensch nicht sofort durchsieht, sodass Qualitätsfehler sich still summieren; und der Kostenunterschied bei moderatem Volumen ist kleiner als der Preis einer schlechten Ausgabe, die einen neuen Lauf oder eine Korrektur von Hand verlangt.
Praktisch bedeutet das: Ein Workflow „Recherche zusammenfassen und Briefing entwerfen“ bevorzugt für die Zusammenfassung ein leistungsfähiges Schlussfolgerungsmodell und für den Entwurf ein hochwertiges Textmodell, statt beim Preis nach unten zu rasen. Du kannst das je Schritt überstimmen, wenn du weißt, dass dort ein leichtes Modell genügt.
Die Abrechnung ist wie überall auf ToRun: Jeder Modellaufruf innerhalb eines Workflows schreibt genau einen Abrechnungssatz mit eingefrorener Preismomentaufnahme. Ein Lauf, der über fünf Schritte drei verschiedene Modelle aufruft, erzeugt fünf Abrechnungssätze. Du kannst die genauen Kosten jeder Ausführung nach Schritten aufgeschlüsselt im Nachhinein prüfen — selbst Monate später, nachdem sich Anbieterpreise bewegt haben.
Einen Lauf debuggen
Jede Workflow-Ausführung erzeugt eine strukturierte Laufspur. Die Spur zeigt den DAG mit Anmerkungen an jedem Knoten: Startzeit, Endzeit, aufgelöstes Modell, Token-Zahlen ein und aus, getätigte Werkzeugaufrufe und den Fehler, falls einer auftrat. Bei LLM-Schritten kannst du den exakt gesendeten Prompt und die rohe Antwort aufklappen.
Scheitert ein Schritt, sagt dir die Spur, ob der Fehler vom Modellaufruf selbst kam (Anbieterfehler, Kontextüberlauf, Ablehnung durch Inhaltsrichtlinie), von einem nachgelagerten Werkzeug (Netzwerk-Timeout, Schemavalidierung) oder aus deiner eigenen bedingten Logik. Du musst keine Protokollierung ergänzen — es wird für jeden Lauf auf Infrastrukturebene erfasst.
Jeder Lauf lässt sich mit derselben Eingabe wiederholen, was das Reproduzieren eines Fehlers einfach macht.
Ein kleines Beispiel: wöchentlicher Wettbewerbsüberblick
Stell dir einen Workflow vor, den du jeden Montagmorgen startest:
- Websuche-Schritt — sucht nach aktueller Berichterstattung zu einer Reihe von Wettbewerber-Stichwörtern und liefert eine Liste von URLs und Auszügen.
- Abrufschritt — holt die letzten vier Berichte aus einer Wissensdatenbank, um den Ausgangskontext zu setzen.
- Zusammenfassungsschritt (LLM) — destilliert die Suchergebnisse zu strukturierten Erkenntnissen: neue Funktionen, Preisänderungen, bemerkenswerte Ankündigungen.
- Entwurfsschritt (LLM) — schreibt ein kurzes internes Briefing in gleichbleibendem Hausstil, gestützt auf die zusammengefassten Erkenntnisse.
- Zustellschritt — sendet das Briefing an einen konfigurierten Webhook-Endpunkt.
Der Graph hat eine natürliche Abhängigkeit: Schritt 3 hängt von 1 und 2 ab (die parallel laufen können), Schritt 4 von 3, Schritt 5 von 4. Der Runner führt ihn genau so aus, ohne explizite Parallelitätskonfiguration — er liest die Kanten.