Gleicher Prompt, vier Agents, vier Ergebnisse

Ich habe vier KI-Agents dieselbe Anweisung gegeben. Ich bekam vier verschiedene Ergebnisse. Nicht weil die Anweisung schlecht war — sondern weil stochastische Systeme genau das tun, was stochastische Systeme tun.

Das Setup, das einfach aussah

Ich war dabei, den PR-Workflow über vier Repositories hinweg zu optimieren, jedes mit einem eigenen Claude Code Agent. Ich hatte die Workflow-Regeln in allen Repos aktualisiert und fragte Claude Cowork, wie ich die laufenden Agents über die Änderung informieren kann — ohne alle Sessions neu zu starten.

Die Antwort war ein Einzeiler zum Einfügen in jede CLI: „Re-read CLAUDE.md — the PR workflow has changed. Create PRs as drafts first, then mark ready after CI passes.“

Copy. Paste. Paste. Paste. Paste. Vier Agents, gleicher Prompt, gleicher Kontext — vier verschiedene Interpretationen. Einer nahm es zur Kenntnis und machte weiter. Ein anderer fing an, seinen aktuellen PR zu „reparieren“. Der dritte entschied, dass seine laufende Arbeit umstrukturiert werden müsse. Was der vierte tat, kann ich bis heute nicht vollständig rekonstruieren.

Warum die Agents sich selbst diagnostizierten

Als ich Claude fragte, was schiefgelaufen war, diagnostizierte es seine eigene Art: „’Re-read CLAUDE.md‘ is ambiguous. Some agents will just acknowledge. Others will start ‚fixing‘ things. The safer instruction would have been explicit about what to do and what NOT to do.“

Ein KI-System, das erklärt, warum seine eigene Spezies eigene Anweisungen nicht zuverlässig befolgen kann. Das ist kein Bug Report — das ist ein Designconstraint, der sichtbar wird.

Das Galton Board in jedem Token

LLMs sind stochastische Systeme. Gleicher Input, unterschiedlicher Output — by Design. Jeder Token, den ein LLM generiert, ist eine probabilistische Entscheidung, geformt durch den Kontext, aber nie vollständig durch ihn determiniert. Wie ein Galton Board: Eine Kugel fällt von oben, prallt an jedem Stift nach links oder rechts ab. Lässt man sie erneut von derselben Position fallen — nimmt sie einen anderen Weg.

Wie LLMs Token für Token Entscheidungen treffen: eine Galton-Board-Analogie

Tokengenerierung funktioniert genauso. Bei jedem Schritt hat das Modell eine Wahrscheinlichkeitsverteilung über mögliche nächste Tokens. Temperature, Top-p-Sampling und Kontext formen diese Verteilung — aber sie eliminieren die Varianz nicht. Das Ergebnis ist ein Pfad durch einen Möglichkeitsraum, kein deterministisches Rechenergebnis.

Deshalb liefert derselbe Prompt unterschiedliche Ergebnisse. Nicht weil das Modell kaputt ist, sondern weil Interpretation das ist, was es tut. LLMs führen Anweisungen nicht aus — sie interpretieren sie. Und Interpretation variiert von Natur aus.

Die Unterscheidung, die wirklich zählt

Die Lektion aus meinem Vier-Agents-Vorfall ist nicht „schreib bessere Prompts“. Bessere Prompts reduzieren die Varianz, sie eliminieren sie nicht. Die eigentliche Lektion ist architektureller Natur: Wenn du einen Geschäftsprozess automatisierst, musst du entscheiden, welche Teile deterministisches Verhalten erfordern und welche Teile stochastisches Reasoning tolerieren — oder sogar davon profitieren.

Kreatives Reasoning, Problemzerlegung, Codegenerierung — hier ist die Fähigkeit des Modells, einen Möglichkeitsraum zu explorieren, ein Feature. Hier ist Stochastik eine Stärke.

Prozessausführung, Zustandsübergänge, Workflow-Orchestrierung — hier muss jedes Mal dasselbe Ergebnis herauskommen. Hier ist Stochastik ein Risiko.

Der Fehler ist nicht, KI in der Automatisierung einzusetzen. Der Fehler ist, einem probabilistischen System Wiederholbarkeit zuzutrauen, wo dein Prozess sie verlangt.

Für die Grenze designen

Die praktische Konsequenz: Nutze KI, um die Automatisierung zu entwerfen, dann nutze deterministische Regeln, um sie auszuführen. Lass das Modell darüber nachdenken, wie der Workflow aussehen sollte, welche Randfälle zu behandeln sind, was die Fehlerzustände sind. Dann codiere das Ergebnis in etwas, das ausführt — eine State Machine, eine Rule Engine, eine CI-Pipeline — nicht in einen weiteren Prompt.

Zuverlässigkeit und Intelligenz sind unterschiedliche Systemeigenschaften. Deine Architektur sollte sie auch so behandeln.

Boris Heuer

Boris Heuer
AI Engineer & Consultant

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen