Determinismus entsteht um das Modell herum, nicht in ihm

„Können Sie das deterministisch machen?“ Die Frage fällt in fast jedem Gespräch darüber, einen KI-Agenten in einen regulierten Prozess zu setzen. Das Risikomanagement stellt sie, die Revision stellt sie, und der Ingenieur, der später Bereitschaft hat, stellt sie auch. Es ist die richtige Frage, gestellt an die falsche Komponente.

Im September 2025 schickte ein Team von Thinking Machines Lab denselben Prompt tausendmal an dasselbe Open-Weight-Modell, mit Temperatur null, also der Einstellung, die den Zufall eigentlich abschalten soll. Zurück kamen achtzig verschiedene Antworten. Die Ursache war nicht das Sampling, sondern die Arithmetik: Das Ergebnis einer Matrixmultiplikation auf einem Beschleuniger hängt davon ab, wie die Arbeit gebündelt wird, und die Bündelung hängt davon ab, wie viele Anfragen anderer Leute im selben Moment eintreffen. Mit Rechenkernen, denen die Batch-Größe gleichgültig ist, waren alle tausend Antworten identisch, um den Preis geringerer Geschwindigkeit. Gehostete APIs versprechen das nicht; Anthropic schreibt in der eigenen Dokumentation, dass Ergebnisse selbst bei Temperatur null nicht vollständig deterministisch sind, und die neuesten Modelle nehmen den Parameter gar nicht mehr an.

Die ehrliche Antwort hat also zwei Hälften. Nein: Das Modell wird nicht deterministisch, und ein reproduzierbares Modell wäre dort, wo es irrt, nur reproduzierbar im Irrtum. Ja: Das System kann es sein, in den Eigenschaften, auf die es ankommt. Als Beispiel dient hier Claude Code, der Coding-Agent von Anthropic, weil seine Architektur die Grenze zwischen Anweisung und Durchsetzung scharf zieht und sie dokumentiert. Das Muster lässt sich auf jeden Agenten übertragen, den Sie bauen oder kaufen.

Sie brauchen Invarianten, nicht identische Tokens

Niemand braucht zweimal dieselben Tokens. Ein regulierter Prozess braucht, dass bestimmte Eigenschaften des Ergebnisses in jedem Lauf gelten. Es gibt fünf Arten:

• Nie. Nichts geht ungefragt in Produktion; kein Kundendatensatz verlässt das Haus.
• Immer. Jede Änderung wird formatiert, getestet und protokolliert.
• In Reihenfolge. Erst der Plan, dann die Änderung; erst das Review, dann der Merge.
• In Form. Die Ausgabe lässt sich parsen, die Felder sind da, die Typen stimmen.
• Vor Freigabe. Nichts geht hinaus, ohne dass eine Prüfung bestanden ist.

Für Agenten wiegt das schwerer als für Chatbots, und der Grund ist Arithmetik. Die Aufgabe eines Agenten ist eine Kette aus Lesen, Suchen, Ändern, Ausführen und Korrigieren, oft Dutzende Schritte lang. Gelingt jeder Schritt mit Wahrscheinlichkeit p, gelingen n unabhängige Schritte mit p hoch n. Fünfundneunzig Prozent je Schritt sind 36 Prozent über zwanzig Schritte.

Die τ-bench-Studie von 2024 ließ jede Kundenservice-Aufgabe achtmal lösen, bei Temperatur null. Im Bereich Einzelhandel löste der damals beste Agent etwa 61 Prozent der Aufgaben in einem Versuch und weniger als 25 Prozent in allen acht. Die Modelle sind seither deutlich besser geworden. Die Multiplikation nicht.

