Subagent-First (Subagent-Prioritär)

Subagent-Prioritär · Hauptagent bleibt draußen

Die Aufmerksamkeit des Hauptagenten gehört dem Nutzer, nicht der Aufgabe. Jede Aufgabe, die voraussichtlich viele Runden benötigt, wird an einen Subagenten im Hintergrund delegiert; der Hauptagent ist nur für Zerlegung, Delegation, Abnahme und Abschluss zuständig und bleibt jederzeit reaktionsfähig.

Viele Agenten fühlen sich umständlich an, nicht weil das Modell nicht gut genug ist, sondern weil der Hauptagent mit schweren Aufgaben blockiert ist: Der Nutzer schickt einen Satz, der Hauptagent arbeitet sich durch zwanzig Tool-Aufrufe, kann weder antworten noch die Richtung ändern, der Nutzer wartet einfach. Wenn der Hauptagent endlich aufschaut, haben sich die Anforderungen möglicherweise geändert.

Diese Fähigkeit bietet eine Arbeitsdisziplin – sie macht „Wann delegieren, wie delegieren, wie abnehmen“ zu überprüfbaren Regeln, nicht zum Bauchgefühl. Die Disziplin ist plattformunabhängig: Sie gilt für jeden KI-Agenten mit Subagenten/ Hintergrundaufgaben (Claude Code, Codex, Cursor, WorkBuddy, Hermes und andere vergleichbare Tools). Der Unterschied liegt nur in den Tool-Namen – eine Zuordnungstabelle findest du im Abschnitt „Tool-Name-Zuordnungstabelle“ dieses Dokuments.

Abweichungen in der Praxis bei bestimmten Plattformen: Die Feldnamen, Parallelitätsgrenzen, Hintergrundsemantik und Kostenstruktur von Hermes sind in references/hermes-runtime-reality.md zusammengestellt (Beispielimplementierung, andere Plattformen können ignorieren). Der Haupttext behandelt nur die Disziplin, nicht diese Seite.

---

Auslösebedingungen

Wenn einer der folgenden Fälle eintritt, sollte nach dieser Fähigkeit verfahren werden (anstatt es selbst zu erledigen):

1. Die Aufgabe erfordert voraussichtlich mehr als 2–3 Tool-Aufrufe: z. B. „8 Dateien lesen und zusammenfassen“, „eine Suche durchführen und dann aufbereiten“.
2. Mehrere voneinander unabhängige Einheiten müssen gleichzeitig verarbeitet werden: Mehrere Dateien, Verzeichnisse, URLs, Datensätze, Lösungsvorschläge.
3. Lange Recherche / lange Suche: Wiederholtes Abrufen, Crawlen, Vergleichen, das Minuten dauert.
4. Batch-Verarbeitung: Gleicher Vorgang für einen ganzen Stapel von Eingaben (Bereinigen, Konvertieren, zeilenweises Prüfen, zeilenweises Generieren).
5. Der Nutzer fordert explizit Parallelverarbeitung oder „mehrere Dinge gleichzeitig tun“.
6. Der Hauptagent befindet sich mitten in einem Dialog mit dem Nutzer: Der Nutzer kann jederzeit nachfragen, Anforderungen ändern oder neue Aufgaben einwerfen.
7. Teilaufgaben sind voneinander unabhängig und können gleichzeitig gestartet werden: Typisch „Drei Dokumente separat Korrektur lesen und dann Schlussfolgerungen zusammenführen“.
8. Während schwere Aufgaben im Hintergrund laufen, möchte der Nutzer weiterhin über etwas anderes chatten (dies ist der Hauptnutzen dieser Fähigkeit).

Umgekehrte Auslösebedingung: Wenn eine Sache mit einem einzigen Tool-Aufruf erledigt werden kann und der Nutzer danach nicht mehr mit dir spricht – dann mach es selbst. Einen Subagenten zu erzwingen, wäre nur langsamer. Die Entscheidungskriterien findest du im nächsten Abschnitt, dem Entscheidungsbaum.

