arXiv:2607.08740 – Workflow as Knowledge: Semantic Persistence for LLM-Mediated Workflows

Hinweis: Bei der hier besprochenen Arbeit handelt es sich um einen arXiv-Preprint. Sie hat noch kein reguläres Peer-Review-Verfahren durchlaufen; die vorgestellten Konzepte sind unabhängig noch nicht geprüft.

Worum geht es?

Anwendungen mit großen Sprachmodellen (LLMs) verlassen sich längst nicht mehr nur auf einzelne Prompts. Sie nutzen zunehmend explizite Workflows: Graphen mit typisierten Schritten, Schleifen, Werkzeugaufrufen, Zwischenspeicherpunkten und Freigaben durch Menschen. Der arXiv-Preprint 2607.08740 von Emanuele Quinto, Carlo Andrea Rozzi und Francesco Zanitti erkennt darin zwar einen sinnvollen Schritt weg vom impliziten, schwer nachvollziehbaren Kontrollfluss reiner Prompt-Ketten – sieht darin aber ein tieferliegendes Problem ungelöst: Die Bestandteile eines Workflows bleiben über Quellcode, Laufzeitschicht, Logs, Traces und Chatverläufe verstreut, ohne dass ihnen klare semantische Rollen zugewiesen werden.

Die Autoren schlagen ein Konzept vor, in dem Workflow-Definitionen, laufende Workflow-Instanzen und die damit verknüpften Entscheidungs- und Schlussfolgerungs-Datensätze als dauerhafte, abfragbare Wissensobjekte in einer gemeinsamen „Knowledge-Substrate“ genannten Ablage existieren – statt lediglich als flüchtige Logdateien oder Konfigurationsdaten.

Wofür ist es gut / was bringt es?

Das Konzept richtet sich an ein praktisches Problem heutiger LLM-Workflow-Systeme: Wenn ein Workflow unterbrochen wird oder im Nachhinein geprüft werden soll, ist es oft schwer nachzuvollziehen, welche Informationen zu welchem Zeitpunkt vorlagen, welche Entscheidung ein Mensch getroffen hat und welchen Anteil ein Sprachmodell an einem Ergebnis hatte. Die Autoren argumentieren, dass ihr Modell drei konkrete Vorteile böte: erstens eine abfragbare Workflow-Historie – man könnte etwa gezielt nach allen aufgeschobenen Freigaben oder allen Workflows fragen, die eine bestimmte Annahme berührt haben. Zweitens eine präzise spätere Prüfbarkeit, da jede Modell-Anfrage mit ihrem genauen Kontext protokolliert würde. Drittens eine klarere Trennung von Zuständigkeiten: deterministische Berechnung, Urteile des Sprachmodells, menschliche Freigaben und die vom System kontrollierte Ablaufsteuerung blieben als unterscheidbare Konzepte erkennbar, statt in einer einzigen Ausführungsspur zu verschwimmen.

Wie funktioniert es (vereinfacht)?

Im Zentrum des Vorschlags steht eine Unterscheidung zwischen zwei Arten von Rechenschritten. „derive“ bezeichnet deterministische Berechnungen über vorhandenem Zustand – etwa Skripte, Parser, Schema-Prüfungen oder Routing-Regeln, die reproduzierbar denselben Wert liefern. „infer“ bezeichnet dagegen eine vom Sprachmodell vermittelte Einschätzung unter einem festgelegten Kontext und einer vom Ausführungssystem kontrollierten Berechtigungsrichtlinie. Wichtig dabei: Die Modellantwort erhält dadurch keine Entscheidungsgewalt über den Workflow-Ablauf – diese Autorität behält das Ausführungssystem („Executor“), das über deklarierte Zweige selbst entscheidet.

Das folgende Schema veranschaulicht, wie eine zentrale Kontrollschicht (die „DSL-Maschine“) semantische Workflow-Objekte interpretiert, Laufzeitdienste koordiniert und Ergebnisse in die Wissensablage zurückschreibt:

Abbildung 1: Architekturschema des Vorschlags. Quelle: arXiv:2607.08740 (CC-BY-SA 4.0).

Die Autoren definieren dazu ein Vokabular wiederkehrender semantischer Objekte – etwa Workflow-Definition, Workflow-Instanz, Kontext-Schnappschuss, Inferenz-Datensatz, Freigabe-Datensatz und Gremiums-Datensatz („Panel“) – sowie operative Grundbegriffe wie Ressource, Wächter-Bedingung („Guard“), Zustand und Abhängigkeits-Verknüpfung. Die folgende Darstellung zeigt konkret die Unterscheidung zwischen „derive“ und „infer“:

Abbildung 3 im Paper: Gegenüberstellung von „derive“ und „infer“. Quelle: arXiv:2607.08740 (CC-BY-SA 4.0).