Dieselbe Arithmetik läuft auch in die andere Richtung, und das ist die nützlichste Zahl dieses Artikels. Setzen Sie hinter einen Schritt eine deterministische Prüfung (einen Compiler, einen Test, einen Schema-Validator) und lassen Sie den Agenten es erneut versuchen, wenn sie fehlschlägt. Eine Wiederholung macht aus einem 90-Prozent-Schritt einen 99-Prozent-Schritt, zwei machen 99,9 daraus. Über zwanzig Schritte sind das 12 Prozent, dann 82, dann 98 (Abbildung 1). Kein Modellwechsel der letzten Jahre hat so viel gebracht, und dieser kostet eine Schleife und eine Prüfung. Er wirkt nur bei Fehlern, die ein Programm erkennen kann, und nur, wenn die Fehlermeldung der Prüfung zum Modell zurückfließt: Ein zweiter Versuch, der nicht weiß, woran der erste gescheitert ist, scheitert meist genauso.

Eine Anweisung im Kontextfenster ist eine Wahrscheinlichkeit, keine Kontrolle

Alles, was ein Modell als Text erreicht, wirkt auf dieselbe Weise: Es verschiebt die Wahrscheinlichkeiten dessen, was als Nächstes kommt. Systemprompt, Projektanweisungen, abgerufene Dokumente und das Gespräch sind Tokens in einem Fenster und konkurrieren um dieselbe Aufmerksamkeit. Eine gut geschriebene Anweisung verschiebt viel. Keine verschiebt auf hundert Prozent.

Die Dokumentation von Claude Code ist da offen. CLAUDE.md, die Anweisungsdatei des Projekts, wird in jede Sitzung geladen, und die Dokumentation nennt sie „context, not enforced configuration“: Kontext, keine durchgesetzte Konfiguration. Sie kommt als Nachricht nach dem Systemprompt an, nicht als Teil davon. Befolgung ist nicht garantiert; widersprechen sich zwei Anweisungen, wählt das Modell womöglich irgendeine. Und die Befolgung sinkt mit der Länge der Datei: Empfohlen sind weniger als zweihundert Zeilen.

Mitte 2025 gab der IFScale-Benchmark zwanzig Modellen bis zu fünfhundert einfache Anweisungen gleichzeitig; das beste befolgte 68 Prozent. Eine Replikation durch einen Observability-Anbieter sieht die Grenze der neuesten Modelle 2026 eher bei zweitausend. Die Grenze wandert; sie verschwindet nicht, und eine Anweisungsdatei teilt sich das Fenster mit der Aufgabe, dem Code und jedem Tool-Ergebnis. Jede Regel, die Sie hinzufügen, macht jede einzelne ein wenig weniger wert.

Die Mittel dieser Schicht sind deshalb Mittel der Kontextökonomie, dieselbe Disziplin wie beim Budgetieren eines Kontextfensters:

• CLAUDE.md enthält, was in jeder Sitzung gilt: Befehle, Konventionen, Aufbau, frühere Fehler. Sie wird neu aus der Datei gelesen, wenn das Gespräch verdichtet wird; eine Anweisung, die nur im Chat fiel, nicht.
• Regeln unter .claude/rules/ können ein Pfadmuster tragen und laden dann nur, wenn der Agent passende Dateien anfasst: Regeln zur Barrierefreiheit, während eine Komponente offen ist, nicht während einer Datenbankmigration.
• Skills sind Verfahren mit gestufter Offenlegung: Eine kurze Beschreibung liegt im Fenster, bis der Skill gebraucht wird, dann lädt der eigentliche Inhalt. Mitgelieferte Skripte laufen, ohne dass ihr Quelltext in den Kontext gelangt.
• Subagenten geben einer Nebenaufgabe ein frisches Fenster und liefern nur das Ergebnis zurück.

Alle erhöhen die Wahrscheinlichkeit. Keines macht sie zu eins. Dies ist die Schicht für Urteil und Wissen: Konventionen, Vokabular, Architektur, die Gründe hinter Entscheidungen, alles, was ein Programm nicht prüfen kann. Der Fehler liegt darin, hier Anforderungen zu belassen, die jedes Mal gelten müssen.

Eine Garantie ist Code, der läuft, ohne das Modell zu fragen

Folgen Sie einer einzelnen Aktion durch den Harness, das Programm um das Modell herum (Abbildung 2). Das Modell schlägt einen Tool-Aufruf vor, etwa git push. Dieser Vorschlag ist seine einzige Stimme. Alles danach entscheidet jemand anderes.