---

Kernprinzipien

1. Der Hauptagent macht keine schweren Arbeiten. Der Hauptagent macht nur vier Dinge: Zerlegen → Delegieren → Abschließen/ Zusammenfassen → Mit Nutzer sprechen. Er muss jederzeit „antwortbereit“ bleiben.
2. Schwere Arbeit wird zwingend an Subagenten delegiert. Wenn die obigen Auslösebedingungen erfüllt sind, delegiere. „Ich denke, ich bin schnell, ich mach das mal eben selbst“ ist nicht erlaubt. Entscheidend sind die Aufgabenmerkmale, nicht das Selbstvertrauen des Hauptagenten.
3. Selbstmeldung ist nicht gleich Tatsache. Dass ein Subagent „erledigt“ sagt, ist nur seine Behauptung; ohne Überprüfung gilt die Ausgabe als nicht erledigt (siehe „Abnahmeliste“).
4. Der Kontext muss in sich geschlossen sein. Der Subagent sieht nicht den bisherigen Dialog zwischen dir und dem Nutzer. Alles, was du im Kopf hast, bekommt er nicht mit. Wenn der Arbeitsauftrag nicht vollständig ist, läuft er garantiert in die falsche Richtung – nicht, weil er dumm ist, sondern weil du es nicht angegeben hast.
5. Parallelität hat Grenzen. Nur unabhängige Aufgaben werden parallelisiert; Aufgaben mit Abhängigkeiten müssen seriell ausgeführt werden, oder die Ausgabe des vorgelagerten Schrittes wird dem nachgelagerten Schritt als Eingabe gegeben.
6. Aufgaben, die eine Entscheidung des Nutzers erfordern, werden nicht delegiert. Alles, was eine Nutzerbestätigung, irreversible Konsequenzen oder eine sofortige Qualitätskontrolle erfordert, bleibt beim Hauptagenten.
7. Langlebige, sitzungsübergreifende Aufgaben brauchen einen anderen Mechanismus. Aufgaben, die länger als die aktuelle Sitzung leben müssen (kontinuierliche Überwachung, zeitgesteuerte Auslösung, dauerhafte Prozesse), werden mit dem Timing/ Dauerhaft-Mechanismus deiner Plattform erledigt (geplante Tasks, Cron-Jobs, Hintergrundprozesse), nicht mit Subagenten – der Lebenszyklus eines Subagenten ist an eine einzelne Delegation gebunden.
8. Fehler führen zu einer Degradierung, nicht zur Erfindung. Wenn ein Subagent fehlschlägt, ein Timeout hat oder die Ausgabe nicht den Anforderungen entspricht: Degradiere zu Eigenarbeit oder delegiere auf einem anderen Weg. Es ist absolut nicht erlaubt, „ein nicht erhaltenes Ergebnis“ als „erhalten“ darzustellen.

Diese Prinzipien entsprechen dem bekannten Fork-Join / Fan-Out-Fan-In Paradigma: Aufgaben werden an mehrere Ausführungseinheiten verteilt und die Ergebnisse wieder zusammengeführt (Javas ForkJoinPool und das von Dean und Ghemawat auf der OSDI 2004 vorgestellte MapReduce sind konkrete Implementierungen dieser Idee). Diese Fähigkeit erfindet kein neues Konzept, sondern setzt es als ausführbare Arbeitsdisziplin für Agenten um.

---

Entscheidungsbaum: Was ist schwere Arbeit, was mache ich selbst

Beantworte die folgenden Fragen der Reihe nach. Der erste Zweig, der mit „Ja“ beantwortet wird, ist das Ergebnis.

Frage 1: Kann diese Sache mit einem Tool-Aufruf erledigt werden?

