Deterministische KI-Workflows: eine Sprache, keine Aufzeichnung
Deterministische KI-Workflows entstehen nicht, indem man eine Session als Job speichert - Wiederholung braucht Eigenschaften, die man lesen kann, bevor etwas läuft. Warum DataQube-Workflows in einer Sprache geschrieben sind: geordnete Schritte, typisierte Parameter und ein Grant-Manifest, das nicht lügen kann.
Analytische Arbeit hat zwei Modi, die so tun, als wären sie einer. Die Untersuchung ist offen: Sie mäandern, revidieren, folgen der überraschenden Zahl. Die Wiederholung ist das Gegenteil: der Monatsend-Pack, die Antwort an die Aufsicht, das Montags-Komitee-Deck - dieselben Schritte auf neuen Daten, wo eine Überraschung kein Insight ist, sondern ein Vorfall. Eine Plattform, die beides als einen Modus behandelt, wird in beidem mittelmäßig sein; die eigentliche Designfrage ist, was der zweite Modus verdient.
DataQubes Antwort: ein Workflow - ein eigenes, erstklassiges Artefakt mit einem starken Anspruch. Nicht "der Agent versucht, dasselbe noch einmal zu tun". Nicht "wir haben Ihre Session gespeichert und spielen sie ab". Ein Workflow ist ein Programm: geordnete Schritte, typisierte Parameter, deklarierter Zugriff - etwas, das Sie lesen, prüfen und durchdenken können, bevor es läuft, und das sich danach jedes Mal gleich verhält.
Das Risiko aufgezeichneter Automatisierungen
Die meisten Agent-Produkte bieten Wiederholung als Aufzeichnung an: die Session nehmen, die funktioniert hat, als Job speichern, nach Zeitplan laufen lassen. In der Demo wirkt das großartig. Das Risiko kommt später und wächst leise. Eine Aufzeichnung trägt alles, was die Session zufällig enthielt - die explorativen Umwege, die Annahmen jenes Tages, Werte in Zelle siebzehn, die nur für Oktober gedacht waren. Niemand kann präzise sagen, was sie auf neuen Daten tun wird, denn niemand hat je aufgeschrieben, was sie tun soll; und wenn die Aufzeichnung von einem improvisierenden Modell "abgespielt" wird, ist jeder Monatslauf eine neue Interpretation der Geschichte. Der Drift hat kein Änderungsprotokoll. Wenn der Montags-Pack sich zum ersten Mal selbst widerspricht, gibt es nichts zu diffen - nur zwei Läufe, zwei Stimmungen und ein Meeting.
Wenn Sie Automatisierungsfunktionen einer Agent-Plattform evaluieren, trennt diese Frage Aufzeichnung von Engineering: Zeigen Sie mir das Artefakt, das am Montag läuft - kann ich es lesen, und können Sie beweisen, was es anfassen darf?
Ein Workflow ist ein Programm, das man lesen kann
In DataQube beantwortet das Artefakt beide Hälften. Workflows werden in einer kleinen eigenen Sprache geschrieben - .wf -, und hier ist der stehende Exposure-Workflow aus unseren Demo-Szenarien, leicht gekürzt (die Tool-Methoden kommen aus Ihrem eigenen Katalog):
import std @ 1 ## Rebuilds the monthly CRE exposure pack and stages it for review.## @param sql the SQL capability the queries run under## @param docs the document-store capability for policy citations## @param conn the registered risk-warehouse connection## @param as_of the reporting month-end, e.g. "2026-09-30"## @param dest the file store that receives the packdef cre_monthly_exposure(sql: Cap<dq.sql>, docs: Cap<dq.files>, conn: Connection, as_of: String, dest: Store) -> Step<ArtifactRef> = {let exposures: Table<{ segment: String, drawn: Decimal }> <- sql.execute_sql( connection_id: conn, sql: "select segment, sum(drawn_amount) as drawn from loan_book where cre_flag and as_of = '{as_of}' group by segment",)let policy: Markdown <- docs.cite(file: "policies/CRE-limits-2026.pdf", section: "3.2")let pack: Markdown <- std.llm(prompt: "Build the CRE exposure pack for {as_of}. Exposures: {exposures.rows}. Limits, cited: {policy}")let pdf: Pdf <- std.render_pdf(pack)std.upload(pdf, name: "cre-exposure-{as_of}.pdf", store: dest)}Alles, was eine Aufzeichnung implizit lässt, ist hier explizit. Die Parameter sind typisiert, in der Signatur deklariert und mit Tags dokumentiert, die der Checker durchsetzt - der Stichtag ist ein Input, keine Archäologie. Jeder Effekt ist ein gebundener, geordneter Schritt. Und die Sprache selbst ist so gebaut, dass das Artefakt nicht driften kann: total und deterministisch by construction - keine Rekursion, keine unbeschränkten Schleifen, kein Fließkomma (nur exakte Dezimalzahlen), keine Nulls. Muss sich die Analyse ändern, ist die Änderung eine neue Version dieses Texts, geprüft wie jede Änderung an einem governten Prozess. Determinismus ist kein Versprechen über die Laune des Modells. Er ist eine Eigenschaft des Artefakts.
Es kann nicht lügen über das, was es anfasst
Sehen Sie sich die Signatur noch einmal an, denn sie leistet die Sicherheitsarbeit. Jede Tool-Familie, die ein Workflow nutzen kann, muss als typisierter Capability-Parameter ankommen - sql: Cap<dq.sql> -, und Capabilities können im Rumpf nicht erzeugt werden. Die Signatur ist die Zugriffsfläche: Dieser Workflow kann eine Warehouse-Verbindung abfragen, Dokumente zitieren und ein Artefakt hochladen, weil das alles ist, was man ihm gereicht hat. Daraus berechnet die Analyse das Grant-Manifest des Workflows, bevor irgendetwas läuft - was er liest, was er schreibt, was er fragen darf - als geprüfte Tatsache, nicht als erklärte Absicht.
Die Disziplin endet nicht bei eingebauten Tools. Verbinden Sie einen Third-Party-MCP-Server - Jira, ServiceNow, einen internen Dienst -, und seine Tools werden automatisch in dieselbe typisierte Welt abgeleitet: Die Capability erscheint als jira: Cap<mcp.`jira-cloud`.*>, ihre Methoden typisiert aus dem Live-Katalog, ohne handgeschriebene Wrapper. Externe Tools gehorchen denselben Regeln wie native - in der Signatur deklariert, im Manifest gezählt, unfähig, in einem Lauf aufzutauchen, der sie nicht deklariert hat.
Diese eine Eigenschaft ändert, wer wem was glauben muss. Wer einen Workflow freigibt, sieht im Moment der Freigabe seine exakte Fläche. Das Berechtigungssystem erzwingt dieselbe Obergrenze wie überall: Ein Workflow übersteigt nie die Berechtigungen seines Owners, und Planung gewährt nichts. Und ein Auditor, der fragt "Worauf hätte dieser Job im März zugreifen können?", bekommt die Antwort aus dem Artefakt selbst - nicht aus Rekonstruktion.
Extrahieren ist Aufgabe des Agenten, nicht Ihre
Nichts davon verlangt, dass jemand Workflow-Code schreibt. Der Thread ist der Ort, an dem die Arbeit herausgefunden wird - und wenn sie wieder laufen muss, fragen Sie, und der Agent leitet den Workflow aus dem Protokoll ab: die Schritte, die tatsächlich liefen, die Parameter, die tatsächlich variierten, die Quellen, die tatsächlich berührt wurden. Das append-only Protokoll der Untersuchung ist präzise genug, um daraus zu kompilieren; Extraktion ist eine Projektion des Geschehenen in ein Programm, das wieder geschehen kann. Sie prüfen das Ergebnis - lesbar, typisiert, Manifest angehängt -, statt es zusammenzubauen.
Drei Wege, ihn auszuführen
Dasselbe Artefakt läuft auf drei Wegen, und jeder beantwortet ein anderes Bedürfnis:
- Auf Abruf - eine Person löst ihn mit den heutigen Parametern aus; der Monatsend-Pack, früher gefahren, weil das Komitee vorgezogen wurde.
- Nach Zeitplan - das ist ein geplanter Agent: der Montags-IC-Pack um 06:00, der sich selbst neu baut, mit der Vorwoche vergleicht und einen Entwurf bereitstellt, während die verteilte Version unverändert bleibt.
- Per Tool-Aufruf - ein Agent in einem laufenden Gespräch ruft den stehenden Workflow auf, statt Zahlen neu herzuleiten; so kommt eine Zahl aus einem Ad-hoc-Thread Lauf für Lauf identisch mit der Zahl im verteilten Pack heraus.
Hier läuft ein geplanter Lauf - Montag, 06:00 Uhr, niemand an der Tastatur:
- riskdwh.sqlPositionen & Wochenperformance abrufen
- risk.engineAttribution gegen die Benchmark rechnen
- docstore.readMandatslimits zitieren
- checks.runAbstimmen & verifizieren
- thread.appendIC-Deck-Entwurf bereitstellen
Auf Basis realer Kundengespräche — alle Daten fiktiv.
Jeder Lauf landet im Protokoll
Ein Workflow-Lauf ist kein Fire-and-forget. Jeder hängt sich an die Run-Historie an: welche Version lief, mit welchen Parametern, mit welchen Outputs, mit der vollständigen Evidenzkette - und die Ergebnisse landen als bereitgestellter Entwurf in einem Thread, den eine Person publiziert. Fehlgeschlagene Läufe erscheinen in derselben Historie mit ihrer Provenienz, nicht in einem Log, das niemand liest. Die Garantien des Protokolls werden nicht schwächer, weil niemand zusah; sechs Monate Montagsläufe sind sechs Monate Evidenz, nicht sechs Monate Hoffnung.
Das ist das ganze Design: Der Thread ist der Ort, an dem Sie überrascht werden dürfen, und der Workflow ist der Ort, an dem Sie es nie werden - weil er ein Programm mit Manifest ist, keine Erinnerung an einen guten Tag. Das Modul der geplanten Agents auf der Produktseite zeigt, wo das in der Plattform lebt - und eine Demo extrahiert Ihnen gern live einen Workflow aus einem laufenden Gespräch.