Hooks sind Ihr Code, den der Harness an festen Punkten seines Ablaufs ausführt; die Dokumentation selbst nennt das, was sie liefern, deterministische Kontrolle. Ein PreToolUse-Hook erhält den vorgeschlagenen Aufruf als JSON und kann ihn blockieren, einem Menschen vorlegen, seine Eingabe umschreiben oder ihn durchlassen. Eine Blockade gilt in jedem Berechtigungsmodus, auch in dem, der alle Rückfragen überspringt.

Berechtigungsregeln folgen, in fester Reihenfolge: deny, dann ask, dann allow; der erste Treffer zählt. Ein Deny aus irgendeiner Einstellungsdatei schlägt ein Allow aus jeder anderen, und eine Organisation kann verwaltete Einstellungen ausrollen, die keine Nutzer- oder Projektdatei überschreibt. Ein Hook kann das verschärfen, nicht lockern: Ein Hook, der „allow“ sagt, kommt an einer Deny-Regel nicht vorbei.

Die Sandbox ist der Punkt, an dem die Garantie nicht mehr davon abhängt, einen Befehl richtig zu lesen. Die Dokumentation nennt Berechtigungsmuster, die Shell-Argumente einschränken wollen, fragil und verweist für Grenzen, die halten müssen, auf die Sandbox. Dort setzt das Betriebssystem (Seatbelt unter macOS, bubblewrap unter Linux) Datei- und Netzgrenzen für jeden Shell-Befehl und seine Kindprozesse durch, selbst wenn eine Prompt Injection die Entscheidungen des Modells übernommen hat.

PostToolUse-Hooks laufen nach jeder Aktion: formatieren, linten, testen, protokollieren. Stop-Hooks laufen, wenn das Modell die Aufgabe für erledigt erklärt, und können widersprechen: erst, wenn die Tests bestehen.

{
  "permissions": {
    "deny": ["Read(./.env)", "Edit(/public/.htaccess)"],
    "ask": ["Bash(git push *)"]
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npm run check >&2 || exit 2" }
        ]
      }
    ]
  }
}

Wenige Zeilen, vier Garantien: ein Geheimnis, das die Datei-Tools nicht lesen können, eine generierte Datei, die sie nicht ändern können, ein Mensch vor jedem Push und eine Typprüfung nach jeder Änderung. Das exit 2 sorgt dafür, dass deren Befunde beim Modell ankommen und nicht nur bei Ihnen.

Zwei Grenzen. Ein Hook kann auch vom Typ prompt oder agent sein: Dann bewertet ein Modell, was für Ermessensfragen nützlich und wieder probabilistisch ist. Dasselbe gilt für den Auto-Modus, seit August 2026 Standard in Anthropics Einzel- und Team-Tarifen, in dem ein Klassifikationsmodell an der Freigabeabfrage für den Menschen einspringt. Deny- und Ask-Regeln werden davor ausgewertet; eine Ask-Regel hält also einen Menschen vor den Aktionen, auf die es ankommt. Und Hooks laufen mit Ihren vollen Nutzerrechten. Prüfen und versionieren Sie sie wie Code.

Reihenfolge und Form gehören in Code

2024 traf Anthropic eine nützliche Unterscheidung: Workflows orchestrieren Modelle und Werkzeuge über vordefinierte Codepfade, Agenten steuern ihren Ablauf selbst. Die Ingenieursfrage lautet nie Agent oder Workflow. Sie lautet, welcher Teil des Plans vorab bekannt sein kann, denn dieser Teil gehört in Code.