Als Erklärungsvorbild dient den Autoren die Lisp-Programmierwelt, in der Programme, Daten und Zustand traditionell in einer gemeinsamen, interaktiv inspizierbaren Umgebung existieren – nicht als Implementierungsvorgabe, sondern als Analogie dafür, wie eng Workflow-Definitionen und die von ihnen erzeugten Daten zusammengehören könnten. Zur Veranschaulichung arbeiten die Autoren im Anhang ein Beispiel aus, bei dem ein Workflow eine wissenschaftliche Aussage prüft: Er ordnet Ressourcen zu, prüft deterministisch die Formvollständigkeit einer Behauptung, lässt das Sprachmodell eine Risikoeinschätzung abgeben, holt eine menschliche Freigabe ein und kann bei Bedarf ein strukturiertes Gremium zur Klärung einberufen – jeder Schritt bleibt dabei als eigener, nachvollziehbarer Datensatz erhalten.

Ergänzend führt die Arbeit eine kleine explorative Bestandsaufnahme durch: Die Autoren sichteten 77 bereits existierende, workflowartige Artefakte (etwa interne Vorlagen sowie Agenten- und Automatisierungs-Skripte), um zu prüfen, welche der vorgeschlagenen Begriffe in der Praxis bereits sichtbar auftauchen und wo das Vokabular noch nachgeschärft werden müsste – etwa bei der Abgrenzung zwischen einer einfachen Freigabe und einer strukturierten Gremiumsentscheidung.

Einordnung & Grenzen

Die Autoren selbst betonen, dass es sich um einen konzeptionellen Entwurf handelt, nicht um eine fertige, empirisch getestete Umsetzung. Offene Fragen benennen sie explizit: Wie lange sollten die vielen erzeugten Datensätze aufbewahrt werden, bevor Speicherbedarf und Suchaufwand zu groß werden? Nicht jedes Zwischenergebnis eines Sprachmodells verdient dauerhafte Aufbewahrung, da Modelle auch redundante, qualitativ schwache oder irreführende Ausgaben erzeugen können. Auch die Grenze zwischen „derive“ und „infer“ verlangt nach den Worten der Autoren Disziplin von den Entwickler:innen eines Workflows und müsste im Zweifel nachprüfbar bleiben. Ob die vorgeschlagenen Datensätze in der Praxis tatsächlich Prüfbarkeit, Nachvollziehbarkeit und Reproduzierbarkeit verbessern, sei laut den Autoren selbst noch offen und bedürfe weiterer Untersuchung.

Wichtig für die Einordnung: Es handelt sich um einen arXiv-Preprint ohne unabhängige Begutachtung. Die vorgestellte Architektur wird bislang nur konzeptionell und anhand eines einzelnen ausgearbeiteten Beispiels illustriert; eine vollständige technische Implementierung oder ein Vergleich mit bestehenden Workflow- und Provenance-Systemen in der Praxis steht laut den Autoren noch aus. Als nächste Schritte nennen sie unter anderem einen Prototypen in Common Lisp sowie eine breitere Untersuchung an weiteren Praxis-Workflows.

FAQ

Was schlägt der arXiv-Preprint 2607.08740 vor? Ein Konzept, bei dem LLM-Workflows, ihre laufenden Instanzen sowie die dabei entstehenden Entscheidungs- und Modell-Datensätze als dauerhafte, abfragbare Wissensobjekte statt als flüchtige Logs gespeichert werden.

Was bedeuten „derive“ und „infer“ in diesem Modell? „Derive“ steht für deterministische, reproduzierbare Berechnungen ohne Sprachmodell. „Infer“ steht für eine vom Sprachmodell vermittelte Einschätzung unter festgelegtem Kontext, deren protokollierter Wert einen vom System kontrollierten Übergang beeinflussen kann, ohne selbst Entscheidungsgewalt zu besitzen.

Was ist eine „Knowledge-Substrate“? Eine abstrakte, technologieunabhängige Ablageschicht, die Workflow-Objekten eine feste Identität, typisierte Rollen und Beziehungen sowie Abfragbarkeit über einzelne Ausführungen hinweg verleiht – etwa realisierbar über Graphdatenbanken oder andere Speichersysteme.

Wurde das Konzept bereits praktisch umgesetzt und getestet? Nein. Es handelt sich um einen konzeptionellen Vorschlag mit einem ausgearbeiteten Beispiel im Anhang sowie einer kleinen explorativen Sichtung bestehender Workflow-Artefakte; eine vollständige Implementierung nennen die Autoren als zukünftigen Schritt.

Ist die Arbeit bereits von unabhängigen Fachleuten geprüft? Nein. Es handelt sich um einen arXiv-Preprint, der noch kein reguläres Peer-Review-Verfahren durchlaufen hat; die vorgestellten Konzepte sind unabhängig noch nicht geprüft.