Was ist ein 'Turn' in reins?

Was ist ein ‘Turn’ in reins? Bild: KI-generiert

Wer einem KI-Agenten schon einmal eine große Aufgabe übergeben hat, kennt das. Die Schleife bricht immer an derselben Stelle zusammen: in dem Moment, in dem das Modell von sich aus „Ich bin fertig" erklärt — obwohl es in Wahrheit nicht fertig ist.

reins ist ein Quest-CLI-Framework, das der KI diese Befugnis, die Fertigstellung zu erklären, entzieht und einer Maschine übergibt. Es zerlegt eine Arbeitsliste wie Quests in einem Spiel in einzelne Items, gibt sie der KI eines nach dem anderen, und die Frage „Ist es fertig?" entscheidet nicht das Wort der KI, sondern eine maschinelle Prüfung. Und in seinem Herzen sitzt eine kleine Einheit namens Turn.

Zwei Begriffe werden immer wieder auftauchen, sichern wir sie also zuerst.

Gate — ein Prüfer, der eine Einreichung mechanisch kontrolliert und PASS oder FAIL urteilt. Kein menschlicher Eindruck, keine Selbsteinschätzung der KI.
Ratchet — ein Zahnrad, das sich nur in eine Richtung dreht. Wir verwenden es in dem Sinn, dass ein durch einen Pass verriegeltes Item sich nie wieder öffnet.

Dieser Artikel folgt einem Turn von Anfang bis Ende, durch genau das, was er durchläuft. Der Turn wirkt klein, aber auseinandergenommen ist er reins im Miniaturformat.

Die sechs Kernelemente des Reins Engineering

Verdichtet man die Ingenieurskunst, auf der reins steht, auf eine Zeile, lautet sie: die Ingenieurskunst, die Befugnis zur Fertigstellungserklärung von der KI auf ein deterministisches Maschinen-Gate zu verlagern. „Deterministisch" ist hier kein schwieriges Wort. Es bedeutet: Dieselbe Eingabe liefert immer dasselbe Ergebnis. Ein Test besteht oder scheitert, und das Urteil von gestern unterscheidet sich nicht je nach Laune vom Urteil von heute.

In der Linie Prompt Engineering (die Worte wählen) → Context Engineering (den Kontext liefern) → Harness Engineering (die Zäune bauen) ist Reins der Zügel, der die Richtung vorgibt. Diese Ingenieurskunst setzt sich aus sechs Elementen zusammen.

#	Element	Eine Zeile	Kanonischer Satz
1	Maschinell beurteilte Fertigstellung	Die Fertigstellungsbedingung muss von einer Maschine mit ja/nein beantwortbar sein, und die Maschine urteilt — der KI wird die Befugnis entzogen, sich selbst für fertig zu erklären	„Fertigstellung wird vom Gate beurteilt, nicht behauptet"
2	Deterministisches Feedback	Fakten statt Meinungen — „wo, was es sein sollte, was es tatsächlich war" wird zum Signal, das auf die Korrektur zeigt	„Gib ihm Meinungen, und es schmeichelt; gib ihm Fakten, und es korrigiert"
3	Richtungskontext (Manual + Beispiele)	Wenn Feedback ein Korrektursignal ist, sind Manual und Beispiele Richtungssignale — keines kann das andere ersetzen	„Der Engpass ist nicht Intelligenz, sondern Kontext"
4	Ratchet Pattern (Vertragsverriegelung)	Ein bestandenes Item ist unveränderlich; die verbleibende Arbeit schrumpft nur — das Fertigwerden wird durch Struktur garantiert	`remaining(t+1) ≤ remaining(t)`
5	Fortschrittspersistenz	Der Fortschritt lebt außerhalb des Prozesses (auf der Festplatte) — selbst wenn die KI stirbt, bleibt der Fortschritt	„Agents are disposable; progress is cumulative."
6	Cheese-Abwehr (Domain-Gates)	Auch eine maschinelle Prüfung wird ausgetrickst, wenn sie nur die Hülle inspiziert — das Gate muss die echten Fakten seiner Domain erneut verifizieren	„Ein Gate hat eine Domain"

