Guided Determinism: KI-Agenten auf Schienen setzen

Ein KI-Agent, der frei entscheiden darf, welche Tools er aufruft und in welcher Reihenfolge, ist ein beeindruckendes Demo. Und ein Risiko in der Produktion. Wer Agenten produktiv einsetzt, merkt schnell: Bei unkritischen Aufgaben funktioniert Autonomie. Bei allem mit echten Konsequenzen (Kundendaten, Finanztransaktionen, Deployments) braucht man Kontrolle.

Guided Determinism ist der Ansatz, der beides verbindet: Die Flexibilität eines LLMs, das natürliche Sprache versteht und auf unvorhergesehene Situationen reagieren kann, eingebettet in einen deterministischen Rahmen, der vorgibt, was wann passieren darf.

Das Problem mit autonomen Agenten

Traditionelle Software ist deterministisch. Gleicher Input, gleicher Output, gleicher Pfad. Ein Skript, das eine Rechnung erstellt, macht das morgen genauso wie heute.

KI-Agenten brechen dieses Muster. Sie treffen Entscheidungen auf Basis von Wahrscheinlichkeiten. Derselbe Prompt kann zu unterschiedlichen Tool-Aufrufen führen, in unterschiedlicher Reihenfolge, mit unterschiedlichen Ergebnissen. Für eine Recherche-Aufgabe ist das kein Problem. Für einen Workflow, der am Ende Geld überweist oder einen Server konfiguriert, schon.

Das Kernproblem hat Praetorian auf den Punkt gebracht: Viele Teams nutzen probabilistische Steuerung (Prompts) für deterministische Aufgaben. Das kann nicht gutgehen. Der Agent ist nicht der Workflow, er ist eine Komponente innerhalb des Workflows.

Was Guided Determinism bedeutet

Salesforce hat den Begriff in ihrem Engineering-Blog geprägt: Das LLM wird als nondeterministischer Kernel behandelt, eingebettet in eine deterministische Laufzeitumgebung. Konkret heißt das:

• Der Workflow ist ein gerichteter Graph mit definierten Knoten (Aufgaben) und Kanten (Übergänge)
• Die Runtime verwaltet den Zustand: Wo im Workflow steht der Agent, welche Daten hat er, was darf er als Nächstes tun?
• Das LLM entscheidet innerhalb eines Knotens, wie es die Aufgabe löst. Aber welche Aufgabe es als Nächstes bekommt, entscheidet die Runtime

Die Analogie: Ein Zug auf Schienen. Der Zug (LLM) kann beschleunigen und bremsen, aber die Schienen (Workflow) geben die Route vor. Weichen (Routing-Entscheidungen) können vom LLM gestellt werden, aber nur zwischen vordefinierten Optionen.

Fünf Patterns für die Praxis

Anthropic hat in "Building Effective Agents" fünf Workflow-Muster beschrieben, die sich kombinieren lassen und zeigen, wie Guided Determinism konkret aussieht.

Beim Prompt Chaining laufen Aufgaben sequenziell ab. Schritt 1 erzeugt Output, der als Input für Schritt 2 dient. Zwischen den Schritten können Validierungen stehen, die prüfen, ob das Zwischenergebnis den Anforderungen entspricht. Wenn nicht, wird wiederholt oder abgebrochen.

Routing bedeutet: Ein Klassifikator entscheidet, welcher spezialisierte Pfad für eine Anfrage zuständig ist. Der Unterschied zum Freitext-Agenten: Die Menge der möglichen Pfade ist vordefiniert. "Support-Anfrage" geht an den Support-Workflow, "Rechnungsfrage" an den Billing-Workflow, alles andere an einen Fallback.

Bei der Parallelisierung laufen mehrere Teilaufgaben gleichzeitig, zum Beispiel drei verschiedene Analysen auf denselben Datensatz, deren Ergebnisse am Ende zusammengeführt werden. Das spart Zeit und reduziert die Fehlerfortpflanzung, weil ein fehlgeschlagener Strang die anderen nicht beeinflusst.

Orchestrator-Workers funktionieren so: Ein koordinierender Agent verteilt dynamisch Aufgaben an spezialisierte Worker-Agenten. Der Orchestrator plant, die Workers führen aus, die Übergaben zwischen ihnen sind definierte Handoffs. Anders als beim Prompt Chaining wird die Aufgabenverteilung zur Laufzeit entschieden.

Beim Evaluator-Optimizer-Pattern erzeugt ein Agent Output, ein zweiter bewertet ihn. Wenn die Bewertung unter einem Schwellenwert liegt, geht der Output zurück. Das kann iterativ laufen, bis die Qualität stimmt oder ein Maximum an Versuchen erreicht ist. BMad nutzt dieses Muster mit dem Developer-Agent Devon und dem QA-Agent Quinn.

