Finyuus

Die Sprache von Finyuus ist eine kleine, domänenspezifische Sprache, geschrieben für die Orchestrierung von KI, nicht für allgemeines Skripting. Die Anweisungen decken Agentenaufrufe, native und HTTP-Werkzeuge, Guards, Freigaben, Bedingungen, Schleifen, parallele Zweige und untergeordnete Pipelines ab. Weil Workflows reiner Text sind, können Sie sie per Diff vergleichen, in Pull Requests prüfen und Teile projektübergreifend wiederverwenden. Das ist der ganze Grund für ihre Existenz: KI-Verhalten, das Sie lesen und vergleichen können, kein Canvas voller Kästchen. Keine Kästchen. Nur Text.

Jeder Lauf wird von Temporal gestützt, und das macht lange Wartezeiten und Ausfälle überstehbar. Stirbt ein Worker mitten im Lauf, wird der Workflow aus seinem aufgezeichneten Zustand fortgesetzt, statt neu zu starten. Wiederholungen, Abbruch und Orchestrierung untergeordneter Workflows kommen aus derselben Schicht. Es funktioniert einfach. Wer schon erlebt hat, wie ein mehrstündiger Agentenauftrag bei einem Absturz verschwindet, für den ändert diese Funktion die Rechnung.

Guards sind LLM-basierte Richtlinienprüfungen, die Felder wie allowed, confidence und reason zurückgeben. Eine Pipeline leitet die Ausführung über einen erlaubten oder blockierten Zweig, und Sie können auf Vertrauensschwellen statt auf ein pauschales Ja oder Nein abstellen. So hindern Sie ein Modell daran, eine Frage zur Finanzberatung direkt zu beantworten, oder blockieren eine Ausgabe, die eine Veröffentlichungsrichtlinie verletzt, bevor sie einen Nutzer erreicht. Einfache Idee. Riesiger Unterschied in der Praxis.

Freigabeanweisungen pausieren einen Workflow, bis ein Prüfer ihn über das Dashboard oder die API auflöst. Sie legen einen Zuständigen, eine Zeitüberschreitung und eine Aktion bei Ablauf fest, und die Pipeline verzweigt in genehmigte und abgelehnte Pfade. Das ist ein echter Halt, kein Vorschlag. Darin liegt der Unterschied zwischen „das prüfen wir später" und einem System, das eine riskante Ausgabe tatsächlich stoppt und auf einen Menschen wartet, bevor es weitergeht.

Agenten, Guards, Werkzeuge, Schemas und Pipelines sind gespeicherte Objekte mit unveränderlichen Versionsbindungen. Sie schreiben pipeline:company_research@v2 und bekommen genau diese Version, nicht das, was zuletzt jemand bearbeitet hat. Binden. Weitergehen. Untergeordnete Pipelines lassen sich direkt aufrufen oder als Agentenwerkzeuge einwickeln, eine Änderung an einer Stelle schwappt also nicht still durch jeden Workflow, der davon abhängt.

Jede Pipeline kann als HTTP-Endpunkt veröffentlicht werden, mit Bearer-Token-Authentifizierung, Redis-gestützter Ratenbegrenzung, Idempotenzschlüsseln und Eingabevalidierung. Über den Server gesendete Ereignisse streamen Laufaktualisierungen zurück an den Aufrufer, und Freigaben erzeugen eigene Ereignisse. Die Prozessgrenzen liegen standardmäßig bei insgesamt 300 Anfragen pro Minute und 120 pro Endpunkt, alle über Umgebungsvariablen konfigurierbar. Sinnvolle Vorgaben. Leicht zu überschreiben.

Traces, Token-Nutzung und Modellkosten landen in Langfuse, während Anwendungsdaten und Pipelinetabellen in ClickHouse liegen. Laufhistorie, Guard-Ergebnisse und Freigabeentscheidungen sind im Dashboard sichtbar. Der Punkt ist nicht, mehr Dashboards um ihrer selbst willen zu haben. Der Punkt ist, dass ein zersplittertes KI-System meist keinen einzigen Ort hat, um die Frage „was ist in diesem Lauf tatsächlich passiert?" zu beantworten.

Dateien und große Artefakte gehen in einen konfigurierbaren Objektspeicher, der standardmäßig lokales MinIO nutzt und mit ein paar Umgebungsvariablen auf AWS S3 umschalten kann. Die DSL liest und schreibt Dateien und ClickHouse-gestützte Tabellen als Anweisungen erster Klasse, strukturierte Datenoperationen liegen also im Workflow statt in einem separaten Dienst. Kein zusätzlicher Dienst, der betreut werden muss.