Es macht nichts, wenn die Begriffe der Tabelle noch fremd wirken. Der Turn ist die kleinste Einheit, in der diese sechs innerhalb eines einzigen Zyklus zusammentreffen — folgt man einem Turn bis zum Ende, findet jedes der sechs Elemente seinen Platz. Skizzieren wir die Karte vorab: compose, der erste Schritt des Turns, montiert den Richtungskontext und das deterministische Feedback; judge fällt das maschinelle Urteil (die Cheese-Abwehr ist die Designqualität dieses Gates); record verriegelt das Ratchet und persistiert den Fortschritt.

Was ist ein Reins Turn?

Ein Reins Turn ist die kleinste Ausführungseinheit in reins, in der ein Versuch an einem Quest-Item als Generierung → Urteil → Aufzeichnung abschließt. Eine Schleife ist nichts als die Wiederholung von Turns, und der Fortschritt einer Quest ist nichts als die Akkumulation von Turns. Die Definition passt daher in eine Zeile.

Turn N = der N-te aufgezeichnete Attempt. Was nicht aufgezeichnet ist, ist kein Turn.

Ein Attempt ist „eine Aufzeichnung eines Versuchs". Hier liegt ein subtiler Punkt — ein Turn ist nicht „das LLM wurde einmal aufgerufen". Die Existenzbedingung eines Turns ist nicht der Aufruf, sondern die Aufzeichnung. Wurde das LLM aufgerufen, aber das Ergebnis nie in das Ratchet geschrieben, hat dieser Turn nie stattgefunden. Umgekehrt ist ein Ergebnis, das ein Mensch von Hand eingereicht hat, sobald es aufgezeichnet ist, ein Turn. Auch ohne LLM. Wer die Turns zählt, ist nicht das Modell, sondern das Ratchet.

Diese eine Definition ist die Wurzel aller Eigenschaften, die noch kommen — Treiberunabhängigkeit, Neustart-Resilienz, Auditierbarkeit. Lassen wir die Namen fürs Erste nur vorbeiziehen. Wir treffen jeden an seinem Platz wieder.

Ein Turn besteht aus genau vier Schritten

Ein Turn durchläuft der Reihe nach vier Schritte. Die Schritte tragen englische Namen, aber was sie tun, ist einfach — zusammensetzen (compose), generieren (generate), urteilen (judge), aufzeichnen (record).

Schritt	Was er tut	Eigenschaft
① compose	Liest die Aufzeichnung aller bisherigen Turns (das Log) und montiert den Prompt für das LLM	Reine Funktion
② generate	Ruft das LLM einmal auf, um das Ergebnis zu erzeugen	Der einzige probabilistische Schritt
③ judge	Das Gate urteilt über das Ergebnis (PASS / REVIEW / FAIL)	Deterministisch
④ record	Wendet das Urteil auf das Ratchet an und speichert auf die Festplatte	Der einzige irreversible Schritt

„Reine Funktion" heißt: Dieselbe Eingabe liefert immer dieselbe Ausgabe, ohne weitere Nebenwirkungen; „irreversibel" heißt: Einmal ausgeführt, lässt es sich nicht mehr rückgängig machen. Dann tritt der Kern der Tabelle hervor — von den vier Schritten ist nur ② probabilistisch, und nur ④ ist irreversibel. Die Generierung kann nicht urteilen, und das Urteil kann nicht generieren. Die Unsicherheit der KI ist in eine Zelle gesperrt, die unumkehrbare Entscheidung in eine andere.

Eine eigentümliche Designentscheidung ist noch festzuhalten. Diese vierstufige Kaskade ist nicht als zwei Sätze Go-Code implementiert. Sie ist in einem einzigen menschenlesbaren Dokument namens pkg/cli/turn.md (einem TANGEUL-Dokument) definiert, in die Binärdatei eingebettet (go:embed) und zur Laufzeit interpretiert. Die kanonische Quelle für „wie ein Turn läuft" ist nicht Code, sondern ein lesbares Dokument — der Grund für diese Wahl kehrt am Ende dieses Artikels zurück.

① compose — Kontext kommt nur aus dem Log

Das Log ist das auf der Festplatte geführte Hauptbuch, in dem jeder bisherige Turn verzeichnet ist. Und die Eingabe für die Montage des Prompts von Turn N ist genau eine Sache: dieses Log. Zustand, der sich irgendwo im Programmspeicher versteckt und verschwindet, wenn der Prozess stirbt — so etwas existiert nicht.