Die dynamischen Workflows von Claude Code sind die wörtliche Umsetzung. Eine JavaScript-Datei hält die Schleife, die Verzweigungen und die Zwischenergebnisse. Jeder agent()-Aufruf darin ist ein probabilistischer Arbeiter, aber welche Arbeiter laufen, in welcher Reihenfolge, wie viele parallel, und dass auf jeden Befund ein Prüfschritt folgt, entscheidet das Skript. Die Dokumentation fasst den Unterschied in eine Frage: Wer hält den Plan? Das Skript darf weder die Uhr lesen noch Zufallszahlen ziehen (beide Aufrufe werfen Fehler), damit ein fortgesetzter Lauf dieselben Aufrufe wiederholt. Und ein Arbeiter mit Schema muss JSON liefern, das validiert; nach fünf Fehlversuchen schlägt der Aufruf fehl, statt Prosa durchzureichen.

Form ist die am besten verstandene Garantie. Structured Outputs der API übersetzen ein JSON-Schema in eine Grammatik, die die Token-Erzeugung beschränkt, sodass sich eine vollständige Antwort immer parsen lässt. Damit ist die Form geklärt. Ob der Wert im Feld stimmt, ist eine andere Frage, und sie braucht eine eigene Prüfung.

Am weitesten treibt die Forschung die Idee. In CaMeL von Google DeepMind und der ETH Zürich führt ein Interpreter einen Kontrollfluss aus, der aus der vertrauenswürdigen Anfrage abgeleitet ist; nicht vertrauenswürdige Daten können nie ändern, welche Tools aufgerufen werden. Das System löste 77 Prozent eines gängigen Agenten-Benchmarks mit beweisbarer Sicherheit, gegenüber 84 Prozent ohne Schutz. Sieben Punkte sind der Preis eines Beweises.

Menschliche Führung gehört in die Entwurfszeit, Entscheidungen an wenige Punkte

Der Reflex ist, für jede Aktion einen Menschen in der Schleife zu halten. Die Daten sagen, dass das die schwächste Kontrolle im ganzen Aufbau ist. Anthropic berichtete im August 2026, dass Nutzer von Claude Code 97 Prozent der Einzelfreigaben bestätigen. In einer kontrollierten Studie begegnete 1.053 bezahlten Testern je ein eindeutig gefährlicher Befehl im Strom der Abfragen. Sie stoppten ihn in 13,6 Prozent der Fälle: etwa 17 Prozent früh in einer Sitzung, etwa 5 Prozent nach fünfzig Abfragen. Das sind Zahlen eines Anbieters, veröffentlicht, um einen Klassifikator als Standardprüfer zu begründen. Sie passen aber zu Jahrzehnten der Human-Factors-Forschung über Gewöhnung, und der AI Act nennt das Phänomen in seinem Aufsichtsartikel beim Namen: Automatisierungsbias.

Derselbe Bericht enthält die Zahl, die auf die Lösung zeigt: Dieselben Nutzer lehnen 39 Prozent der Pläne ab. Urteilskraft lebt auf der Ebene der Absicht, nicht des Tastendrucks. Führung wandert also dorthin, wo sie wirkt:

• In die Entwurfszeit. Menschen schreiben die Anweisungsdateien, die Berechtigungsregeln, die Hooks und die Workflow-Skripte, in der Versionsverwaltung, geprüft wie Code. Einmal geschrieben, in jedem Lauf angewandt.
• An den Plan. Der Planmodus ist durchgesetzt, nicht erbeten: Änderungen bleiben blockiert, bis ein Mensch den Plan freigibt.
• An das Unumkehrbare. Ask-Regeln für die wenigen Aktionen, die die Maschine verlassen: pushen, ausrollen, senden, zahlen, löschen. Eine im Gespräch gezogene Grenze genügt nicht: Die Dokumentation vermerkt, dass sie verloren gehen kann, wenn der Kontext verdichtet wird.
• An das Ergebnis. Ein Diff, ein Pull Request, ein zweites Paar Augen.

Auch das Rückgängigmachen hat Grenzen: Checkpoints setzen die Dateiänderungen des Agenten zurück, nicht die Nebenwirkungen von Shell-Befehlen oder irgendetwas außerhalb der Maschine; dort muss die Prüfung vor der Aktion stehen. Und es folgt eine Pflegeregel: Eine Korrektur, die Sie zweimal tippen, gehört in die Anweisungsdatei; ein Verstoß, der einmal gezählt hat, wird zu einer Prüfung im Code.

