Ich habe 1.000 KI-Agenten mit 6 Schritten, 5 Prompts & 1 Datei ausgeführt (Entwickler-Leitfaden)

Prompting ist 2024 gestorben. Die neue Fähigkeit heißt Orchestrierung

Ich habe 30 Tage lang 1.000 KI-Agenten betrieben – das habe ich gelernt

Die Fähigkeit, die Prompting ersetzt hat, und die Systeme, die du heute einsetzen kannst.

Hör auf, deinen Prompt zu optimieren. Er ist nicht mehr der Engpass.

Mit einem Agenten in einem Chatfenster ist der Prompt der entscheidende Faktor.

Mit zehn Agenten, die stundenlang laufen, ist der Prompt ein Rundungsfehler.

Was die Qualität der Arbeit bestimmt, ist das System um die Agenten herum:

• in welchem Modus jede Aufgabe ausgeführt wird
• welches Modell welchen Schritt übernimmt
• wie die Agenten koordiniert bleiben
• wie „Erledigt" überprüft wird, während du schläfst

Ein Prompt liefert dir eine Ausgabe. Eine Schleife liefert dir eine sich verstärkende Operation.

Die Veränderung ist einfach. Du hörst auf, die Person zu sein, die jedes Ergebnis liest und die nächste Anweisung eintippt. Du wirst zu der Person, die das System einmal entwirft und es dann laufen lässt.

Diese Design-Ebene ist jetzt der Job. Hier ist, wie du sie aufbaust.

Du baust den Orchestrator, nicht den Code

Du verwaltest nicht dreißig Agenten, indem du mit dreißig Agenten sprichst. Du sprichst mit einem. Dieser eine ist der Orchestrator und verwaltet den Rest.

Ein guter Orchestrator macht genau drei Dinge:

1. Er zerlegt ein Ziel in abgegrenzte, unabhängig prüfbare Teilaufgaben.
2. Er delegiert jede Teilaufgabe an einen Worker, mit einem knappen Briefing und klarer Dateizuordnung.
3. Er setzt die Ergebnisse zusammen und entscheidet, was als nächstes passiert.

Eine Regel steht über allen anderen: Der Orchestrator macht die Arbeit niemals selbst.

Sobald dein leitender Agent anfängt, Implementierungscode zu schreiben, füllt sich sein Kontext mit Details und er verliert den roten Faden der gesamten Aufgabe.

Halte seinen Kontext sauber. Er denkt, teilt auf, weist zu und prüft. Nichts weiter.

Geh dann in die Tiefe, nicht in die Breite:

• Lass den Orchestrator nicht direkt acht Worker erzeugen. Das zersplittert seinen Kontext.
• Lass ihn stattdessen zwei oder drei Leiter erzeugen.
• Lass jeden Leiter seine eigenen zwei oder drei Spezialisten erzeugen.

Der Gewinn ist die dreifache Zerlegungstiefe bei gleichen Kontextkosten. So skaliert eine echte Organisation – durch Ebenen, nicht indem eine Person jede Aufgabe zuweist.

Überprüfbar oder nicht: die entscheidende Unterscheidung

Bevor du etwas baust, stelle eine Frage zur Aufgabe. Kann eine Maschine prüfen, ob sie erledigt ist?

Die Antwort bestimmt deine gesamte Vorgehensweise.

Wenn die Aufgabe überprüfbar ist, kannst du sie in eine Schleife packen:

• Tests bestehen oder sie bestehen nicht.
• Der Typ-Checker ist grün oder nicht.
• Der Benchmark erreicht den Schwellenwert oder nicht.

Richte einen Agenten auf eine überprüfbare Aufgabe aus, und er wird sie über Nacht optimieren. Du wachst auf und das Problem ist gelöst.

Wenn die Aufgabe nicht überprüfbar ist, hilft dir eine Schleife allein nicht weiter. Beispiele:

• Entwerfen einer guten Evaluierung.
• Entscheiden, ob sich eine API richtig anfühlt.
• Beurteilen, ob sich eine Forschungsrichtung lohnt.

Für diese Aufgaben musst du Geschmack einbringen. Du kannst das Ziel nicht übergeben und weggehen, weil es keine Hürde gibt, an der du anhalten kannst.

Die Lösung ist also, so viel wie möglich von der Arbeit überprüfbar zu machen:

• Verwandle „Mach es gut" in „Bestehe diese spezifischen Prüfungen."
• Ersetze vage Ziele durch konkrete, messbare.
• Wo das nicht geht, behalte einen Menschen im Kreislauf und steuere nach.

Ein Großteil der Orchestrierungs-Engineering besteht darin, vage Ziele in prüfbare zu verwandeln, damit die Schleife übernehmen kann.

Beginne mit dem kleinsten echten System: einer Zielschleife