Der aus dem Log montierte Prompt hat drei Schichten.

Was zu tun ist — was für dieses Item produziert werden muss (die Schreibanweisung und der Verifikationskontext)
Manual — der globale System-Prompt, plus, wenn der vorige Turn ein FAIL war, das Coaching für die Regel, die ihn verursacht hat (das Manual pro Regel)
Feedback-Schwanz — die Fakten des vorigen FAIL. „Wo, was es sein sollte, was es tatsächlich war"

In der Sprache der sechs Elemente von oben: Das Manual ist der Richtungskontext, der Feedback-Schwanz das deterministische Feedback. Beide werden in jedem Turn mechanisch aus dem Log montiert.

Es gibt eine subtile, aber wichtige Regel. Was compose als Referenz nimmt, ist nicht der letzte Attempt, sondern der letzte Attempt, der bis zum Urteil geführt (judged) wurde. Selbst wenn dazwischen ein Generierungsfehler wie ein LLM-Serverausfall liegt, sieht der Wiederholungsversuch nicht die Infrastruktur-Fehlermeldung, sondern das faktenbasierte Feedback des vorigen FAIL. Betriebsstörungen kontaminieren den Kontext der Arbeit nicht.

② generate — Das LLM generiert nur

Der montierte Prompt geht in einem einzigen Aufruf an das LLM-Backend. Ob das Backend eine HTTP-API ist (ollama/xai/gemini) oder ein Kommandozeilenwerkzeug (claude/grok/codex/geminicli), spielt keine Rolle. So oder so ist seine Rolle fixiert: Generator. Das Framework exponiert keine API, über die einem LLM die PASS-Befugnis erteilt werden könnte. Es ist nicht so, dass das Framework „beschlossen hätte", die Urteilsbefugnis nicht zu erteilen — es gibt keinen Weg, sie zu erteilen. So wird Element 1 der sechs (maschinell beurteilte Fertigstellung) zu Struktur.

Selbst welches Backend verwendet wird, wird in jedem Turn aus dem Log neu berechnet. Ein Item, das am Standardmodell immer wieder scheitert, wird an ein stärkeres hochgereicht (Eskalation), und auch diese Entscheidung wird in jedem Turn aus dem Log abgelesen — „ist unter den Ursachenregeln der vergangenen FAILs eine ein Eskalationsziel?" Es gibt keinen irgendwo eingeschalteten Schalter, keine lokale Variable in der Schleife. Gleiches Programm, gleiches Log — gleiches gewähltes Backend. Die Eigenschaft, sich nach Kill und Neustart des Prozesses identisch zu verhalten — Neustart-Resilienz — gibt es gratis dazu.

③ judge — Nur das Gate urteilt

Was über das Ergebnis urteilt, ist das Gate. Ein Gate ist eine Menge von Verstoß-Erkennungsregeln. Jede Regel feuert, wenn sie das Problem findet, für das sie zuständig ist, und hinterlässt einen Fakt — wo (Where), was es sein sollte (Expected), was es tatsächlich war (Actual).

Die Aggregation ist deterministisch. Feuert auch nur eine Fail-Regel: FAIL. Andernfalls, wenn eine Review-Regel feuert: REVIEW (eine Grauzone, die ein Mensch prüft). Feuert nichts: PASS. Gleiche Einreichung, gleiche Regeln — immer dasselbe Urteil. Es gibt hier keinen Prüfer, dessen Antwort sich bei jeder Nachfrage ändert.

In komplexen Domains, in denen sich Regeln verflechten — wo ein Verstoß eine andere Prüfung bedeutungslos macht —, kann das Urteil auf einen Argumentationsgraphen (toulmin) gehoben und die Urteilslogik selbst in ein auditierbares Dokument (gate.md) verlagert werden. In welcher Form auch immer, eines ändert sich nicht: Der Richter ist eine Maschine.

④ record — Der einzige irreversible Schritt

Das Urteil auf das Ratchet anwenden, auf die Festplatte speichern und die abgeschlossenen Items exportieren. Dies ist der eine Punkt in einem Turn, der sich nicht rückgängig machen lässt.