Kriterium	Beurteilung
Anzahl Tool-Aufrufe	Du kannst sie selbst zählen, und sie ist ≤ 1 Runde
Müssen mehrere Dateien gelesen werden?	Nein (0–1)
Gibt es eine Schleife?	Nein (kein „für jedes…“)
Voraussichtliche Dauer	Sekunden

Alle vier Kriterien erfüllt → Selber machen. Auch nur eines nicht erfüllt → Weiter zu Frage 2.

Frage 2: Benötigt diese Sache eine Entscheidung des Nutzers?

• Der Nutzer muss aus mehreren Optionen wählen → Selber machen (oder nur Informationen sammeln und die Optionen präsentieren).
• Es geht um irreversible Operationen (Daten löschen, veröffentlichen, bezahlen, Nachrichten an Dritte senden) und eine sofortige Kontrolle ist nötig → Selber machen.
• Es geht nur darum, dass „der Nutzer Bescheid weiß“, ohne dass er während des Prozesses eine Entscheidung treffen muss → Kann delegiert werden, aber bei der Zusammenfassung muss klar kommuniziert werden.

Frage 3: Muss diese Sache länger als die aktuelle Sitzung leben?

• Ja (zeitgesteuerte Auslösung, kontinuierliche Überwachung, dauerhafter Dienst) → Nutze den Timing/ Dauerhaft-Mechanismus deiner Plattform (geplante Tasks, Cron-Jobs, Hintergrundprozesse), nicht den Subagenten.
• Nein, es reicht, wenn es innerhalb dieser Sitzung erledigt wird → Weiter zu Frage 4.

Frage 4: Kann es in voneinander unabhängige Teile zerlegt werden?

• Ja → Parallel mehrere Subagenten delegieren, jeder kümmert sich um seine eigene Datei / sein eigenes Verzeichnis / seine eigene URL / seinen eigenen Datensatz, der Hauptagent führt am Ende zusammen.
• Nein, aber es gibt eine klare Reihenfolge → Seriell delegieren oder einen einzigen Subagenten die gesamte Kette durchlaufen lassen (das ist immer noch besser, als wenn du selbst ranmusst).
• Lässt sich nicht zerlegen und ist auch nicht lang → Gehe zurück zu Frage 1 und überprüfe es noch einmal; wahrscheinlich machst du es selbst.

Kurzübersicht Mengengerüst

Art der Aufgabe	Typische Dauer	Vorgehen
Einen Wert nachschlagen, einen Abschnitt einer Datei lesen	Sekunden	Selber machen
Eine Textstelle ändern, einen Befehl ausführen	Sekunden	Selber machen
3 Dateien lesen und zusammenfassen	1–2 Minuten	Kann man machen oder delegieren; delegieren, wenn der Nutzer wartet
8 Dateien lesen, einzeln zusammenfassen	Mehrere Minuten	Delegieren
Mehrere Quellen durchsuchen + quervergleichen	Minuten bis über zehn Minuten	Delegieren (in Blöcke parallelisieren)
Batch-Verarbeitung von N Eingaben (N ≥ 5)	Steigt mit N	Delegieren (in Scheiben parallelisieren)
Nutzer muss aus Optionen wählen	Unbestimmt	Selber machen (sammeln + Optionen präsentieren)
Täglich einmal zu fester Zeit ausführen	Sitzungsübergreifend	Geplanter Task (kein Subagent)

---

Fünf-Schritte-Prozess

Schritt 1: Zerlegen

Schneide die Arbeit in klar abgegrenzte Einheiten. Jede Einheit muss drei Fragen unabhängig beantworten können:

• Was ist die Eingabe: Konkrete Dateipfade, Verzeichnisse, URL-Listen, Datensatznamen, Parameter.
• Was ist die Ausgabe: Konkreter Dateiname, Format, Pfad.
• Wann ist es fertig: Überprüfbare Kriterien, nicht „wenn es gut aussieht“.

Beim Zerlegen zwei Regeln beachten:

• Dateischreibkonflikte vermeiden: Zwei Subagenten dürfen niemals dieselbe Datei schreiben. Entweder schreibt jeder seine eigene Datei, und der Hauptagent führt sie am Ende zusammen, oder es wird seriell gearbeitet.
• Abhängigkeiten explizit machen: Wenn die Ausgabe von A als Eingabe für B dient, darf nicht parallel delegiert werden – entweder seriell oder ein Subagent macht A+B zusammen.

Fertig-Kriterien (Punkt für Punkt abhaken)

• Jede Einheit hat eine klare Eingabe (mit konkreten Pfaden / Listen)
• Jede Einheit hat eine klare Ausgabe (Dateiname + Format + Speicherort)
• Jede Einheit hat überprüfbare Fertig-Kriterien
• Keine zwei Einheiten schreiben in dieselbe Datei
• Alle Abhängigkeiten sind markiert (welche müssen seriell sein)

Schritt 2: Delegieren

Verwende das Subagenten-/ Hintergrundaufgaben-Tool deiner Plattform, um jede Einheit zu delegieren (bei Hermes ist es delegate_task, bei anderen Plattformen gemäß der „Tool-Name-Zuordnungstabelle“). Der Arbeitsauftrag muss die „Vier Elemente“ enthalten (siehe nächster Abschnitt). Wichtig:

• Ein Subagent bekommt eine einzige klar abgegrenzte Aufgabe. Stecke nicht drei zusammenhanglose Dinge in einen Auftrag.
• Gib im Auftrag den vollständigen Hintergrund an – der Subagent sieht nicht den Dialog zwischen dir und dem Nutzer.
• Sage ihm genau, wo die Ausgabe landen soll und was er zurückmelden soll (Dateipfad? Zeilenanzahl? Befehlsausgabe?).
• Fordere ihn explizit auf, nur Dinge zu melden, die überprüfbar sind: Welche Befehle wurden ausgeführt, was war die Ausgabe; wenn etwas nicht geklappt hat, soll er es direkt sagen.
• Wenn die Plattform strukturierte Rückmeldungen / Ausgabevalidierung unterstützt (z. B. Überprüfung der finalen Antwort des Subagenten gegen ein JSON-Schema) – wenn möglich, gib eine Struktur vor, keinen Freitext.

Fertig-Kriterien

• Jeder Auftrag enthält alle vier Elemente (Ziel / Hintergrund / Ausgabestruktur / Abnahmemethode)
• Jeder Auftrag gibt den Ausgabepfad an
• Jeder Auftrag fordert überprüfbare Beweise an (Befehl + tatsächliche Ausgabe)
• Der Auftrag enthält keine vagen Verweise wie „du weißt schon“ oder „wie vorher“

Schritt 3: Parallele Ausführung

• Parallel delegieren, was parallel kann: Einheiten ohne gegenseitige Abhängigkeiten werden auf einmal rausgeschickt, nicht nacheinander in die Warteschlange gestellt.
• Seriell, wenn Abhängigkeiten bestehen: Warte, bis die vorgelagerte Einheit abgenommen ist, und gib dann ihre Ausgabe als Kontext für die nachgelagerte Einheit.
• Parallelitätsgrenze einhalten: Zu viele gleichzeitig laufende Aufgaben konkurrieren um Ressourcen und erhöhen deinen Koordinationsaufwand. Drei bis fünf gleichzeitig ist ein guter Bereich; bei mehr überlege, sie in Gruppen aufzuteilen (die Folgen einer Überschreitung des Limits variieren je nach Plattform; siehe „Tool-Name-Zuordnungstabelle“ und die plattformspezifische Realität).
• Sofort nach dem Delegieren zum Nutzer zurückkehren: Stehe nicht da und warte auf die Subagenten. Das ist der Zweck dieser Disziplin – während der Nutzer auf dich wartet, solltest du ansprechbar sein.
• Nicht pollen, nicht warten: Der Delegierungsaufruf sollte sofort zurückkehren; die Ergebnisse werden von der Plattform zurückgeliefert; der Hauptagent muss während der Wartezeit in der Lage sein, neue Nachrichten des Nutzers anzunehmen. Wenn deine Plattform standardmäßig blockiert, führe den Delegierungsaufruf im Hintergrund / asynchronen Modus aus.
• Dem Nutzer eine Kontrollmöglichkeit geben: Wenn die Plattform es unterstützt, laufende Subagenten einzusehen, einem Subagenten eine Korrektur zu geben, vorzeitig zu beenden und Teilergebnisse zu behalten, dann nutze es; wenn nicht, falle zurück auf „in der nächsten Auftragsrunde die Korrektur mitgeben“.

Fertig-Kriterien

• Unabhängige Einheiten wurden gleichzeitig delegiert (nicht eine nach der anderen in die Warteschlange)
• Abhängige Einheiten wurden seriell in der richtigen Reihenfolge delegiert, und die nachgelagerten haben die Ausgabe der vorgelagerten erhalten
• Die Parallelität ist in einem kontrollierbaren Rahmen (nicht ein Dutzend auf einmal gestartet)
• Der Hauptagent wartet nach dem Delegieren nicht blockierend und kann immer noch auf den Nutzer reagieren

Schritt 4: Abnahme

Dieser Schritt wird am leichtesten übersprungen und darf am wenigsten übersprungen werden. Das „Erledigt“ eines Subagenten ist eine zu überprüfende Behauptung, keine Schlussfolgerung.

Überprüfe in der richtigen Reihenfolge (siehe „Abnahmeliste“):

1. Existiert die Ausgabe? Ist die Datei wirklich da? Stimmt der Pfad? Lies den tatsächlichen Inhalt.
2. Entspricht die Ausgabe den Spezifikationen? Stimmen Format, Felder, Zeilenanzahl, Umfang mit den Anforderungen des Auftrags überein?
3. Gibt es Beweise für die Schlussfolgerung? Haben die behaupteten Schlüsselzahlen / Schlussfolgerungen eine entsprechende Befehlsausgabe oder Quelle?
4. Stichprobe aus der Quelle: Ziehe 1–2 Stellen willkürlich heraus und überprüfe sie an der Primärquelle.

Wenn auch nur einer dieser Punkte nicht erfüllt ist → Gehe zur Fehlerbehandlung in Schritt 5.

Fertig-Kriterien

• Die Ausgabe jedes Subagenten wurde mit den Lese-/ Ausführungstools der Plattform tatsächlich zurückgelesen (bei Hermes sind es read_file / terminal)
• Format und Felder entsprechen den Auftragsanforderungen
• Schlüssel Schlussfolgerungen haben nachvollziehbare Beweise
• Mindestens eine Stelle wurde an der Primärquelle überprüft und stimmt mit der Aussage des Subagenten überein
• Fehlgeschlagene / nicht konforme Ausgaben wurden klar markiert und nicht in das Endergebnis eingemischt

Schritt 5: Abschluss

Bei der Zusammenfassung für den Nutzer müssen drei Dinge beachtet werden:

• Quelle angeben: Welche Teile wurden von Subagenten erledigt, welche von dir selbst. Der Nutzer hat ein Recht, das zu wissen.
• Status angeben: Welche Teile wurden überprüft, welche nicht, welche sind fehlgeschlagen. Verwende keine vagen Formulierungen wie „ungefähr“ oder „sollte passen“.
• Nächsten Schritt angeben: Wo der Nutzer eine Entscheidung treffen muss, muss das klar dargestellt werden.

Fehlerbehandlung (in der Reihenfolge der Priorität):

1. Degradieren und selbst machen – die Arbeit ist eigentlich nicht groß, also mach es selbst.
2. Auf anderem Weg erneut delegieren – schreibe den Grund des Fehlschlags in den neuen Auftrag und versuche es mit einer anderen Methode noch einmal.
3. Aufteilen und erneut delegieren – der Auftrag war zu groß und ist dadurch in die falsche Richtung gelaufen; teile ihn in kleinere Stücke und delegiere erneut.
4. Wahrheitsgemäß berichten – wenn es nicht funktioniert, dann funktioniert es nicht; erkläre klar die Hürden und die bereits ausgeschlossenen Wege. Es ist nicht erlaubt, Ergebnisse zu erfinden.

Fertig-Kriterien

• In der Zusammenfassung ist die Quelle jedes Teils angegeben (Subagent / Hauptagent)
• In der Zusammenfassung ist der Überprüfungsstatus jedes Teils angegeben
• Fehlgeschlagene Arbeiten wurden behandelt (selbst gemacht / erneut delegiert / wahrheitsgemäß berichtet) und sind nicht unsichtbar
• Punkte, bei denen der Nutzer entscheiden muss, sind separat aufgeführt
• Es gibt keinen Satz, der als Tatsache dargestellt wird, ohne bestätigt zu sein

---

Die Vier Elemente des Delegierungsauftrags

Jeder Auftrag muss diese vier Dinge enthalten. Fehlt auch nur eines, steigt die Wahrscheinlichkeit von Problemen signifikant.

1. Ziel (goal) – Was ist zu tun

Beschreibe das Ziel in einem Satz, mit einem Verb beginnend, ergebnisorientiert.

• Gut: Führe 3 CSV-Dateien zu einer deduplizierten combined.csv zusammen, behalte die ursprüngliche Spaltenreihenfolge bei
• Schlecht: Bearbeite diese Dateien mal

2. Hintergrund (context) – Warum wird es gemacht, welche Grundlagen gibt es (muss in sich geschlossen sein)

Dies ist das Element, das am leichtesten schiefgeht. Der Grund ist einfach:

Der Subagent sieht nicht den bisherigen Dialog zwischen dir und dem Nutzer. Er weiß nur, was du in den Auftrag geschrieben hast. Alles, was du im Kopf hast – die Vorlieben des Nutzers, die bisherigen Fallstricke, warum eine bestimmte Lösung nicht in Frage kommt, die Dimensionen der Daten – er bekommt kein einziges Wort davon mit.

Daher müssen im Kontext explizit angegeben werden:

• Aufgabenkontext: Wozu dient diese Arbeit, worauf legt der Nutzer Wert.
• Harte Einschränkungen: Zwingend einzuhaltende Dimensionen, Formate, Namenskonventionen, Verbote.
• Eingabeliste: Konkrete Dateipfade / Verzeichnisse / URLs / Datensätze. Nicht „diese Dateien“ schreiben.
• Bekannte Fallstricke: Was wurde schon erfolglos versucht, wo gibt es Fallen, was wird leicht missverstanden.
• Umgebungsinformationen: Arbeitsverzeichnis, verfügbare Tools, ob Abhängigkeiten installiert sind.

Selbsttest: Könnte ein Kollege, der überhaupt keine Vorkenntnisse hat, mit diesem Auftrag arbeiten? Wenn ja, ist er in sich geschlossen.

3. Ausgabestruktur (output schema) – Wie sieht die Ausgabe aus

Gib die Struktur der Ausgabe vor, damit du sie nicht noch einmal aufbereiten musst.

• Dateien: Pfad + Dateiname + Format (markdown / json / csv) + erforderliche Felder oder Abschnitte.
• Berichte: Gib die geforderte Struktur vor (Schlussfolgerung / Beweis / Quelle / ungelöste Punkte), nicht einen Aufsatz.
• Maschinenlesbar bevorzugen: Wenn möglich, json statt Freitext – das spart dir die erneute Analyse.
• Wenn die Plattform Ausgabevalidierung unterstützt (Überprüfung der Subagentenantwort gegen ein Schema), aktiviere sie; wenn nicht, wiederhole die Struktur im Fließtext des Auftrags und fordere die Antwort in dieser Struktur.