Eine Zielschleife ist ein dauerhaftes Ziel plus eine deterministische Prüfung. Der Agent arbeitet Schritt für Schritt auf ein Ziel hin, anstatt nach einem Durchgang anzuhalten.

Das gesamte System ist eine Schleife um deinen Agenten und einen Validator:

1i=0
2until npm test -s; do
3  agent -p "Ziel: Die Testsuite grün machen.
4            LIES den Code und baue dir ein vollständiges Bild, BEVOR du etwas änderst.
5            'npm test' schlägt fehl. Mache die kleinste Änderung in Richtung Bestehen."
6  (( ++i > 20 )) && { echo "Stopp: 20 Iterationen"; exit 1; }
7done

Der Validator ist jeder Befehl, dessen Exit-Code das Tor ist. Tests, eine Typprüfung, ein Lint oder ein benutzerdefiniertes Skript.

Zwei Dinge sind nicht verhandelbar:

1. Eine Obergrenze. Eine Schleife ohne Stopp-Bedingung führt dazu, dass du mit einer fünfstelligen Token-Rechnung aufwachst.
2. Eine „Lies-zuerst"-Anweisung. Der Standard-Fehlermodus jedes Agenten ist, einen zufälligen Schuss auf die erste plausible Lösung abzugeben, anstatt den Code zu lesen.

Erzwinge das Lesen. Es ist langsamer pro Schritt und insgesamt weitaus schneller.

Mach „Erledigt" unverhandelbar: der Richter

Agenten hören vorzeitig auf. Sie sind darauf trainiert, in dem Moment aufzuhören, in dem sie es rechtfertigen können.

„Ich habe mein Bestes gegeben, ich höre hier auf" ist nicht dasselbe wie erledigt.

Wenn ein Agent seine eigenen Hausaufgaben benotet, schummelt er. Nicht böswillig. Er redet sich einfach ein, dass er fertig ist.

Die Lösung ist ein separater Richter:

• Ein zweiter Agent, dessen einzige Aufgabe es ist, die Arbeit anhand eines konkreten Bewertungsrasters zu bewerten.
• Er beantwortet eine Frage: erledigt oder nicht erledigt, und was fehlt.
• Er hat kein Interesse daran, anzuhalten, also zögert er nicht.

Lasse den Ersteller und den Richter mit verschiedenen Modellfamilien laufen. Verschiedene Familien machen unkorrelierte Fehler, sodass der Richter sieht, was der Ersteller übersieht.

