Die Grenzen eines einzelnen Prompts: Warum Reasoning keine Präzision garantiert
K
Kuba
KI-Engineering bei ASKEN
Je länger ein Modell vor der Antwort „nachdenkt“, desto höher die Wahrscheinlichkeit einer korrekten Antwort — eine Annahme, die man leicht unkritisch übernimmt. Wir haben sie empirisch anhand dreier Aufgaben geprüft, die mechanische, überprüfbare Präzision erfordern. Das Ergebnis ist komplexer, als es zunächst scheint.
Was ist ein einzelner Prompt?
Ein einzelner Prompt ist die einfachste Möglichkeit, ein Sprachmodell zu nutzen — genau die, die die meisten von uns aus alltäglichen Gesprächen mit ChatGPT kennen: Wir schreiben eine Frage oder Anweisung, das Modell erzeugt eine Antwort, und damit ist der Vorgang beendet. Das Modell kann nicht prüfen, ob das gerade Geschriebene korrekt ist. Es verwendet keinen Taschenrechner, führt keinen Code aus und berät sich nicht mit sich selbst. Es sagt lediglich das nächste Wort voraus, dann das folgende, bis der Satz fertig ist. Was dabei entsteht, erhalten wir als fertige Antwort.
Dieser Ansatz funktioniert hervorragend bei Gesprächen, beim Schreiben von Texten oder Zusammenfassungen, für die es keine einzelne, eindeutig richtige Antwort gibt. Unsere Frage war: Was passiert, wenn eine Aufgabe genau eine korrekte Antwort hat und mechanische Präzision erfordert, etwa das Ergebnis einer Multiplikation oder die exakte Zeichenzahl eines Textes? Garantiert allein die Aufforderung, „länger nachzudenken“ — also reasoning_effort zu erhöhen — diese Präzision?
Die Tests liefen über Azure OpenAI auf einem Modell der GPT-5.6-Familie. Der Parameter reasoning_effort steuert, wie viele „Denk“-Tokens das Modell vor der Antwort verbraucht, von none bis xhigh. Um systematische Probleme von zufälligen Schwankungen beim Sampling zu unterscheiden, wiederholten wir jede Kombination aus Aufgabe und Reasoning-Stufe viermal.
Drei Aufgaben, eine Gemeinsamkeit
Wir wählten drei Aufgaben, deren Ergebnisse eindeutig richtig oder falsch sind:
Multiplikation — das exakte Produkt zweier vierstelliger Zahlen.
Zeichen — ein Text mit einer exakt vorgegebenen Anzahl von Zeichen, nicht Wörtern.
Buchstaben — die Anzahl der Vorkommen eines bestimmten Buchstabens in einem zufälligen Text mit ungefähr 350 Zeichen bestimmen.
Ergebnisse: Die Erfolgsquote steigt mit dem Reasoning-Aufwand, aber nicht linear
Aufgabe
none
low
medium
high
xhigh
Multiplikation
0 %
100 %
100 %
100 %
100 %
Zeichen
0 %
0 %
50 %
50 %
100 %
Buchstaben
0 %
100 %
100 %
75 %
100 %
Bei effort=none scheitern alle drei Aufgaben in 100% der Versuche. Überraschend ist, was danach geschieht. Bei der Aufgabe Buchstaben schneidet high (75%) schlechter ab als low und medium (100%). Mehr Reasoning bedeutet also nicht automatisch ein besseres Ergebnis. Eine höhere Stufe erhöht die Wahrscheinlichkeit eines Treffers, garantiert ihn aber nicht.
Warum passiert das?
Bei effort=none sollte das Modell 3471 × 6305 = 21.884.655 berechnen. Es gab „218637?“ zurück — eine Zahl, die nicht nur falsch, sondern auch strukturell unvollständig war. Das veranschaulicht den Mechanismus: Das Modell erzeugt eine Antwort Token für Token in eine Richtung, ohne die eigene Ausgabe zu überprüfen. Es gibt keinen Schritt „Prüfe, ob das stimmt“. Reasoning gibt dem Modell mehr „Raum“, das Problem vor der Antwort aufzuschlüsseln, verändert aber nicht die grundlegende Architektur: Es bleibt eine Generierung in eine Richtung ohne Rückkopplungsschleife.
Die Kosten wachsen schneller als die Sicherheit
Mehr Reasoning bedeutet höhere Kosten — wir bezahlen für die „Denk“-Tokens, nicht nur für die Antwort.
Aufgabe
none
low
medium
high
xhigh
Multiplikation
0,000075 $
0,000382 $
0,000425 $
0,000584 $
0,000473 $
Zeichen
0,000342 $
0,010084 $
0,010458 $
0,014829 $
0,014225 $
Buchstaben
0,000249 $
0,003133 $
0,004803 $
0,005837 $
0,006423 $
Bei der Aufgabe Zeichen steigen die Kosten von 0,0003 USD (none) auf 0,0142 USD (xhigh) — ungefähr das Vierzigfache. Die Erfolgsquote bei xhigh erreicht tatsächlich 100%, bei high liegt sie jedoch nur bei 50%. Wir bezahlen mehr, ohne immer mehr Sicherheit zu erhalten.
Buchstaben: durchschnittliche Kosten eines einzelnen Prompts
Reasoning-Stufe
Durchschnittliche Kosten (USD)
Erfolgsquote
none
0,000249 $
0 %
low
0,003133 $
100 %
medium
0,004803 $
100 %
high
0,005837 $
75 %
xhigh
0,006423 $
100 %
Durchschnittliche Kosten und Erfolgsquote für Buchstaben auf fünf Reasoning-Stufen. Jede Konfiguration wurde viermal getestet.
Zeichen: durchschnittliche Kosten eines einzelnen Prompts
Reasoning-Stufe
Durchschnittliche Kosten (USD)
Erfolgsquote
none
0,000342 $
0 %
low
0,010084 $
0 %
medium
0,010458 $
50 %
high
0,014829 $
50 %
xhigh
0,014225 $
100 %
Durchschnittliche Kosten und Erfolgsquote für Zeichen auf fünf Reasoning-Stufen. Jede Konfiguration wurde viermal getestet.
Wie geht es weiter?
Da das Problem in der fehlenden Überprüfung liegt, ist der nächste naheliegende Schritt, dem Modell ein Werkzeug zu geben, das diese übernimmt. Im nächsten Beitrag untersuchen wir, was Codeausführung leistet und wo sie weiterhin an Grenzen stößt.
Die Grenzen eines einzelnen Prompts: Warum Reasoning keine Präzision garantiert
Je länger ein Modell vor der Antwort „nachdenkt“, desto besser die Antwort — so eine verbreitete Annahme. Wir haben sie empirisch geprüft.
Kuba
KI-Engineering
Codeausführung: Was sie löst — und was nicht
Ein einzelner Prompt scheitert, weil das Modell Antworten Token für Token ohne Überprüfung erzeugt. Was passiert, wenn wir ihm einen Python-Interpreter geben?
Kuba
KI-Agenten
Die Agentenschleife: Überprüfung und Korrektur als Grundlage der Zuverlässigkeit
Codeausführung löst mechanische Aufgaben perfekt, scheitert aber, wenn das Modell seine eigene Ausgabe beurteilen muss. Hier kommt die Agentenschleife ins Spiel.
Kuba
Je länger ein Modell vor der Antwort „nachdenkt“, desto höher die Wahrscheinlichkeit einer korrekten Antwort — eine Annahme, die man leicht unkritisch übernimmt. Wir haben sie empirisch anhand dreier Aufgaben geprüft, die mechanische, überprüfbare Präzision erfordern. Das Ergebnis ist komplexer, als es zunächst scheint.
Was ist ein einzelner Prompt?
Ein einzelner Prompt ist die einfachste Möglichkeit, ein Sprachmodell zu nutzen — genau die, die die meisten von uns aus alltäglichen Gesprächen mit ChatGPT kennen: Wir schreiben eine Frage oder Anweisung, das Modell erzeugt eine Antwort, und damit ist der Vorgang beendet. Das Modell kann nicht prüfen, ob das gerade Geschriebene korrekt ist. Es verwendet keinen Taschenrechner, führt keinen Code aus und berät sich nicht mit sich selbst. Es sagt lediglich das nächste Wort voraus, dann das folgende, bis der Satz fertig ist. Was dabei entsteht, erhalten wir als fertige Antwort.
Dieser Ansatz funktioniert hervorragend bei Gesprächen, beim Schreiben von Texten oder Zusammenfassungen, für die es keine einzelne, eindeutig richtige Antwort gibt. Unsere Frage war: Was passiert, wenn eine Aufgabe genau eine korrekte Antwort hat und mechanische Präzision erfordert, etwa das Ergebnis einer Multiplikation oder die exakte Zeichenzahl eines Textes? Garantiert allein die Aufforderung, „länger nachzudenken“ — also reasoning_effort zu erhöhen — diese Präzision?
Die Tests liefen über Azure OpenAI auf einem Modell der GPT-5.6-Familie. Der Parameter reasoning_effort steuert, wie viele „Denk“-Tokens das Modell vor der Antwort verbraucht, von none bis xhigh. Um systematische Probleme von zufälligen Schwankungen beim Sampling zu unterscheiden, wiederholten wir jede Kombination aus Aufgabe und Reasoning-Stufe viermal.
Drei Aufgaben, eine Gemeinsamkeit
Wir wählten drei Aufgaben, deren Ergebnisse eindeutig richtig oder falsch sind:
Multiplikation — das exakte Produkt zweier vierstelliger Zahlen.
Zeichen — ein Text mit einer exakt vorgegebenen Anzahl von Zeichen, nicht Wörtern.
Buchstaben — die Anzahl der Vorkommen eines bestimmten Buchstabens in einem zufälligen Text mit ungefähr 350 Zeichen bestimmen.
Ergebnisse: Die Erfolgsquote steigt mit dem Reasoning-Aufwand, aber nicht linear
Aufgabe
none
low
medium
high
xhigh
Multiplikation
0 %
100 %
100 %
100 %
100 %
Zeichen
0 %
0 %
50 %
50 %
100 %
Buchstaben
0 %
100 %
100 %
75 %
100 %
Bei effort=none scheitern alle drei Aufgaben in 100% der Versuche. Überraschend ist, was danach geschieht. Bei der Aufgabe Buchstaben schneidet high (75%) schlechter ab als low und medium (100%). Mehr Reasoning bedeutet also nicht automatisch ein besseres Ergebnis. Eine höhere Stufe erhöht die Wahrscheinlichkeit eines Treffers, garantiert ihn aber nicht.
Warum passiert das?
Bei effort=none sollte das Modell 3471 × 6305 = 21.884.655 berechnen. Es gab „218637?“ zurück — eine Zahl, die nicht nur falsch, sondern auch strukturell unvollständig war. Das veranschaulicht den Mechanismus: Das Modell erzeugt eine Antwort Token für Token in eine Richtung, ohne die eigene Ausgabe zu überprüfen. Es gibt keinen Schritt „Prüfe, ob das stimmt“. Reasoning gibt dem Modell mehr „Raum“, das Problem vor der Antwort aufzuschlüsseln, verändert aber nicht die grundlegende Architektur: Es bleibt eine Generierung in eine Richtung ohne Rückkopplungsschleife.
Die Kosten wachsen schneller als die Sicherheit
Mehr Reasoning bedeutet höhere Kosten — wir bezahlen für die „Denk“-Tokens, nicht nur für die Antwort.
Aufgabe
none
low
medium
high
xhigh
Multiplikation
0,000075 $
0,000382 $
0,000425 $
0,000584 $
0,000473 $
Zeichen
0,000342 $
0,010084 $
0,010458 $
0,014829 $
0,014225 $
Buchstaben
0,000249 $
0,003133 $
0,004803 $
0,005837 $
0,006423 $
Bei der Aufgabe Zeichen steigen die Kosten von 0,0003 USD (none) auf 0,0142 USD (xhigh) — ungefähr das Vierzigfache. Die Erfolgsquote bei xhigh erreicht tatsächlich 100%, bei high liegt sie jedoch nur bei 50%. Wir bezahlen mehr, ohne immer mehr Sicherheit zu erhalten.
Buchstaben: durchschnittliche Kosten eines einzelnen Prompts
Reasoning-Stufe
Durchschnittliche Kosten (USD)
Erfolgsquote
none
0,000249 $
0 %
low
0,003133 $
100 %
medium
0,004803 $
100 %
high
0,005837 $
75 %
xhigh
0,006423 $
100 %
Durchschnittliche Kosten und Erfolgsquote für Buchstaben auf fünf Reasoning-Stufen. Jede Konfiguration wurde viermal getestet.
Zeichen: durchschnittliche Kosten eines einzelnen Prompts
Reasoning-Stufe
Durchschnittliche Kosten (USD)
Erfolgsquote
none
0,000342 $
0 %
low
0,010084 $
0 %
medium
0,010458 $
50 %
high
0,014829 $
50 %
xhigh
0,014225 $
100 %
Durchschnittliche Kosten und Erfolgsquote für Zeichen auf fünf Reasoning-Stufen. Jede Konfiguration wurde viermal getestet.
Wie geht es weiter?
Da das Problem in der fehlenden Überprüfung liegt, ist der nächste naheliegende Schritt, dem Modell ein Werkzeug zu geben, das diese übernimmt. Im nächsten Beitrag untersuchen wir, was Codeausführung leistet und wo sie weiterhin an Grenzen stößt.
Im vorherigen Beitrag haben wir gezeigt, dass ein einzelner Prompt scheitert, weil das Modell Antworten Token für Token erzeugt, ohne das gerade Geschriebene zu überprüfen. Der nächste naheliegende Schritt ist ein Werkzeug, das diese Prüfung übernimmt: ein Python-Interpreter. Das Modell schreibt ein Skript, wir führen es aus, und was das Skript auf stdout ausgibt, behandeln wir als Antwort. Dies ist die erste von zwei agentischen Varianten in unserer Reihe.
Was ist Codeausführung?
Stellen Sie sich vor, wir geben jemandem einen Taschenrechner, anstatt ihn zu bitten, zwei große Zahlen im Kopf zu multiplizieren. Genau das leistet die Codeausführung. Statt das Modell um eine direkte Antwort zu bitten, lassen wir es ein kurzes Python-Programm schreiben, das die Antwort berechnet. Anschließend führen wir dieses Programm selbst aus.
Der Unterschied zu einem einzelnen Prompt ist grundlegend. Das Modell hört auf, im Kopf zu „rechnen“ oder zu „buchstabieren“, und überträgt diese Arbeit dem Python-Interpreter — einem Werkzeug, das im Gegensatz zum Modell bei einfacher Arithmetik oder beim Zeichenzählen keine Fehler macht. Das Modell konzentriert sich auf seine Stärken: die Aufgabe zu verstehen und passenden Code zu schreiben. Die mechanische Ausführung überlässt es einer Maschine, die genau dafür entwickelt wurde.
Wir testeten dies mit demselben Aufgabensatz wie zuvor: Multiplikation, Zeichen und Buchstaben, auf fünf Reasoning-Stufen. Jede Konfiguration wurde viermal wiederholt.
Ergebnisse: Zwei Aufgaben gelöst, eine scheitert weiterhin
Aufgabe
none
low
medium
high
xhigh
Multiplikation
100 %
100 %
100 %
100 %
100 %
Buchstaben
75 %
100 %
100 %
100 %
100 %
Zeichen
0 %
25 %
0 %
25 %
75 %
Bei der Multiplikation steigt die Erfolgsquote sofort auf 100%, selbst bei effort=none. Das Modell muss nicht mehr im Kopf rechnen. Es erzeugt lediglich print(6305 * 3471), und der Interpreter übernimmt die Multiplikation. Genau diese Problemklasse löst die Codeausführung vollständig: Aufgaben, bei denen die mechanische Ausführung das „Denken“ des Modells ersetzt. Auch Buchstaben erreicht schnell 100%, obwohl das Modell ohne Reasoning (75%) gelegentlich noch Fehler in der Zähllogik selbst macht.
Zeichen ist ein völlig anderer Fall, denn die Codeausführung löst dieses Problem nicht. Das Modell muss weiterhin die Länge des selbst geschriebenen Textes beurteilen und liegt dabei weiterhin falsch. Der einzige Unterschied: Nun geschieht dies über eine Assertion, die das Skript schlicht abbrechen lässt, statt eine falsche Antwort auszugeben.
Wenn der eigene Test gegen den Agenten arbeitet
Bei effort=none sollte das Modell einen Absatz über Programmierung mit genau 320 Zeichen schreiben. Es schrieb Code, der sich selbst überprüft:
text = ("Programming turns ideas into instructions that computers can "
"execute. It rewards curiosity, patience, and precise thinking, while "
"offering creative ways to solve problems...")
assert len(text) == 320
print(text)
Der vom Modell geschriebene Text hatte tatsächlich keine 320 Zeichen. Deshalb löste die Assertion eine Ausnahme aus, das Skript brach ab, und stdout blieb leer. Das zeigt die Grenzen dieses Ansatzes besonders deutlich. Das Modell schätzte nicht nur die Zeichenzahl falsch ein, sondern schrieb auch einen Test, der den Fehler erkannte — und ließ den fehlerhaften Code dennoch stehen, statt den Text zu korrigieren. Ihm fehlte der Mechanismus dafür: Es hatte eine einzige Chance und nutzte sie nicht.
Kosten: Das Werkzeug ist nicht immer günstiger
Bei Multiplikation liegen die Kosten ähnlich hoch wie beim einzelnen Prompt, bei effort=none sogar etwas niedriger. Kurzer Code ist günstiger als eine lange, in Textform ausgeführte Rechnung. Bei Zeichen verhält es sich jedoch umgekehrt: Die Codeausführung ist auf derselben Reasoning-Stufe deutlich teurer als ein gewöhnlicher Prompt und garantiert dennoch keinen Erfolg.
Multiplikation: einzelner Prompt und Codeausführung
Reasoning-Stufe
Einzelner Prompt
Codeausführung
none
0 %
100 %
low
100 %
100 %
medium
100 %
100 %
high
100 %
100 %
xhigh
100 %
100 %
Erfolgsquoten für Multiplikation. Die Codeausführung erreicht in diesen Tests bereits ab effort=none eine Erfolgsquote von 100%.
Buchstaben: einzelner Prompt und Codeausführung
Reasoning-Stufe
Einzelner Prompt
Codeausführung
none
0 %
75 %
low
100 %
100 %
medium
100 %
100 %
high
75 %
100 %
xhigh
100 %
100 %
Erfolgsquoten für Buchstaben. Ohne Reasoning zählt das Modell auch bei der Codeausführung gelegentlich falsch.
Zeichen: einzelner Prompt und Codeausführung
Reasoning-Stufe
Einzelner Prompt
Codeausführung
none
0 %
0 %
low
0 %
25 %
medium
50 %
0 %
high
50 %
25 %
xhigh
100 %
75 %
Erfolgsquoten für Zeichen. Auch auf hohen Reasoning-Stufen führt eine einmalige Codeausführung nicht immer zum Erfolg.
Wie geht es weiter?
Die Codeausführung löst mechanische Aufgaben zu 100%. Wo das Modell jedoch die Qualität der eigenen Ausgabe beurteilen muss, reicht eine einzige Chance für ein Skript nicht aus. Es fehlt ein Mechanismus, der das Modell über seinen Fehler informiert und ihm eine Korrektur ermöglicht. Im nächsten und letzten Beitrag der Reihe schließen wir diese Schleife.
Im vorherigen Beitrag haben wir gezeigt, dass ein Python-Interpreter mechanische Aufgaben zu 100% löst. Er hilft jedoch nicht dort, wo das Modell die Qualität seiner eigenen Ausgabe beurteilen muss. Der Agent hatte eine einzige Chance für ein Skript. Schlug dessen Assertion fehl, blieb lediglich eine leere Antwort. Es fehlte ein Mechanismus, der die Fehlerinformation zurückgibt und einen weiteren Versuch ermöglicht.
Was ist eine Agentenschleife?
Stellen Sie sich einen Schüler vor, der seine Hausaufgaben abgibt, sie mit einem markierten Fehler zurückbekommt, diesen korrigiert und die Arbeit erneut abgibt — so lange, bis die Aufgabe richtig gelöst ist. Genau so funktioniert die Agentenschleife. Bei der vorherigen Variante, der Codeausführung, schrieb das Modell ein Skript und hatte nur eine Chance. Scheiterte der Code, endete der Agent mit einer leeren Antwort und ohne Rückmeldung. In der Agentenschleife ergänzen wir das fehlende Element: Fehlerinformationen, die zum Modell zurückkehren, und die Möglichkeit eines erneuten Versuchs.
Praktisch läuft es so ab: Das Modell schreibt ein Skript, wir führen es aus. Ist das Ergebnis falsch oder wirft das Skript einen Fehler, geben wir dem Modell genau zurück, was schiefging — die Fehlermeldung sowie die erwartete und die tatsächliche Ausgabe — als nächste Nachricht im selben Gespräch. Das Modell sieht seinen Fehler und kann eine korrigierte Codeversion schreiben. Der Zyklus:
schreiben → ausführen → prüfen → korrigieren
wiederholt sich, bis die Aufgabe korrekt abgeschlossen oder die maximale Anzahl an Versuchen erreicht ist. Bei uns liegt diese Grenze bei fünf Durchläufen. Diese Rückmeldung zusammen mit der Korrekturmöglichkeit unterscheidet die Agentenschleife von der einfachen Codeausführung und macht einen enormen Unterschied für die Zuverlässigkeit.
Drei Ansätze, ein Diagramm
Wir testeten dies mit der Aufgabe Zeichen, die in beiden vorherigen Ansätzen am schlechtesten abschnitt.
Reasoning-Stufe
Einzelner Prompt
Codeausführung
Agentenschleife
none
0 %
0 %
50 %
low
0 %
25 %
100 %
medium
50 %
0 %
100 %
high
50 %
25 %
100 %
xhigh
100 %
75 %
100 %
Zeichen: Vergleich aller drei Ansätze
Reasoning-Stufe
Einzelner Prompt
Codeausführung
Agentenschleife
none
0 %
0 %
50 %
low
0 %
25 %
100 %
medium
50 %
0 %
100 %
high
50 %
25 %
100 %
xhigh
100 %
75 %
100 %
Erfolgsquoten für Zeichen: einzelner Prompt, Codeausführung und Agentenschleife auf fünf Reasoning-Stufen.
Ab der Stufe low erreicht die Agentenschleife eine Erfolgsquote von 100% — genau dort, wo der einzelne Prompt und die einmalige Codeausführung am häufigsten scheiterten. Überprüfung in Verbindung mit Korrektur erwies sich als wirksamer als eine bloße Erhöhung des Reasoning-Aufwands: Selbst auf der günstigsten, niedrigsten Reasoning-Stufe (low) schließt die Schleife die Aufgabe in 100% der Fälle ab, während der einzelne Prompt auf derselben Stufe überhaupt nicht zurechtkommt.
Bemerkenswert ist effort=none: Dort erreicht die Schleife nur eine Erfolgsquote von 50%. Rückmeldung allein hilft nicht, wenn das Modell nicht genügend „Rechenleistung“ hat, um die Fehlerinformation im nächsten Durchlauf sinnvoll zu nutzen. Die Agentenschleife ist für sich genommen keine Universallösung. Sie benötigt ein Mindestmaß an Reasoning, damit die Rückmeldung einen Nutzen hat.
Was kostet das in der Praxis?
Mehr Durchläufe bedeuten mehr Modellaufrufe und damit höhere Kosten. Ein höherer Reasoning-Aufwand verkürzt jedoch die Schleife. Das Modell nutzt die Rückmeldung aus dem vorherigen Versuch besser und benötigt weniger Durchläufe bis zum Erfolg.
Reasoning-Stufe
none
low
medium
high
xhigh
Durchschnittliche Durchläufe
3,50
2,50
1,75
1,75
1,50
Die Agentenschleife ist auf jeder Reasoning-Stufe am teuersten. Das ist nachvollziehbar: Wir bezahlen für mehrere Durchläufe statt für einen. Die Tabelle der Erfolgsquoten zeigt jedoch das vollständige Bild. Ein einzelner Prompt und Codeausführung „sparen“ Kosten, erkaufen dies aber mit einem Ausfallrisiko von bis zu 100% auf niedrigen Reasoning-Stufen. Die Agentenschleife kostet ab low mehr, bietet dafür aber Sicherheit. Bei Aufgaben, bei denen eine falsche Antwort tatsächlich Geld kostet — etwa weil sie direkt an den Kunden geht — sind einige Cent Unterschied pro Versuch ein geringer Preis für die Garantie eines korrekten Ergebnisses.
Zusammenfassung des gesamten Experiments
Ein einzelner Prompt erzeugt eine Antwort ohne Überprüfung. Deshalb garantiert selbst ein hoher Reasoning-Aufwand keine Präzision. Die Codeausführung führt mit dem Interpreter einen objektiven „Richter“ ein. Ohne Rückmeldung hat der Agent jedoch nur eine Chance. Erst die Verbindung dieser beiden Elemente — Überprüfung und Korrektur in einer Schleife — schafft echte Zuverlässigkeit. Dieser Ansatz ist nicht auf drei Testaufgaben beschränkt. Überall dort, wo sich die Korrektheit eines Ergebnisses automatisch prüfen lässt — durch Tests, Formatvalidierung oder Schemaabgleich — sollte dasselbe Muster aus Ausführen, Prüfen und Korrigieren ebenso wirksam sein.