Deterministische Workflows & Tooling

Wir konzipieren KI-Pipelines, bei denen die Orchestrierung deterministisch ist und der Modellaufruf die einzige probabilistische Komponente darstellt. Jede Routing-Entscheidung, Validierungsprüfung, Retry-Policy und jeder Zustandsübergang läuft als expliziter, auditierbarer Code. Das LLM operiert innerhalb abgegrenzter Knoten mit schemageprüften Ein- und Ausgaben, und wenn ein Fehler auftritt, setzen Sie am letzten Checkpoint wieder an — nicht von vorn. Das ist die Architektur, die Agenten-Chaos in der Handelsüberwachung, der klinischen Datenextraktion und der Erstellung regulatorischer Meldungen auditierbar macht.

Die Mathematik, die Agenten-Pipelines scheitern lässt

Eine 10-Schritte-Kette von KI-Agenten, bei der jeder Schritt mit 95% Genauigkeit arbeitet, liefert in nur 59.9% der Fälle ein korrektes End-to-End-Ergebnis. Das bedeutet, dass vier von zehn Durchläufen fehlschlagen. In einer Chatbot-Demo wiederholen Sie die Anfrage einfach. In der Handelsüberwachung, der klinischen Datenextraktion oder der Erstellung regulatorischer Einreichungen führt eine Fehlerrate von 40% jedoch zum Projektabbruch. Gartner prognostiziert, dass über 40% der agentischen KI-Projekte bis Ende 2027 abgebrochen werden, und die Mathematik sich kumulierender Fehler ist ein wesentlicher Grund dafür.

Unsere Antwort beschränkt den probabilistischen Modellaufruf auf abgegrenzte Knoten mit schemageprüften Ein- und Ausgaben. Jede Routing-Entscheidung, Validierungsprüfung, Retry-Policy und jeder Zustandsübergang läuft als expliziter, auditierbarer Code — sodass bei einem Fehler die Ausführung ab dem letzten Checkpoint und nicht von Beginn an wiederholt wird (siehe unsere Forschungsarbeit zu Architektur, Zuverlässigkeit und strategischer Divergenz in Deep AI).

Warum die meisten Agenten-Frameworks in der Produktion scheitern

Das Signal aus der Community ist eindeutig, und die Fehlermuster sind spezifisch:

• LangChain -Agenten geraten in Reasoning-Schleifen, rufen wiederholt falsche Tools auf und degradieren, ohne Exceptions auszulösen.
• Modelle stellen JSON erklärenden Text voran; Parser liefern scheinbar fehlerfrei strukturierte, aber inhaltlich falsche Daten zurück.
• CrewAI -Delegationsschleifen divergieren bei nebenläufigen Task-Graphen.
• AutoGen führt pro Task über 20 LLM-Aufrufe zu je 0.45 $ durch, während eine deterministische Pipeline dasselbe Ergebnis mit weniger Aufrufen für 0.08 $ erzielt.

Diese Ausfälle lassen sich auf eine gemeinsame Architekturentscheidung zurückführen: dem Modell die Kontrolle über den Ausführungsfluss zu überlassen. Wenn das LLM entscheidet, welches Tool aufgerufen, welcher Zweig gewählt und wann gestoppt werden soll, erhält man Autonomie auf Demo-Niveau und Chaos im Produktivbetrieb. Die Lösung ist architektonischer Natur — verlagern Sie die Ablaufsteuerung in eine deterministische Engine, ein Ansatz, der ausführlich in unserem Whitepaper über die Architektur resilienter Enterprise-KI jenseits des LLM-Wrappers beschrieben wird, und lassen Sie das Modell nur das tun, worin Modelle wirklich gut sind: Reasoning über Inhalte innerhalb klar definierter Grenzen.

Wie wir deterministische KI-Pipelines aufbauen

Unser Ansatz nutzt Durable-Execution-Engines — Temporal, Prefect oder Inngest, ausgewählt auf Basis Ihrer bestehenden Infrastruktur — als Orchestrierungs-Backbone. Jeder Schritt ist eine Activity oder ein Task mit expliziten Eingaben, Ausgaben, Retry-Policies und Timeout-Budgets. Die Engine verwaltet den Zustand, behandelt Fehler und stellt die Checkpoint/Replay-Fähigkeit bereit, die ein zuverlässiges Debugging überhaupt erst ermöglicht.

An jedem Knoten, an dem ein LLM Ausgaben erzeugt, binden wir den Aufruf in eine Validierungsumgebung ein, die Ausgabeschemata mit dem jeweils passenden Werkzeug durchsetzt. Da jeder Ansatz unterschiedliche Fehlermodi aufweist, stimmen wir die Validierungsstrategie präzise auf die Fehlertoleranz und das Latenzbudget des jeweiligen Knotens ab:

Tool-Calling erfolgt über einen eingeschränkten Planer statt über uneingeschränkte LLM-Generierung. Anstatt dem Modell 50 Tools vorzulegen und zu hoffen, dass es die richtige Wahl trifft, filtern wir den Tool-Katalog anhand des aktuellen Workflow-Zustands, sodass das Modell nur die für diesen Schritt gültigen Tools sieht. Dies eliminiert halluzinierte Tool-Namen und ungültige Argumentationsmuster — die beiden häufigsten Fehlermodi beim Tool-Calling in der Produktion.

Checkpointing, Replay und das Kostenargument

Ein Drei-Agenten-Workflow, der in Demos 5–50 $ kostet, verursacht in der Produktion monatliche Rechnungen von 18.000 bis 90.000 $. 96% der Unternehmen berichten, dass die GenAI-Kosten ihre Erwartungen überstiegen haben. Der Großteil dieser Verschwendung entsteht durch die erneute Ausführung bereits erfolgreicher Schritte nach einem nachgelagerten Fehler.

Checkpointing verändert die Wirtschaftlichkeit grundlegend. Nach jedem abgeschlossenen Knoten speichert die Engine einen Snapshot des gesamten Zustands — Eingaben, Ausgaben, Metadaten, ausstehende Tasks. Tritt bei Schritt 7 von 10 ein Fehler auf, beheben Sie die Ursache und setzen bei Schritt 7 wieder an, nicht bei Schritt 1. LangGraph erzielt Fehlertoleranz-Raten von 96% mit diesem Ansatz. Das Durable-Execution-Modell von Temporal geht noch weiter: Es übersteht Prozessabstürze und setzt den Workflow exakt an der Stelle fort, an der er unterbrochen wurde — einschließlich laufender LLM-Aufrufe.

Wir konzipieren Checkpoint-Strategien mit:

• Deterministischen Thread-IDs , gekoppelt an Geschäftsentitäten — einen Kreditantrag, eine Patientenakte, eine Handelsbestätigung.
• Idempotenten externen Aufrufen , gesteuert über eine eindeutige Workflow- und Schritt-Identität.
• Gezielten Failure-Injection-Tests.

Allein durch Checkpointing reduziert sich der Verarbeitungsaufwand um 60% oder mehr bei mehrstufigen Workflows.

Tool-Governance im Produktivbetrieb

Die Einführung von MCP eilt den Sicherheitsstandards voraus. Ein Scan von rund 2.000 über das Internet erreichbaren MCP-Servern ergab bei sämtlichen Servern keinerlei Authentifizierung, wodurch schätzungsweise 200.000 Server gefährdet sind. Hinzu kommt ein massives Kostenproblem: Ein einzelner GitHub-MCP-Server verbraucht bereits für die Initialisierung rund 50.000 Tokens, und ein Datenbank-Server mit 106 Tools verschlingt 54.600 Tokens, bevor auch nur eine einzige Abfrage ausgeführt wird.

Wir konzipieren kontrollierte Tool-Schnittstellen, unabhängig davon, welches Protokoll Ihre Tools verwenden. Jeder Tool-Aufruf durchläuft eine Validierungsschicht, die Eingabetypen und Wertebereiche prüft, Rate-Limits und Ressourcenkontingente durchsetzt, das Ausgabeformat verifiziert und den vollständigen Aufrufkontext protokolliert. Die Tool-Auswahl erfolgt zustandsgesteuert: Die Workflow-Engine bestimmt anhand des aktuellen Zustands und der deklarierten Fähigkeiten des Schritts, welche Tools an jedem Punkt verfügbar sind. Dies ist keine Empfehlung an das Modell — es ist ein strikter Constraint, der auf Infrastrukturebene durchgesetzt wird.

Audit-First-Architektur für regulierte Branchen

SOX-Kontrollen, SR 11-7 Modellrisikomanagement, HIPAA, der EU AI Act und die FDA-Leitlinien für Clinical Decision Support erfordern allesamt eine Kombination aus Reproduzierbarkeit, Nachvollziehbarkeit und Erklärbarkeit. Ein nachträgliches Aufpfropfen von Observability auf ein Agenten-Framework nach dem Deployment genügt diesen Anforderungen nicht. Die Architektur selbst muss den Prüfpfad (Audit-Trail) lückenlos generieren.

Die von uns entwickelten Pipelines sind darauf ausgelegt, jeden LLM-Aufruf mit seinem vollständigen Prompt, der Antwort, dem Validierungsergebnis, dem Retry-Zähler und der Checkpoint-ID zu protokollieren. Jeder Zustandsübergang ist unveränderlich (immutable). Workflow-Definitionen sind versionskontrolliert und an spezifische Modellversionen gebunden, sodass Auditoren exakt die Pipeline rekonstruieren können, die ein historisches Ergebnis erzeugt hat. Für GxP-Umgebungen konzipieren wir Workflow-Versionen so, dass sie über formale Change-Control-Prozesse an validierte Modell-Checkpoints gekoppelt sind — die Art von deterministischer klinischer Pipeline, wie demonstriert in einer funktionsfähigen Demo für klinische KI-Sicherheit.