1while :; do
2  agent --model "$BUILD" -p "Aufgabe: $TASK. Lies zuerst, implementiere, führe die Tests aus."
3  urteil=$(agent --model "$JUDGE" -p "Strenger Prüfer. Bewerte anhand jedes Punktes in rubric.md.
4            Antworte genau 'BESTANDEN' oder 'NICHT BESTANDEN: <was fehlt>'.")
5  [[ $urteil == BESTANDEN* ]] && break
6done

Gestalte das Bewertungsraster konkret und binär:

• Gutes Raster: „Alle Tests grün, Migration inbegriffen, kein Debug-Logging."
• Schlechtes Raster: „Mach es gut."

Ein desinteressierter Prüfer mit einem Vetorecht ist das Einzige, was einen Lauf stundenlang fortsetzen lässt, anstatt zusammenzubrechen, sobald der Worker müde wird.

Setze es nach jeder Aufgabenerledigung ein. Dann siehst du nur noch grün geprüfte Arbeit.

Weitere Schleifen, die du tatsächlich nutzen wirst

Die Zielschleife ist das Grundmuster. Ein paar Varianten decken das meiste ab, was du ausführen wirst.

1. Die Validierungsschleife.

Handeln, den Validator ausführen, den Fehler zurückmelden, wiederholen, bis das Tor grün ist.

Verwende sie für Regressionsdurchläufe, Typprüfungen und jeden deterministischen Bestehen/Nicht-Bestehen-Test.

2. Die Warteschlangen- und Zurücksetz-Schleife.

Zerlege die Arbeit in eine Liste kleiner, atomarer Aufgaben. Bearbeite eine nach der anderen.

Setze nach jeder Aufgabe den Agenten auf einen sauberen Kontext zurück und nimm die nächste auf.

Ein Kontext, der stundenlang läuft, füllt sich mit Verwirrung. Das Zurücksetzen hält jede Aufgabe sauber.

Der Speicher befindet sich außerhalb des Agenten, in der Aufgabendatei und im Commit-Verlauf.

1while read -r task; do
2  agent -p "Aufgabe: $task. Lies zuerst. Implementiere, dann führe die Tests aus."
3  npm test -s && git commit -aqm "auto: $task"   # nur bei Grün committen
4done < tasks.txt

3. Die Überwachungsschleife.

Richte einen Agenten auf einen Strom von Signalen aus und lass ihn herausfinden, was wichtig ist. Offene Issues, fehlschlagende Builds, Fehlerprotokolle, neues Feedback.

Er wartet nicht darauf, dass du fragst. Er liest, priorisiert und berichtet nach oben oder erstellt einen Entwurf zur Behebung.

1while sleep 300; do
2  agent -p "Lies die letzten 5 Minuten der Fehlerprotokolle. Wenn ein NEUES Muster auftaucht,
3            erstelle ein Issue mit einer minimalen Reproduktion. Ansonsten sag 'nichts Neues'."
4done

4. Die Plan-dann-Bau-Schleife.

Führe die Schleife in zwei Phasen aus. Zuerst ein Planungsdurchlauf, der einen schriftlichen Plan erstellt und anhält.

Du überprüfst den Plan. Dann folgt ein Ausführungsdurchlauf, der dem genehmigten Plan folgt.

Den Plan zu korrigieren ist billig. Den Code zu korrigieren ist teuer. Erwischt eine falsche Richtung im Plan.

Die Prompts, die die Arbeit machen

Ein Prompt ist kein Wunsch. Für einen Agenten ist er eine Spezifikation.

Der Unterschied zwischen mittelmäßiger und exzellenter Ausgabe liegt fast vollständig in der Qualität dieser Prompts.

Halte einen kleinen Satz wiederverwendbarer Prompts bereit. Fünf tragen die meiste Last.

1. Der Zerlegungs-Prompt für den Orchestrator:

1Du bist der Orchestrator. Schreibe KEINEN Code.
2Zerlege dieses Ziel in 3 bis 6 abgegrenzte Teilaufgaben.
3Für jede: eine einzeilige Beschreibung, die genauen Dateien, die sie besitzt, und ihre Erledigt-Prüfung.
4Markiere alle Aufgaben, die von einer anderen abhängen. Gib die Liste aus und halte dann an.
5Ziel: <Ziel>

2. Die Worker-Beschreibung für einen Spezialisten:

1Du besitzt NUR diese Dateien: <Dateien>.
2Aufgabe: <eine Zeile>. Erledigt, wenn: <überprüfbare Prüfung>.
3Lies diese Dateien und ihre Aufrufer, BEVOR du etwas bearbeitest. Ändere nichts außerhalb deiner Dateien.
4Wenn du fertig bist, schreibe einen 5-zeiligen Bericht nach <Name>.md und führe dann die Tests aus.

3. Der Richter-Prompt für eine andere Modellfamilie:

1Du bist ein strenger, kein Auge zudrückender Prüfer. Du hast diesen Code nicht geschrieben.
2Bewerte das Repository anhand JEDES der folgenden Punkte. Ein Fehler ist ein NICHT BESTANDEN.
3<Bewertungsraster>
4Antworte mit genau einer Zeile: 'BESTANDEN' oder 'NICHT BESTANDEN: <was fehlt>'.

4. Der Plan-zuerst-Prompt für den Plan-Modus:

1Erstelle einen schriftlichen Plan für <Ziel>. Behandle: Vorgehen, zu bearbeitende Dateien,
2Randfälle, Teststrategie und was du NICHT tun wirst.
3Schreibe noch keinen Code. Halte nach dem Plan an, damit ich ihn überprüfen kann.

5. Der Reflektiere-oder-Brich-ab-Prompt, wenn ein Agent feststeckt:

1Du hast dieselbe Prüfung 3 Mal nicht bestanden. Hör auf, die Vorgehensweise zu wiederholen.
2Antworte in 3 Zeilen: was genau fehlgeschlagen ist, welche Annahme falsch war,
3und die kleinste, andere Sache, die du versuchen könntest. Versuche dann NUR diese.

Ein Muster zieht sich durch alle fünf. Nenne die Rolle, die Grenzen, die Erledigt-Prüfung und was NICHT zu tun ist.

Modell-Routing: die Frage, die jeder stellt

Die Frage wird normalerweise als Wahl formuliert. Setze ich das teure Modell für die Planung oder für die Implementierung ein?

Das ist der falsche Rahmen. Route stattdessen nach der Schadensreichweite. Frage, wo dich ein Fehler am meisten kostet.

Die Logik ist einfach:

• Eine schlechte Entscheidung bei der Planung breitet sich auf deine gesamte Flotte aus.
• Eine schlechte Zeile in einer abgegrenzten, getesteten Funktion wird innerhalb von Minuten erkannt.
• Also gibst du dort Geld aus, wo Fehler teuer und irreversibel sind, und sparst dort, wo sie billig und begrenzt sind.

Hier ist das Routing, Stufe für Stufe:

1. Planung, Architektur und Zerlegung: immer die oberste Stufe. Höchste Hebelwirkung, winziges Token-Volumen. Hier zu sparen ist der teuerste Fehler, den du machen kannst.
2. Implementierung mit einer engen Spezifikation: mittlere Stufe, parallel ausführen. Die Spezifikation hat das Denken übernommen. Mit Tests verifizieren.
3. Implementierung mit einer lockeren Spezifikation: oberste Stufe. Das Füllen von Lücken erfordert logisches Denken, und ein billiges Modell rät in einem Dutzend Richtungen falsch.
4. Überprüfung und Beurteilung: eine andere Familie und keine billige. Hier fängst du die teuren Fehler ein.
5. Navigation, Suche, Zusammenfassung und Klassifizierung: das billigste, schnellste Modell. Null logisches Denken, hohes Volumen. Zahle niemals Premium-Preise für grep.

Die wahre Antwort auf „billige Planung oder billige Implementierung" ist also keines von beidem, blind.

Top-Modell für Planung und Überprüfung, immer. Implementierung ist die variable Größe.

Verschiedene Modellfamilien haben auch unterschiedliche Persönlichkeiten, und das ist für das Routing wichtig:

• Eine Familie füllt Lücken. Wenn die Spezifikation locker ist, trifft sie vernünftige Annahmen und macht weiter. Das hilft, wenn die Annahmen gut sind, und schadet, wenn sie es nicht sind.
• Eine andere Familie ist wörtlich zu nehmen. Sie macht genau das, was du gesagt hast, und nicht viel mehr, wie ein präzises Multifunktionswerkzeug.

Verwende den Lückenfüller, wo die Arbeit offen ist und die Spezifikation locker ist. Verwende den wörtlich zu nehmenden für die Überprüfung und für exakte, gut spezifizierte Änderungen.

Der Hebel, der die Implementierung steuert, ist deine Spezifikation

• Eine enge Spezifikation gibt dir das Recht, billige, parallele Worker einzusetzen.
• Eine lockere Spezifikation zwingt dich zurück zu einem teuren Modell, um die Lücken zu füllen.

Investiere in den Plan, genau damit du den Bau verbilligen kannst.

Eine Falle ist erwähnenswert. Billiges Routing optimiert den Preis jedes Aufrufs, kann aber leise den Anteil der Token zerstören, die ausgelieferte, merge-fähige Ausgabe produzieren.

Ein billiges Modell, das fünfmal wiederholt und Code produziert, den du nicht mergen kannst, ist teurer als ein sauberer Durchlauf eines Premium-Modells.

Miss die Kosten für die nützliche Ausgabe, nicht die Kosten pro Aufruf.

Für den Maßstab helfen zwei Zahlen:

• Deine oberste Stufe kostet etwa das Fünffache des Preises pro Token-Ausgabe einer billigen Stufe.
• Gestaffeltes Routing reduziert die Ausgaben typischerweise um 40 % bis 60 % im Vergleich zum Betrieb deines besten Modells überall.

Fähigkeiten: Paketiere einen Workflow einmal, verwende ihn immer wieder

Wenn du immer wieder denselben Prompt einfügst oder denselben Workflow ausführst, mache daraus eine Fähigkeit.

Eine Fähigkeit ist eine kleine Anweisungsdatei, die der Agent nur lädt, wenn sie relevant ist.

Du schreibst den Workflow einmal, und jeder Agent kann darauf zugreifen.

Eine Fähigkeitsdatei hat zwei Teile:

• YAML-Frontmatter mit einem Namen und einer Beschreibung.
• Einen Markdown-Textkörper mit den eigentlichen Anweisungen.

Die Beschreibung ist die wichtigste Zeile. Sie sagt dem Agenten, was die Fähigkeit tut und wann genau er sie verwenden soll, damit der Agent sie von selbst aufgreift, ohne dass du sie nennst.

Eine minimale Fähigkeitsdatei:

1---
2name: thermonukleare-prüfung
3description: Tiefgehende, konfrontative Code-Überprüfung. Verwende nach jeder nicht-trivialen Änderung
4  oder wenn du aufgefordert wirst, einen Diff vor dem Merge zu überprüfen, zu auditieren oder abzusichern.
5---
6
7# Thermonukleare Prüfung
8
9Lies den vollständigen Diff und die Dateien, die er berührt. Überfliege nicht.
10
11Prüfe in drei Durchgängen:
121. Korrektheit: Logikfehler, Randfälle, Race Conditions, Off-by-One-Fehler.
132. Sicherheit: Injection, Authentifizierung, Geheimnisse, unsichere Eingaben, destruktive Operationen.
143. Passung: Entspricht es der bestehenden Architektur oder schraubt es ein neues Muster an?
15
16Für jeden Befund: Datei, Zeile, Schweregrad und die einzeilige Behebung.
17Ende mit einem Urteil: AUSLIEFERN oder BLOCKIEREN, plus die Top 3 Dinge, die zuerst zu beheben sind.

Regeln für gute Fähigkeiten:

1. Halte die Datei kurz. Unter ein paar hundert Zeilen. Verschiebe langes Referenzmaterial in separate Dateien, auf die die Fähigkeit verweist.
2. Mache den Namen passend zum Ordner, sonst wird sie nicht geladen.
3. Schreibe die Beschreibung für die Auslösung. Führe die „Verwende, wenn"-Fälle aus.
4. Lasse niemals zu, dass ein Agent eine Fähigkeit umschreibt. Ein Mensch kuratiert jede Zeile.

Fähigkeiten sind der Weg, wie sich ein Workflow verstärkt. Wenn du etwas beim ersten Mal gut löst, speicherst du es und machst es auffindbar. Jede Sitzung danach ist es frei verfügbar.

Viele betreiben: die Flotte

Sobald eine Schleife funktioniert, skalierst du aus.

Gib jedem Worker zwei Dinge:

• Seinen eigenen Git-Worktree, sodass niemals zwei Agenten dieselben Dateien berühren.
• Sein eigenes Terminal-Fenster, damit du ihn beobachten und ihm Nachrichten senden kannst.

1tmux new-session -d -s fleet
2for name in hilbert gauss poincare; do
3  git worktree add -B "agent/$name" "../wt-$name" main
4  tmux new-window -t fleet -n "$name" -c "../wt-$name" "$AGENT"
5done

• Gib deinen Agenten Namen. Wenn fünfzehn laufen, ist „agent_7" nutzlos.
• Namen ermöglichen es dir, die gesamte Flotte im Kopf zu behalten. Dieser besitzt die Datenebene, jener schreibt Evaluierungen, jener prüft.
• Lesbarkeit ist der Punkt. Eine Flotte, die du nicht verfolgen kannst, ist eine Flotte, die du nicht steuern kannst.
• Bringe sie dann zur Zusammenarbeit. Standardmäßig ignorieren sich Agenten gegenseitig und behandeln alles von einem Geschwisterchen als Hintergrundrauschen.

Der Trick ist, Nachrichten zwischen Agenten als Benutzerrunden zu übermitteln. Modelle sind darauf trainiert, auf den Benutzer zu reagieren und Umgebungssignale weitgehend zu ignorieren.

1send() { tmux send-keys -t "fleet:$1" "$2" Enter; }
2send hilbert "GET /search?q= gibt [{id,title,url}] zurück. Verkabel die UI damit."

Dieser eine Schritt verwandelt einen Haufen isolierter Prozesse in ein Team, das sich Verträge übergibt und sich gegenseitig entblockt.

Du bleibst an der Spitze. Du sendest dem Leiter eine Nachricht, und der Leiter leitet sie an die Worker weiter.

Dynamische Workflows: Kompiliere die Koordination zu Code

Eine Schleife behält die Koordination innerhalb des Modells. Das Modell entscheidet jeden Schritt, was Token verbraucht und seinen Kontext füllt.

Ein dynamischer Workflow dreht das um. Der Orchestrator schreibt ein Skript, das die Worker koordiniert, und eine separate Laufzeitumgebung führt das Skript im Hintergrund aus.

Die Kernidee ist, wo der Zustand lebt. Die Schleife, die Verzweigungen und die Zwischenergebnisse sitzen in den Variablen des Skripts, nicht im Speicher des Modells.

Was dir das bringt:

• Koordination kostet null Modell-Token, weil einfacher Code sie übernimmt.
• Dein Hauptkontext bleibt sauber. Nur das Endergebnis kommt zurück.
• Es fächert weit auf. Dutzende Worker gleichzeitig, bis zu tausend in einem Lauf.

Wann du darauf zurückgreifen solltest:

• Das Muster ist bekannt und die Verifizierung ist objektiv.
• Die Arbeit ist breit und repetitiv. Viele Dateien, viele Fälle, viele Endpunkte.
• Es kann unbeaufsichtigt laufen.

Wann du nicht darauf zurückgreifen solltest:

• Du findest noch heraus, was zu tun ist. Das ist eine Zielschleife, kein Workflow.
• Die Aufgabe erfordert eine einzige kohärente Argumentationskette. Das will einen einzigen starken Agenten, nicht tausend.

Ein konkretes Beispiel. Angenommen, du musst 200 Dateien auf eine neue API migrieren:

1// der orchestrator schreibt das einmal; eine laufzeitumgebung führt es aus, nicht das modell
2const files = await glob("src/**/*.ts");
3
4const results = await mapLimit(files, 16, async (file) => {
5  const r = await subagent(`Migriere ${file} auf die neue API. Führe seine Tests aus.`);
6  return { file, ok: r.testsPassed };
7});
8
9const failed = results.filter(r => !r.ok);
10return `migriert ${results.length - failed.length} von ${results.length}. ` +
11       `wiederholung: ${failed.map(f => f.file).join(", ")}`;

Lies, was das tut:

1. Es listet die 200 Dateien im Code auf, nicht im Kopf des Modells.
2. Es führt 16 Unteragenten gleichzeitig aus, jeder migriert eine Datei und führt seine Tests aus.
3. Es zeichnet Bestehen oder Nicht-Bestehen pro Datei in einem einfachen Array auf.
4. Es gibt eine kurze Zusammenfassung zurück. Die 200 Zwischentranskripte berühren niemals deinen Kontext.

Das ist der springende Punkt. Das Modell hat einmal gedacht, um das Skript zu schreiben. Das Skript hat die Koordination übernommen, kostenlos.

Schutzmechanismen: was eine Flotte davor bewahrt, sich selbst zu fressen

Der menschliche Engpass hat früher echte Arbeit geleistet. Bei menschlicher Geschwindigkeit tun Fehler früh weh und du behebst sie, während du arbeitest.

Entferne dich vollständig, und kleine Fehler verstärken sich schneller, als du sie spüren kannst. Eine Dublette hier, eine unnötige Abstraktion dort.

Eines Tages wird sich die Architektur nicht mehr biegen lassen, und deine Tests sind unzuverlässig, weil Agenten auch diese geschrieben haben.

Jeder der folgenden Schutzmechanismen ersetzt die Korrektur, die der Engpass früher geliefert hat:

1. Lesen vor dem Raten. Mache es zu einer ständigen Regel in jedem Bau-Prompt, nicht zu einer Bitte pro Aufgabe.
2. Begrenzung und Abbruch. Jede Schleife bekommt eine Iterationsbegrenzung. Jeder Agent bekommt ein Token-Budget, das bei etwa 85 % automatisch pausiert. Nach drei feststeckenden Iterationen mit demselben Fehler brich den Agenten ab und übergib die Aufgabe einem neuen.
3. Eine Datei, ein Besitzer. Isoliere mit Worktrees. Lasse niemals zu, dass zwei Agenten dieselbe Datei bearbeiten.
4. Die Mission erneut einspielen. Sende bei langen Läufen die Checkliste alle paar Minuten als Benutzernachricht, damit der Agent nicht abdrifft, wenn sein Kontext voll wird.

1while sleep 900; do
2  send gauss "ERINNERUNG: noch an der Aufgabe? Lies zuerst. Führe Tests nach jeder Änderung aus. Bleibe in deinen Dateien."
3done &

Der tiefste Punkt liegt unter all dem:

• Die Verifizierung ist jetzt der Engpass, nicht die Generierung.
• Agenten produzieren plausible Ausgaben schneller, als du sie überprüfen kannst.
• Plausibel ist nicht korrekt.

Bis deine Verifizierung so schnell ist wie deine Generierung, ist die menschliche Überprüfung kein Overhead. Sie ist das Sicherheitssystem.

Gedächtnis: Du bist der Langzeitspeicher

Ein Modell hat ein Kurzzeitgedächtnis, das Kontextfenster, und sonst nichts. Alles, was über dieses Fenster hinausgeht, ist weg, es sei denn, du trägst es weiter.

Behandle dich selbst und die Dateien, die du aufbewahrst, als das Langzeitgedächtnis für Agenten, die nur ein Kurzzeitgedächtnis haben.

Zwei Gewohnheiten sind wichtig.

Erstens, übergib Zustand per Referenz, nicht per Zusammenfassung:

• Wenn ein Kontext voll wird, ist die faule Lösung, ihn zusammenzufassen. Zusammenfassungen sind verlustbehaftet und lassen das Detail weg, das du später brauchen wirst.
• Weise Agenten stattdessen auf Dateien, Aufgabenaufzeichnungen und frühere Ausgaben hin, die sie erneut lesen können. Nichts Wichtiges wird stillschweigend weggeworfen.

Zweitens, behalte dauerhaftes Gedächtnis außerhalb des Agenten:

• Eine Aufgabendatei mit Statusangaben.
• Ein laufendes Fortschrittsprotokoll.
• Den Commit-Verlauf.
• Eine Notizdatei für den Langzeitspeicher, die Muster und Stolperfallen sammelt.

Gestalte so, als ob deine Agenten tagelang laufen werden, denn mit guter Verdichtung werden sie das tun.

Die Modelle wissen das noch nicht über sich selbst. Sie tragen eine Verzerrung in sich, alles innerhalb eines kurzen Budgets zu lösen, als ob das Ausgeben von Token tödlich wäre. Dein Gerüst ist es, das ihnen ermöglicht, lange zu laufen, ohne den roten Faden zu verlieren.

Topologie: wie viele Agenten und in welcher Form

Mehr Agenten bedeutet nicht mehr Ausgabe. Ab einem bestimmten Punkt ist es weniger, weil Koordination nicht kostenlos ist und mit jedem Agenten, den du hinzufügst, zunimmt.

Die entscheidende Regel ist, die Form an die Arbeit anzupassen:

• Sequentielles, abhängiges Denken will weniger Agenten, manchmal einen. Das Aufteilen einer einzigen Gedankenkette fragmentiert das Denken und verschlechtert das Ergebnis.
• Unabhängige, parallele Arbeit will, dass du aufweitest. Flache Topologie, saubere Dateizuordnung. Hier zahlt sich Parallelität aus.
• Ein koordiniertes Team will drei bis fünf Arbeiter. Die Token-Kosten skalieren ungefähr linear mit der Größe. Die Koordinationskosten skalieren schlechter. Drei fokussierte Arbeiter schlagen fünf verstreute.

Wie kann also jemand Hunderte betreiben? Nicht als ein einziges riesiges Gespräch, das mit sich selbst argumentiert.

Sie betreiben sie als Tiefe und Unabhängigkeit:

• Ein paar Agenten, mit denen du tatsächlich sprichst, die jeweils nach unten an abgegrenzte Teilaufgaben delegieren, die nicht koordiniert werden müssen.
• Schwärme unabhängiger Schleifen, die ihr eigenes Ding machen und nach oben berichten.

Skalierung kommt von Delegationstiefe und Unabhängigkeit. Niemals von der Verbreiterung eines einzelnen Threads.

Die Steuerdatei: orchestration.md

Du hast wahrscheinlich eine Datei, die Agenten sagt, wie sie Code in deinem Repository schreiben sollen. Stil, Stolperfallen, Architektur. Behalte sie.

Sie beantwortet jedoch die falsche Frage für die Orchestrierung.

Die Datei orchestration.md beantwortet eine andere. Wie soll die Arbeit hier ausgeführt werden?

Es ist ein von Menschen geschriebener Vertrag, der abdeckt:

• welcher Modus für welche Aufgabe verwendet werden soll
• welche Modellstufe wohin geht
• was die Schutzmechanismen sind
• wann an einen Menschen eskalieren soll

Jeder Agent liest sie zu Beginn jeder Sitzung und verwendet sie, um seine Vorgehensweise selbst auszuwählen.

Dies ist die Datei mit der größten Hebelwirkung im Repository. Sie verlagert die Entscheidung über die Modusauswahl aus deinem Kopf, wo du sie bei jeder Sitzung inkonsistent neu triffst, in eine Spezifikation, der die Flotte folgt.

Eine kurze Version sieht so aus:

1# orchestration.md. Wie Arbeit HIER ausgeführt wird. Von Menschen kuratiert. Agenten dürfen nicht bearbeiten.
2
3Wähle den Modus:
4- Zielschleife (überwacht): vage oder gestalterische Arbeit. Definiere die Erledigt-Prüfung.
5- Validierungsschleife: deterministisches Tor. Immer Iterationen und Kosten begrenzen.
6- Bauen plus Richter: Worker baut, ein Richter einer anderen Familie genehmigt.
7- Flotte (drei bis fünf): voneinander abhängige Teilaufgaben, isolierte Worktrees, Peer-Nachrichten.
8- Warteschlange und Zurücksetzen: viele kleine atomare Aufgaben, frischer Kontext jedes Mal.
9- Dynamischer Workflow: bekanntes Muster, objektives Tor, breit und repetitiv. Koordination in Code, unbeaufsichtigt.
10
11Route Modelle nach Schadensreichweite:
12- Planung und Architektur: immer oberste Stufe.
13- Bauen, enge Spezifikation: mittlere Stufe, parallel, mit Tests verifizieren.
14- Bauen, lockere Spezifikation: oberste Stufe, weil Lückenfüllen logisches Denken ist.
15- Überprüfung und Richter: eine andere Familie. Niemals das Modell des Implementierers.
16- Navigation, Suche, Zusammenfassung: billigstes. Optimiere merge-fähige Ausgabe, nicht Aufrufpreis.
17
18Schutzmechanismen:
19- Token-Budget pro Agent. Auto-Pause bei etwa 85 %. Nach 3 feststeckenden Versuchen abbrechen und neu zuweisen.
20- Jeder Lauf über einer Stunde braucht einen separaten Richter. Worker melden sich nie selbst als erledigt.
21- Lies Code, bevor du Hypothesen aufstellst. Plane schriftlich vor der ersten Bearbeitung.

Zwei Regeln regieren die Datei:

1. Halte sie kurz.
2. Lasse niemals zu, dass ein Agent sie umschreibt.

Der Wert liegt darin, dass ein Mensch jede Zeile kuratiert hat.

Was deins bleibt

Orchestrierung macht Agenten zuverlässig bei der Ausführung. Sie wählt nicht das Problem aus und weiß nicht, was gut ist.

Drei Dinge bleiben dauerhaft auf deiner Seite der Linie.

Erstens, delegiere die Aufgaben, nicht das Urteilsvermögen:

• Übergib Agenten abgegrenzte Arbeit mit klaren Bestehens- oder Nichtbestehenskriterien. Standardcode, Migrationen, Testgerüste und Ansätze, für die du niemals die Zeit hättest, sie von Hand auszuprobieren.
• Behalte die Architektur, die Entscheidung, was nicht gebaut werden soll, und die Überprüfung im vollständigen Kontext für dich selbst.
• Agenten haben einen Ozean mittelmäßiger Architektur aufgesogen und werden fröhlich schwerfällige Muster in ein Projekt kopieren, das sie nicht haben sollte. „Nein" zu sagen ist eine Funktion, die sie nicht haben.

Zweitens, deine Spezifikation ist die Hebelwirkung:

• Wenn man sich auf eine Flotte verteilt, bremst vages Denken nicht nur – es multipliziert sich.
• Eine einzige unklare Anforderung pflanzt sich in Dutzende paralleler Durchläufe fort, jeder macht auf seine eigene Weise etwas falsch.
• Eine präzise Spezifikation multipliziert sich in präzise Umsetzungen überall.

Deshalb holt ein guter Ingenieur mehr aus diesen Werkzeugen heraus, nicht weniger. Das Tippen wurde automatisiert. Das Verständnis wurde verstärkt.

Verbringen Sie den Großteil Ihrer Zeit im Plan-Modus, mit einem schriftlichen Plan, auf den sich alle einigen, bevor der erste Schnitt erfolgt.

Drittens: Absichtlich unterfinanzieren:

• Besetzen Sie einen Job für vier Agenten mit zwei. Der Zwang erzeugt das gewünschte Verhalten.
• Sie bauen Schleifen, statt Dinge von Hand zu erledigen, und beim nächsten Mal ist diese Arbeit bereits automatisiert.
• Verlagern Sie Ihr Budget von manueller Arbeit auf Tokens. Hohe Anfangsinvestition, danach Grenzkosten nahe Null für immer.

Die Teams, die das tun, profitieren vom Zinseszinseffekt. Diejenigen, die es nicht tun, zahlen jedes Mal den vollen Preis.

Sie schreiben nicht länger die Software. Sie bauen die Fabrik, die sie schreibt.

Eine Fabrik braucht präzise Eingaben, Qualitätskontrolle an jeder Station und einen Besitzer, der weiß, was das Produkt sein soll.

Hier starten

Versuchen Sie nicht, am Montag hundert Agenten laufen zu lassen. Steigen Sie die Leiter hinauf:

1. Führen Sie eine einzelne Zielschleife für eine Aufgabe mit überprüfbarer Ziellinie aus. Lernen Sie, wie sich eine gute Fertigstellungsprüfung anfühlt.
2. Fügen Sie für alles über eine Stunde einen Richter aus einer anderen Modellfamilie hinzu. Untersagen Sie selbst gemeldete Fertigstellung.
3. Schreiben Sie Ihre orchestration.md. Weisen Sie Ihre Agenten an, sie zuerst zu lesen. Beobachten Sie, wie sie beginnen, Modi für Sie auszuwählen.
4. Verteilen Sie sich vorsichtig. Eine parallelisierbare Aufgabe, drei bis fünf Arbeiter, isolierte Arbeitsbäume, Token-Budgets.
5. Routen Sie Ihre Modelle. Oberste Ebene für Planung und Überprüfung, günstigere für begrenzte Baumaßnahmen und Grind. Messen Sie zusammenführbare Ausgabe.
6. Lassen Sie es unbeaufsichtigt laufen, sobald ein Muster validiert und objektiv prüfbar ist. Leeren Sie den Rückstand über Nacht.

Das System muss nur ungefähr richtig sein, nicht perfekt:

• Die Steuerungsdatei gibt der Flotte genug Struktur, um sich selbst zu steuern.
• Der Richter fängt die Randfälle ab.
• Die Erinnerungsschleife kümmert sich um das Gedächtnis.
• Ihr Geschmack entscheidet über die Aufgaben, die sich nicht delegieren lassen.

Prompting war die Fähigkeit des letzten Jahres. Das hier ist die Fähigkeit jetzt.

Die ausführbaren Versionen aller Systeme hier – die Zielschleife, die Richter-Schleife, der Flottenstarter, der Message Bus, der Erinnerungs-Watchdog und der Modell-Router – befinden sich im Begleitpaket. Setzen Sie eine Variable auf Ihre Agenten-CLI und los geht's.

Haftungsausschluss

Dieser Artikel wurde unter Verwendung von Claude Code-Sitzungen und Codex-Sitzungen des Autors verfasst.

Vom Autor und dem Modell Kimi K2.6 auf grammatikalische und Formatierungsfehler hin bearbeitet.