Legen Sie jede Anforderung dorthin, wo etwas sie tatsächlich halten kann

Zwei Fragen sortieren jede Anforderung an einen Agenten (Abbildung 3). Wäre ein einziger Verstoß ein Vorfall? Wenn nicht, ist sie Anleitung, und das sind die meisten. Wenn doch: Kann ein Programm entscheiden, ob sie gilt? Wenn nicht, entscheidet ein Mensch, an einem Punkt, den Sie entworfen haben. Wenn ja, kodieren Sie sie, je nach Art.

Was gelten muss	In Claude Code	In jedem Agenten-Stack	Was es nicht abdeckt
Es geschieht nie	Deny-Regeln, Sandbox, ein Subagent ohne das Tool	Minimale Rechte, Egress-Regeln	Muster auf Shell-Text sind fragil; Isolation auf Betriebssystemebene ergänzen
Es geschieht immer	Command-Hooks an festen Ereignissen	Middleware um jeden Tool-Aufruf	Von einem Modell bewertete Hooks sind wieder probabilistisch
Es geschieht in Reihenfolge	Workflow-Skripte, Planmodus	Orchestrierungscode, Pipeline-Stufen	Der Inhalt jedes Schritts bleibt Modellausgabe
Es hat diese Form	Schemas, Structured Outputs	Constrained Decoding, Validatoren	Gültig heißt nicht wahr
Nichts geht ungeprüft hinaus	Stop-Hooks, ein Verifier, CI	Tests, Build-Gates, Review	Nur, was die Prüfung prüft

Das Repository hinter dieser Website arbeitet so. Seine Arbeitsvereinbarung für den Coding-Agenten sagt: keine Anfragen an Dritte. Dieser Satz ist ein Rat. Wahr macht ihn ein Verifier, der den Build und damit das Deployment scheitern lässt, sobald ein Skript oder Stylesheet auf einen fremden Host zeigt. Der Satz sagt dem Agenten, was ich will; das Skript stellt sicher, dass ich es bekomme. Wo eine Anforderung nur den Satz hat, weiß ich, was als Nächstes zu schreiben ist.

Was das für eine regulierte Organisation bedeutet

Nachweise liegen in der deterministischen Schicht. Berechtigungsdateien in der Versionsverwaltung, verwaltete Einstellungen, Hook-Skripte, Pipeline-Logs: Das sind Artefakte, die eine Prüferin lesen kann. Für Hochrisiko-Systeme verlangt der AI Act in das System eingebaute Aufsichtsmaßnahmen (Artikel 14), automatische Aufzeichnung von Ereignissen (Artikel 12) und gleichbleibende Leistung (Artikel 15); seit dem Omnibus von 2026 ab Dezember 2027 für eigenständige Systeme. Auch wo die Verordnung für Ihren Agenten nicht gilt, ist dies das Vokabular, das Ihre zweite Verteidigungslinie benutzen wird. „Wir haben dem Modell gesagt, es soll das nicht tun“ ist keine Kontrollbeschreibung.

Garantien außerhalb des Modells überleben einen Modellwechsel. Modell-Updates ändern Verhalten; Deny-Regeln, Hooks und Prüfungen ist es gleich, welches Modell die Aktion vorgeschlagen hat. Je mehr Ihrer Absicherung in der Hülle liegt, desto billiger der Wechsel. Das meint DORA mit einer Ausstiegsstrategie, und deshalb lohnt es sich, Lock-in durch Modellverhalten vor der Unterschrift zu bepreisen.

Planen Sie Budget für die Hülle ein. Der verlässliche Teil eines Agentensystems ist gewöhnliche Software: Richtlinien, Skripte, Tests und Pipelines, mit eigenen Verantwortlichen und Reviews. Der größte Teil der Ingenieursarbeit an einem verlässlichen Agenten ist keine KI-Arbeit.

Fragen Sie bei jeder Anforderung an einen Agenten: Wer setzt das durch, wenn das Modell es nicht tut? Lautet die Antwort „der Prompt“, ist es ein Wunsch.