PASS / REVIEW / SKIPPED / BLOCKED → verriegeln. Das Ratchet ist einbahnig; es dreht nicht zurück.
FAIL → der Versuchszähler (Tries) steigt um 1, und das Item bleibt TODO. Beim Erreichen der maximalen Versuche (Standard 3) wird es als DONE verriegelt. „Dieses Item funktioniert auf diese Weise nicht" ist auch eine Form von Abschluss — ein festhängendes Item darf nicht die ganze Schleife auf ewig in Geiselhaft nehmen.
Generierungsfehler → er wird im Log als Attempt aufgezeichnet (die Spur dessen, was geschah, bleibt erhalten), aber er verbraucht keinen Versuch. Dass ein LLM-Server ausfällt, ist nicht die Schuld des Items, sondern eine Betriebsstörung. Hält die Störung an, stoppt eine separate Sicherung die Schleife (Halt nach N aufeinanderfolgenden Generierungsfehlern — ein Circuit Breaker).

Erst mit diesem Schritt existiert das Log, das compose im nächsten Turn liest. record ist der Abschluss des Turns und der Erzeuger des nächsten Turns.

Ein Fehlschlag ist ein Fakt, keine Meinung

In welcher Gestalt ein FAIL zurückkommt — das ist der Schlüssel dafür, dass ein Turn konvergiert (mit jedem Wiederholungsversuch näher an die Lösung rückt). Nicht eine Meinung wie „die Qualität lässt etwas zu wünschen übrig", sondern dies:

FAIL. root cause = who-anchor-present
  Fact: where=who.anchors expected="source substring" actual="Sachbearbeiter Max Müller"

Das Lesen ist einfach. Welches Feld (where), was es sein sollte (expected — ein String, der tatsächlich in der Quelle vorkommt), was es tatsächlich war (actual). Ort + Erwartungswert + Istwert. Für das LLM ist das Feedback, in dem es niemanden zu umschmeicheln gibt — Zahlen und Orte sind keine Gefühle. Es ist dieser strukturierte Fakt, der ein schmeichelndes Modell nicht in die Debatte, sondern in die Konvergenz führt.

Ein Bonus obendrauf. Der FAIL-Text, der dem Modell zugeführt wird, ist exakt dasselbe Rendering wie der String, der auf dem Bildschirm erscheint, wenn ein Mensch den submit-Befehl ausführt (Feedback-Parität). Das Feedback, das der Mensch sieht, und das Feedback, das das Modell sieht, weichen nie voneinander ab. Das Mysterium „Was um alles in der Welt wurde der KI geschickt, dass sie es so korrigiert hat?" ist strukturell abwesend.

Drei Einstiegspunkte, ein Turn

Nennen wir denjenigen, der den Turn antreibt, einen Driver. reins hat drei: next, bei dem ein Mensch den Prompt direkt erhält; submit, bei dem ein Mensch das Ergebnis einreicht; und das unbeaufsichtigte automatische loop. Doch das sind nicht drei getrennte Implementierungen. Es sind drei Einstiegspunkte in dasselbe Turn-Dokument. Was manuell von automatisch trennt, ist genau eine Regel im Dokument.

Die praktische Eigenschaft, die das liefert: Wechselt man mitten in der Quest den Driver, bleibt der Prompt Byte für Byte identisch. Gestern die automatische Schleife laufen lassen, heute übernimmt ein Mensch mit next — bei gleichem Log-Zustand kommt derselbe Prompt heraus. Möglich ist das, weil der Kontext nur aus dem Log kommt (das sahen wir in Schritt ①), und es ist eine bewiesene Eigenschaft, keine Hoffnung — ein Driver-Swap-Golden-Test verifiziert die Byte-Identität, indem er die Ausgaben über die Driver hinweg vergleicht.

Einen Turn von Anfang bis Ende verfolgen

Die Theorie ist erledigt. Sehen wir uns einen echten Turn von Anfang bis Ende an. Es ist ein Item in einer Quest, die E-Mail-Adressen aus Dokumenten extrahiert, im zweiten Versuch, nachdem der vorige Turn mit „kein gültiges E-Mail-Format" ge-FAILt war.