Guardrails: Vor und nach dem LLM

Guardrails sind die technischen Leitplanken, die den Handlungsraum des Agenten begrenzen. Sie fallen in zwei Kategorien:

Pre-LLM-Guardrails laufen vor jedem LLM-Aufruf. Sie sind schnell und deterministisch: Regex-basierte PII-Erkennung, Injection-Checks, Input-Validierung. Wenn eine Eingabe verdächtig aussieht, wird der LLM-Aufruf gar nicht erst gemacht. Das spart Tokens und verhindert Prompt Injection frühzeitig.

Post-LLM-Guardrails prüfen die Ausgabe des Modells, bevor sie wirksam wird: Halluzinations-Checks, Format-Validierung, Action-Validierung. Wenn ein Agent zum Ergebnis kommt, dass er eine Datei löschen soll, prüft der Post-Guard, ob der Agent diese Berechtigung überhaupt hat.

Am wirksamsten sind Tool-Allowlists. Der Agent darf nur explizit freigeschaltete Tools aufrufen. Ein Support-Agent hat Zugriff auf das CRM, aber nicht auf die Datenbank. Ein Code-Review-Agent darf Dateien lesen, aber nicht schreiben. Klingt simpel, verhindert aber mehr Unfälle als jede andere Einzelmaßnahme. Welche konkreten Angriffsvektoren durch fehlende Einschränkungen entstehen, zeigt die OWASP Top 10 für Agentic AI.

Audit-Trails: Warum hat der Agent das getan?

Wer Agenten in Bereichen mit Compliance-Pflichten einsetzt, braucht Nachvollziehbarkeit. Ein Agent Decision Record (ADR) dokumentiert für jede Agentenentscheidung:

• Welche Eingaben lagen vor?
• Welche Regeln wurden geprüft?
• Welches Modell in welcher Version wurde verwendet?
• Was hat der Agent entschieden und warum?
• Hat ein Mensch eingegriffen?

Das ist kein Nice-to-have. Für Workflows in regulierten Bereichen (Fintech, Healthtech, öffentliche Verwaltung) ist das die Grundlage, um bei einer Prüfung erklären zu können, warum ein automatisiertes System eine bestimmte Entscheidung getroffen hat.

Frameworks

Zwei Open-Source-Frameworks werden aktuell am häufigsten für deterministische Agent-Workflows genutzt:

LangGraph modelliert Agenten als gerichtete Graphen. Knoten sind Funktionen oder LLM-Aufrufe, Kanten definieren den Kontrollfluss. Der Zustand wird als typisiertes Dictionary durch den Graphen geleitet. LangGraphs Stärke ist durable execution: Wenn ein Agent bei Schritt 7 von 12 abstürzt, wird er an genau dieser Stelle fortgesetzt.

CrewAI denkt in Teams statt in Graphen. Agenten bekommen Rollen, Backstories und Ziele. Seit 2025 gibt es zusätzlich einen "Flows"-Modus für event-getriebene Pipelines. CrewAI ist intuitiver für Workflows, die sich als Teamarbeit beschreiben lassen. LangGraph gibt mehr Kontrolle über den exakten Kontrollfluss.

Die Wahl hängt vom Anwendungsfall ab. Für komplexe, zustandsbehaftete Workflows mit vielen Verzweigungen ist LangGraph die bessere Wahl. Für Workflows, die sich als Zusammenarbeit zwischen spezialisierten Rollen beschreiben lassen, ist CrewAI zugänglicher.

Was das für Teams heißt

Guided Determinism ist kein Framework, das man installiert, sondern ein Architekturmuster. Die Umsetzung sieht je nach Kontext anders aus, aber die Grundprinzipien bleiben:

1. Den Workflow definieren, bevor der Agent ihn ausführt. Welche Schritte gibt es, welche Übergänge sind erlaubt, wo sind die Abbruchbedingungen?
2. Tool-Zugriff einschränken. Nur die Tools freigeben, die für den aktuellen Schritt nötig sind. Nicht alle Tools für alle Agenten.
3. Guardrails an beiden Enden. Input validieren, Output validieren, vor der Ausführung prüfen.
4. Menschliche Freigabe bei kritischen Aktionen. Automatisierung heißt nicht, dass niemand hinschaut. Es heißt, dass ein Mensch nur dann hinschauen muss, wenn es darauf ankommt.
5. Loggen, was der Agent tut. Nicht nur das Ergebnis, sondern den Entscheidungspfad. Wer das von Anfang an einbaut, spart sich die nachträgliche Compliance-Nachrüstung.

Der pragmatische Einstieg: Mit einem unkritischen Workflow anfangen, der bisher manuell läuft. Den Workflow als Graph modellieren, Guardrails definieren, einen Agenten einsetzen. Erfahrungen sammeln, bevor die kritischen Prozesse dran sind.