4. Abnahmemethode – Wie wird der Erfolg nachgewiesen

Sage ihm vorab, wie du überprüfen wirst, dann wird er danach handeln; stellst du erst später fest, dass es keine Beweise gibt, musst du nacharbeiten.

• Fordere die tatsächlich ausgeführten Befehle und deren Ausgabe (nicht „ich habe es überprüft“).
• Fordere, dass der Ausgabepfad direkt zurückgelesen werden kann.
• Fordere die explizite Auflistung von unerledigten / unklaren Teilen – ein freiwilliges Geständnis ist besser, als dass du es hinterher aufdeckst.

Kurzübersicht Vier Elemente

Element	Ein Satz	Häufiger Fehler
Ziel	Was ist zu tun, ergebnisorientiert	Zu vage: „Ordne die Daten“
Hintergrund	Kontext + Einschränkungen + Eingabeliste + bekannte Fallstricke	Nur das Ziel, ohne Kontext; der Subagent interpretiert frei
Ausgabestruktur	Ausgabepfad, Format, Felder	Kein Pfad angegeben, die Ausgabe ist verstreut und nicht auffindbar
Abnahmemethode	Welcher Befehl / welches Kriterium entscheidet	Keine Kriterien; Durchwinken mit „sieht gut aus“

---

Abnahmeliste

Gehe bei jedem Subagenten die folgende Liste Punkt für Punkt durch. Wenn auch nur einer mit „Nein“ beantwortet wird, gilt die Arbeit nicht als erledigt.

A. Existenz

• Die Ausgabedatei existiert tatsächlich im im Auftrag angegebenen Pfad (mit den Lese-/ Ausführungstools der Plattform überprüft, nicht nur den Dateinamen angesehen)
• Die Datei ist nicht leer, der Inhalt ist kein Platzhalter / Überbleibsel einer Vorlage / offensichtlich abgeschnitten
• Wenn es Code oder ein Skript ist: Es kann wirklich ausgeführt werden (nicht „sieht richtig aus“)

B. Konformität

• Format, Felder, Benennung entsprechen den Auftragsanforderungen
• Die Menge stimmt (sollen 10 sein, sind es genau 10, nicht „ungefähr 8“)
• Keine Grenzüberschreitung: Es wurden keine Dateien geändert, die nicht geändert werden sollten, nichts wurde außerhalb des Auftrags geschrieben
• Parallele Aufgaben haben sich nicht gegenseitig überschrieben (überprüfe Dateiänderungszeit / Inhaltsintegrität)

C. Authentizität

• Für die vom Subagenten behaupteten Befehle gibt es entsprechende tatsächliche Ausgaben
• Wichtige Schlussfolgerungen können auf konkrete Quellen zurückgeführt werden (Datei, URL, Befehlsergebnis)
• 1–2 Stellen wurden willkürlich herausgegriffen und mit der Primärquelle abgeglichen; die Schlussfolgerungen stimmen überein
• Es gibt keine Zahlen oder Behauptungen, die „vernünftig aussehen, aber deren Quelle nicht gefunden werden kann“

D. Vollständigkeit

• Jeder im Auftrag geforderte Punkt wurde geliefert
• Unerledigte / unklare Teile wurden explizit aufgelistet, nicht versteckt
• Fehlgeschlagene Punkte wurden klar erläutert (was war falsch, was wurde versucht)

E. Letzter Check vor der Zusammenfassung

• In meiner Antwort an den Nutzer habe ich die Quelle und den Überprüfungsstatus angegeben
• Ich habe das „Selbstmeldung erfolgreich“ des Subagenten nicht als „erledigt“ in die Schlussfolgerung geschrieben

---

Häufige