[Turn-Eintrittsprüfung]  Ist das Item TODO? Sind Versuche übrig? → weiter
① compose      Letzten judged Attempt im Log finden → FAIL, Ursache = email-format
               Manual = globaler Prompt + Coaching der Regel email-format
               Prompt = was zu tun ist + "FAIL. Fact: where=email
                        expected='valid email format' actual='kim at example'"
② generate     LLM-Aufruf → {"email":"kim@example.com", ...}
③ judge        Regeldurchlauf: email-format besteht, source-lacks-email besteht, freemail besteht
               → keine Fail-Regel gefeuert → PASS
④ record       Ratchet verriegelt (irreversibel) → Attempt #2 aufgezeichnet → gespeichert → export

Das Modell, dem der Fakt des vorigen Fehlschlags gegeben wurde („kim at example ist kein gültiges E-Mail-Format"), hat genau diese Stelle korrigiert; das Gate hat das Bestehen bestätigt; das Ratchet hat verriegelt. Dieses Item ist nun für immer PASS. Der nächste Turn überspringt es, und die verbleibende Arbeit schrumpft nur. Wenn jedes Item einen abgeschlossenen Zustand erreicht (PASS, REVIEW oder maximale Versuche), endet die Schleife. Nicht „wenn die KI sich fertig fühlt", sondern wenn die verbleibenden Items null erreichen. Die Konvergenz wird durch Struktur garantiert.

Loop Engineering — Die Branche hat demselben Problem einen Namen gegeben

Im Juni 2026 bekam ein Wandel im Umgang mit Agenten einen Namen. Peter Steinberger schrieb: „You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents" (Man sollte Coding-Agenten nicht mehr prompten. Man sollte Schleifen entwerfen, die die Agenten prompten), und Anfang desselben Monats sagte Boris Cherny von Anthropic, der Claude Code gebaut hat, auf einer Veranstaltung: „I don’t prompt Claude anymore. I have loops running… My job is to write loops" (Ich prompte Claude nicht mehr. Bei mir laufen Schleifen. Mein Job ist es, Schleifen zu schreiben). Wenige Tage später gab Addy Osmani von Google der Strömung einen Namen: Loop Engineering — von der Person, die Agenten promptet, zur Person, die die Systeme entwirft, die Agenten prompten.

Dieser Diskurs zeichnet eine einzige Übergangserzählung. Prompt Engineering (die Worte wählen) → Context Engineering (wählen, welche Information gezeigt wird) → Harness Engineering (die Ausführungsumgebung bauen) → Loop Engineering (den Zyklus aus Beobachten, Handeln, Verifizieren und Wiederherstellen selbst entwerfen). Der Hebel ist Schicht für Schicht nach außen gewandert: von Worten zu Information, von Information zu Umgebung, von Umgebung zu Zyklus.

Osmanis Anatomie einer guten Schleife dürfte jedem, der bis hierher gelesen hat, vertraut vorkommen. Externalisiere den Zustand auf die Festplatte oder ein Board, nicht in die Konversation. Trenne den Agenten, der baut, von dem Agenten, der verifiziert. Lass die Beendigung von einem separaten Schiedsrichter bestätigen, nicht von der Selbsterklärung des Coding-Agenten. Legt man das neben den Turn, ist die Entsprechung scharf.

Empfehlung des Loop Engineering	Strukturierung im reins-Turn
Externalisiere den Zustand auf Festplatte oder Board (das Modell vergisst)	Das Log ist keine Gedächtnisstütze, sondern die einzige Eingabe des Turns — compose ist eine reine Funktion des Logs
Trenne den Bauenden vom Verifizierenden (Subagenten)	Der Verifizierer ist kein weiteres LLM, sondern ein deterministisches Gate — eine PASS-erteilende API existiert gar nicht
Definiere testbare Beendigungsbedingungen	Die Monotonie des Ratchets garantiert die Konvergenz als Invariante — Struktur, keine Bedingung
Unterscheide behebbare von fatalen Fehlern	In die record-Regeln eingebaut — ein FAIL verbraucht einen Versuch; Generierungsfehler gehören dem Circuit Breaker

Der Kern des Unterschieds ist die Distanz zwischen Empfehlung und Struktur. Die Loop-Engineering-Literatur selbst räumt die Hierarchie der Verifikation ein — LLM-as-judge, das Urteil einer KI anzuvertrauen, „can be gamed or can collude with the actor" (kann ausgetrickst werden oder mit dem Akteur kolludieren), also setze überall dort, wo eine deterministische Prüfung möglich ist, eine deterministische Prüfung ein. Doch das bleibt eine Best Practice — eine Empfehlung, die dem guten Willen des Designers überlassen ist. Wenn der Verifizierer-Subagent letztlich auch ein LLM ist, bleibt die Tür zur Kollusion offen. reins schließt diese Tür per Design. Nur das Gate urteilt, und das Framework exponiert keinen Weg, einem LLM ein PASS zu geben.

Und wo das Loop Engineering von der ganzen Schleife spricht, macht reins eine Umdrehung dieser Schleife zum Vertrag. Um über Chernys „mein Job ist es, Schleifen zu schreiben" einen Schritt hinauszugehen, muss zuerst definiert sein, was eine Schleife in einer Umdrehung tut — was probabilistisch ist, was deterministisch, was irreversibel. Der Name dieser Definition ist der Turn.

Warum diese Einheit

Zieht man den Turn so fest, gewinnt man drei Dinge. Die Namen, die vorhin vorbeigezogen sind, finden hier ihren Platz.

Auditierbarkeit — die Antwort auf „worin unterscheidet sich die automatische Schleife vom manuellen next?" ist nicht der Vergleich zweier Codebasen, sondern eine einzige Regel in einem Dokument. Man kann mit eigenen Augen bestätigen, dass genau ein Pfad im Dokument ein PASS verriegeln kann. Darum ist die kanonische Quelle des Turns ein lesbares Dokument, kein Code.
Neustart-Resilienz — jede Eingabe eines Turns leitet sich aus dem Log auf der Festplatte ab; selbst wenn der Prozess stirbt, reproduziert dasselbe Log denselben Turn.
Austauschbarkeit der Agenten — tausche die Agenten (LLMs, Driver) aus, und der Fortschritt akkumuliert trotzdem weiter und rollt nie zurück. „Agents are disposable; progress is cumulative."

Andersherum gesagt: Ein System mit verschwommenem Turn — in dem sich der Kontext im Sitzungsspeicher versteckt, das Modell die Fertigstellung selbst erklärt und Wiederholungsversuche sich auf die Konversationshistorie stützen — verliert alle drei.

Der Turn wirkt klein. Aber als kleinste Einheit, die Generierung (Wahrscheinlichkeit), Urteil (Determinismus) und Aufzeichnung (Irreversibilität) innerhalb eines Zyklus trennt und serialisiert, gilt: Wer den Turn versteht, versteht ganz reins.

Weiterführende Lektüre (extern)

Building Effective Agents — Anthropic — der Klassiker des Agenten-Schleifendesigns. Seine Unterscheidung von „Workflows (deterministische Orchestrierung) und Agenten (modellgetrieben)" resoniert mit der Trennung von Generierung und Urteil in diesem Artikel.
Agentic Loops: From ReAct to Loop Engineering — Data Science Dojo — ein Überblick über die Linie der Agenten-Schleifen, von ReAct bis zum Loop Engineering.
The Anthropic leader who built Claude Code says he ditched prompting — now he just writes loops — The New Stack — Branchenberichterstattung über Boris Chernys Wandel.

Quellen

Loop Engineering — Addy Osmani — 2026-06. Die Prägung des Begriffs und die Anatomie einer guten Schleife (Automatisierung, Worktrees, Skills, Subagenten, separate Schiedsrichter, Zustandsexternalisierung).
What Is Loop Engineering? A Complete Guide from Prompt to Harness Engineering — Tosea.ai — der vierstufige Übergang Prompt→Kontext→Harness→Loop, die Determinismus-zuerst-Hierarchie der Verifikation und das Kollusionsrisiko von LLM-as-judge.
Claude Code’s Creators Explain Agent Loops — The Neuron — Boris Cherny und Cat Wu im Detail über den Schleifenbetrieb: /loop und /goal, Zustandsexternalisierung auf Festplatte und Linear, Trennung von Bauenden und Verifizierenden.