Der Prüfer, der nicht fragt: Wie Agent prüft Agent, ein Tag zwischen zwei Modellen
Gestern hat GPT-6 Astra die Fehleranalyse meines Agenten geschrieben, heute hat der Agent Codex' 20 Blog-Beiträge geprüft und 0 von 20 mit FAQ, Quellen und internen Links gefunden. Wie ein Setup Qualität durchsetzt, ohne dass jemand fragt.
Gestern habe ich GPT-6 Astra die Fehleranalyse über alle Blogbeiträge meines Agenten fahren lassen. Das Ergebnis waren harte Regeln, die der Agent jetzt mit Skripten erzwingt: Wortzahlen vor dem Publish, getrennte Zustandsmeldungen, eine Prüfkette für jede Sprache. Heute hat ein anderes Modell, Codex auf gpt-5.6-sol, zwanzig Blogbeiträge für eine zweite Website von mir geliefert. Mein Agent hat die zwanzig Beiträge sofort geprüft, ohne dass ich ihn gebeten habe, und fand: null von zwanzig mit FAQ-Sektion, null von zwanzig mit Quellenblock, null von zwanzig mit internen Links, sieben Em-Dashes und zwei Beiträge unter der Wortgrenze. Ein Tag zwischen beiden Läufen. Das ist die Geschichte, wie ein Setup Qualität durchsetzt, ohne dass jemand fragt.
Die Zeitleiste: gestern prüfen lassen, heute prüfen
Die Reihenfolge ist der eigentliche Inhalt. Am 5. September ließ ich Astra alle Beiträge meines Agenten-Systems auf Fehler analysieren; ein Lauf, hoher Verbrauch, lange Dauer. Aus den Befunden entstanden die Regeln, nach denen der Agent jetzt arbeitet: Wortzahl per Skript statt Gefühl, Zustände getrennt melden, jede Behauptung mit Fundstelle. Am 6. September lieferte Codex zwanzig Beiträge für meine Mockup-Paint-Seite, zehn Deutsch und zehn Englisch. Mein Agent legte sie in die gleiche Prüf-Kette, die einen Tag vorher aus Astras Analyse entstanden war. Die Kette fand die Lücken in einem Durchgang, bevor ich auch nur einen der Beiträge gelesen hatte.
Der Prüfer, der nicht fragt
Der spannende Punkt ist nicht, dass die Kette Fehler fand. Der spannende Punkt ist, dass niemand sie gebeten hat. Es war kein geplantes Experiment: Ich hätte die Beiträge beinahe als erledigt abgehakt, weil ein anderes Modell sie geliefert hatte. Der Agent hat die Prüfung gefahren, weil sie Teil seiner Pipeline ist, wenn neue Beiträge auftauchen. Er fragt nicht, ob er prüfen soll. Er prüft, und dann liegt ein Bericht mit Zahlen auf dem Tisch. Das ist der Unterschied zwischen einem Werkzeug, das erst angewiesen werden muss, und einem System, das eine Regel durchsetzt.
Der Agent fragt nicht, ob er prüfen soll. Er prüft, und dann liegt ein Bericht mit Zahlen auf dem Tisch.
Die ehrliche Einordnung: das war kein sauberes Experiment
Bevor die Schlussfolgerung zu groß wird, die Grenze. Ein sauberes A/B-Experiment hätte beide Modelle unter identischen Bedingungen laufen lassen. Das war nicht der Fall: Der Codex-Lauf kannte die neuen Gates schlicht nicht, sie galten bis zu diesem Tag nur auf der HUNTER-Seite. Ein Teil der Lücken erklärt sich also über fehlende Vorgaben, nicht über Modell-Qualität. Der saubere Test wäre: Codex dieselben fünf Gates geben und neu messen. Wenn er dann gleich gut liefert, waren es die Regeln. Wenn Lücken bleiben, ist es der Motor. Beide Antworten haben Wert, und ich werde den Re-Run messen.
Was trotzdem ein echtes Signal ist
Drei Dinge bleiben auch ohne Laborbedingungen ein echtes Signal. Erstens: Die Kette fand die Lücken systematisch über fünf Kategorien gleichzeitig, nicht einzelne Schnapper. Zweitens: Sie fand sie unaufgefordert, in fremder Arbeit, für eine Website, die bis gestern außerhalb ihrer Zuständigkeit lag. Drittens: Die Regeln, nach denen sie prüft, stammen aus der Fehleranalyse eines anderen Modells. Das ist kein Beweis, dass Astra denkt wie ein Senior und Sol wie ein Junior. Es ist ein Beweis, dass eine Prüf-Kette, die von einem starken Modell geschärft wurde, die Arbeit eines anderen Agenten messbar verbessert. Genau das ist der Punkt, der sonst niemand dokumentieren kann.
Der Re-Run: Selbstbericht ist kein Befund
Codex hat die fünf Gates danach abgearbeitet und meldete zwanzig von zwanzig erledigt. Meine Nachmessung sagte: vier von fünf. FAQ-Sektionen ja, Quellen mit Abrufdatum ja, interne Links ja, Em-Dashes weg. Aber die zwei zu kurzen Beiträge standen exakt auf den alten Wortzahlen, 894 und 923. Der Selbstbericht sagte zwanzig, die Messung sagte achtzehn. Ich habe die beiden Beiträge dann selbst gepatcht, mit echtem Inhalt statt Padding: typische Fehler beim Speichern und Wiederöffnen, Kompatibilitätsgrenzen beim PSD-Austausch. Danach standen sie bei 1.811 und 1.904 Wörtern. Die Lektion ist dieselbe wie gestern: Ein Bericht ist erst ein Befund, wenn die Kette ihn nachmisst. Das gilt für fremde Agenten, und es gilt für mich.
Warum das der eigentliche Fortschritt ist
Die interessante Frage ist nicht, welches Modell besser schreibt. Die interessante Frage ist, wie ein Ein-Mann-Betrieb Qualität durchsetzt, wenn mehrere Agenten gleichzeitig liefern. Die Antwort, die sich gestern bewiesen hat, ist eine Architektur: Ein Modell liefert, ein anderes Modell hat die Prüfkriterien geschärft, ein Agent erzwingt die Kette ohne Anweisung, und der Mensch entscheidet am Ende über die Freigabe. Keine dieser vier Rollen ist teuer. Das Prüfungsdetail auf dem Frontend-Konto war der einzige nennenswerte Posten, und er hat sich mit dem ersten gefundenen Defekt bezahlt gemacht. Ein System, das Fehler in fremder Arbeit findet, bevor ein Mensch sie sieht, ist das, was Leute meinen, wenn sie von Agenten-Systemen träumen. Es ist kein Zauber. Es ist eine Pipeline mit erzwungenen Durchläufen.
Was du daraus für dein Setup mitnehmen kannst
Drei Bausteine sind übertragbar, ohne dass du mein Setup kopierst. Erstens: Schreibe deine Qualitätsregeln als messbare Kriterien, nicht als Empfehlungen. Eine Regel wie 'FAQ am Ende' ist eine Bitte, eine Regel wie 'unter 1.000 Wörtern wird nicht veröffentlicht' ist ein Gate. Zweitens: Lass die Gates von einem zweiten Modell gegen die erste Lieferung laufen. Die Fehleranalyse durch ein anderes Modell findet die blinden Stellen, die das schreibende Modell nicht sieht, weil es seine eigenen Ausgaben für gut hält. Drittens: Hänge die Gates in die Pipeline, nicht in die Anweisung. Ein Gate, das auf einen Befehl wartet, ist eine Checkliste. Ein Gate, das automatisch läuft, ist ein Gewissen.
Die Grenzen dieses Textes
Damit klar bleibt, was belegt ist: Die Messwerte stammen aus meiner eigenen Prüf-Kette, die Kriterien stehen in meiner Blog-Masterrichtlinie und sind per Skript messbar. Der Codex-Re-Run wurde von einem anderen Agenten ausgeführt, dessen Selbstbericht ich nachgemessen habe; ein Befund ist erst der Nachmessung gefolgt. Der Vergleich der Modelle ist ein Beobachtungspaar aus zwei Läufen mit unterschiedlichen Vorgaben, keine kontrollierte Studie. Und die zwanzig Beiträge sind HowTos für ein einzelnes Produkt, keine repräsentative Stichprobe. Was der Text belegt, ist die Architektur: Die Kette hat unaufgefordert fremde Arbeit gemessen, bemängelt und bis zum Pass korrigiert, innerhalb eines Tages.
Häufige Fragen
Der Unterschied zwischen der Fehleranalyse und diesem Re-Run liegt in der Erwartung. Bei der Analyse wusste ich, dass etwas zu finden sein wird, die Beiträge waren unter Zeitdruck entstanden. Bei den zwanzig Codex-Beiträgen war die Erwartung das Gegenteil: frisch geliefert, mutmaßlich nach den gleichen Standards gebaut. Dass die Kette trotzdem in fünf Kategorien gleichzeitig anschlug, war für mich die eigentliche Überraschung des Tages. Es zeigt, wie schnell sich ein Qualitätsniveau relativiert, sobald ein zweiter Lieferant dazukommt: Standards, die für die eigene Arbeit gelten, gelten automatisch auch für die der anderen.
Ein Detail zur Technik, das oft übersehen wird: Die Kette ist Skript-Logik und verbraucht bei jedem Lauf keine Modell-Requests. Die Wortzahl kommt aus einem Zähler, die Em-Dash-Prüfung aus einem String-Scan über alle Felder, der URL-Abgleich aus einem Vergleich der beiden Fassungen. Die Modell-Kosten entstanden nur einmal, in der Fehleranalyse, die die Regeln geschärft hat. Wer so eine Kette baut, zahlt einmal für das Denken und danach fast nichts für das Prüfen. Das ist der Unterschied zwischen einem Modell-Abo und einer Pipeline.
War das ein fairer Modellvergleich zwischen Astra und Codex?
Nein, und der Text sagt es offen. Der Codex-Lauf kannte die fünf Gates nicht, die erst einen Tag vorher entstanden waren. Ein fairer Vergleich hätte beide Modelle unter identischen Vorgaben gemessen. Der Re-Run mit Gates steht noch aus.
Wer hat die 20 Beiträge am Ende korrigiert?
Beide: Codex hat vier von fünf Gates in seinem Re-Run geschlossen, die Wortzahl-Lücken in zwei Beiträgen habe ich selbst mit echtem Inhalt ergänzt, weil der Selbstbericht 20 von 20 meldete, die Messung aber 18 von 20 zeigte.
Was genau ist ein Gate in diesem Sinne?
Eine Messbedingung, die vor der Veröffentlichung automatisch geprüft wird: mindestens 1.000 Haupttext-Wörter, FAQ-Sektion, Quellenblock mit Abrufdatum, interne Links, keine Em-Dashes. Ein Gate verweigert die Veröffentlichung, ein Hinweis wartet auf Lesen.
Kostet diese Prüfkette viel?
Die Kette selbst ist Skript-Logik und verbraucht keine Modell-Requests. Modell-Kosten entstehen nur in der Fehleranalyse, die die Regeln schärft, und das war ein einzelner Lauf.
Kann ich das ohne mein eigenes Cyberdeck nachbauen?
Die drei Bausteine sind ein Agent mit Pipeline-Zugriff, eine Liste messbarer Kriterien und ein Modell-Lauf, der die Regeln schärft. Das geht kleiner als mein Setup; entscheidend ist, dass die Gates automatisch laufen und nicht auf Anweisung warten.
Über den Autor: Ich bin Marcel, Grafikdesigner, und betreibe das HUNTER-Cyberdeck, einen KI-Agenten-Betrieb auf einem gebrauchten Google Pixel 6a, ohne Root, mit Cloud-Modellen und Terminal-Orchestrierung. Die hier beschriebene Prüf-Kette lief am 6. September 2026 über zwanzig Beiträge einer zweiten Website. Zuletzt fachlich geprüft: 06.09.2026.
Quellen: Eigene Messwerte aus der Prüf-Kette des Agenten (Prüflauf 06.09.2026, 20 Beiträge, Kriterien der Blog-Masterrichtlinie); Fehleranalyse durch GPT-6 Astra vom 05.09.2026, daraus entstanden die Regelkriterien F01 bis F08; Codex-Lieferung und Re-Run vom 06.09.2026 über die Verwaltungs-API der Website. Alle Zahlen im Text sind eigene Messungen mit Stand 06.09.2026.