Aus der Garage: Ein Job, sechs Agenten, ein sauberer Kopf

Alle reden über KI-Agenten, als wäre “mehr davon” die Antwort. Der eigentliche Hebel ist die Frage davor: Was lagert man an einen Agenten aus, und was bleibt im Gespräch?

Aufgebockt

Auf dem Tisch lag eine Kundenseite auf einem Headless-Content-Management-System (Payload CMS). Sechs Seiten waren als Klone angelegt, jede brauchte denselben Umbau: das eingebettete HTML responsiv machen, damit auf dem Handy nichts mehr rausragt. Holen, umbauen, zurückschreiben, im Browser gegenprüfen. Sechsmal die gleiche Leier. Ziel: alle sechs live und verifiziert, ohne dass am Ende eine Seite vergessen in der Ecke liegt.

Der naheliegende Weg: alles der Reihe nach durch einen Chat schieben. Seite eins holen, umbauen, prüfen. Seite zwei holen, umbauen, prüfen. Und so weiter.

Wo’s klemmt

Genau da beißt es. Ein Sprachmodell arbeitet in einem Kontextfenster, seinem Arbeitsgedächtnis. Schiebt man sechs volle Umbau-Zyklen nacheinander durch, füllt sich dieses Gedächtnis mit sechsmal demselben Hin und Her: rohes HTML, Zwischenstände, Prüf-Ausgaben, Fehlversuche. Lauter Zeug, das nach dem Umbau kein Mensch mehr braucht, das aber im Kopf des Modells hängen bleibt.

Und ein volles Kontextfenster ist ein müder Kopf. Je mehr Ballast drin liegt, desto schlechter die Antworten, desto größer die Gefahr, dass bei Seite fünf ein Detail von Seite zwei durchschlägt. Serielles Abarbeiten skaliert nicht. Es wird langsamer und schlechter, je mehr draufkommt.

Der Dreh

Der Ausweg liegt in einem Unterschied, den Claude Code sauber trennt und der in der Praxis oft verschwimmt: Skill gegen Agent.

Ein Skill läuft in der laufenden Session. Er teilt sich den Kontext mit dem Gespräch, sieht den ganzen Verlauf und arbeitet inline weiter. Ein Skill ist im Grunde ein Satz Anweisungen für ein wiederkehrendes Vorgehen. (Dieser Blog-Post hier entsteht selbst über einen Skill, der die Schreibregeln der Serie kennt.) Gut ist ein Skill immer dann, wenn etwas den vollen Gesprächskontext braucht und am laufenden Faden weiterarbeiten soll.

Ein Agent ist etwas anderes. Er bekommt ein eigenes, frisches Kontextfenster, einen eigenen System-Prompt, ein einschränkbares Werkzeug-Set und auf Wunsch sogar ein anderes Modell. Er kriegt eine abgegrenzte Aufgabe, arbeitet autonom, und gibt am Ende nur ein verdichtetes Ergebnis zurück. Die ganze Zwischenarbeit bleibt in seinem Kopf, der Hauptkontext sieht sie nie. Ein Fork ist die Sonderform: ein Agent, der den bisherigen Kontext erbt, bevor er sich abkoppelt.

Für die sechs Seiten hieß das: sechs Fork-Agenten, einer pro Seite, in einem Rutsch losgeschickt. Jeder holte sein Layout, baute das HTML responsiv um, schrieb es zurück und verifizierte mit einem Browser-Test, dass mobil und Desktop keinen Überstand mehr hatten. Sie liefen parallel, jeder auf seiner eigenen Seite, ohne Kollision. Im Hauptchat kamen nur die Quittungen an: “eeg live, neun Blöcke, null Überstand”, “ueber-uns live, elf Blöcke”. Der orchestrierende Kopf blieb dabei leer genug, um den Überblick zu behalten.

Dasselbe Muster ein zweites Mal, an ganz anderer Stelle: Beim Triagieren offener Podcast-Folgen liegen pro Transkript schnell gut 20.000 Tokens an Rohtext an. Sieben Folgen linear durchlesen würde jedes Arbeitsgedächtnis sprengen. Also sieben read-only-Explore-Agenten parallel, jeder liest eine Folge und gibt einen knappen Triage-Report zurück. Die Zusammenschau passiert danach im Hauptchat, wo der volle Kontext über die schon vorhandenen Wiki-Inhalte sitzt. Lesen wird ausgelagert, Urteilen bleibt zentral.

Was hält

Die Faustregel, die aus beiden Fällen fällt, ist kurz: Braucht die Aufgabe den vollen Gesprächskontext und soll inline weiterlaufen, ist es ein Skill. Ist sie abgegrenzt, schwer oder parallelisierbar und würden ihre Zwischenschritte den Hauptkontext nur zumüllen, ist es ein Agent.

Praktisch heißt das: Stell vor jeder größeren Aufgabe eine einzige Frage. Läuft das in einem Kopf, oder in mehreren? Wiederholt sich dieselbe abgegrenzte Arbeit über mehrere Objekte (sechs Seiten, sieben Transkripte, zwölf Datensätze), gehört jedes Objekt an einen eigenen Agenten, und der Hauptchat sammelt nur die Ergebnisse ein. Hängt dagegen alles am selben roten Faden und baut aufeinander auf, bleibt es in der Session.

Zwei Leitplanken aus der Praxis noch dazu. Erstens: Ein Worker-Fork kann selbst keine weiteren Forks starten. Die Orchestrierung bleibt oben, beim Kopf, der die Aufgabe verteilt hat. Wer verschachteln will, plant das vorher. Zweitens: Grenz die Werkzeuge der Agenten bewusst ein. Die sieben Podcast-Leser waren read-only, sie konnten nichts kaputt machen, nur lesen und berichten. Ein Agent, der nur schauen darf, ist ein Agent, der nachts nicht anruft.

Die Zahl der Agenten ist dabei nie der Punkt. Sechs parallel klingen nach Wumms, sind aber nur die Folge einer Entscheidung, die vorher fällt: Diese Arbeit zerfällt in unabhängige Stücke, also kriegt jedes Stück seinen eigenen sauberen Kopf. Wer stattdessen alles in einen Chat presst, zahlt mit einem müden Modell und vergessenen Details. Die Kunst steckt in der Schnittführung, nicht in der Truppenstärke.