Sub-Agents sparen nur dann Zeit, Geld und Nerven, wenn jemand sie steuert. Der Artikel beschreibt das Spannungsdreieck aus Zeit, Kosten und Qualität und zeigt, warum "alles an das grösste Modell" und "alles parallel" beide scheitern. Sieben Regeln fassen die Steuerung zusammen: zerlegen vor dem Vergeben, Kleines selbst machen, höchstens vier Agents gleichzeitig, Aufträge mit Ziel und Obergrenze, Zeitbox, Berichte als Behauptungen prüfen und Kurswechsel gebündelt weitergeben. Dazu kommen fünf Prompts zum Kopieren, eine Übersicht der Modellstufen mit den Preisen von Anthropic und die Erfahrung eines Tages, an dem zwei Pannen zu technischen Sicherungen führten.
Mit sieben Regeln und fünf Prompts steuerst du Sub-Agents so, dass Tempo, Rechnung und Fehlerrisiko zusammenpassen. Jede Regel kostet dich einen Satz im Prompt.
Ein einziger Agent braucht kaum Steuerung, zehn davon schon. Sobald du Arbeit an mehrere KI-Agenten verteilst, entscheidest du bei jedem Auftrag dreierlei: wie schnell das Ergebnis da sein muss, was es kosten darf und wie viel ein Fehler schadet. Viele Texte erklären, wie Multi-Agenten-Systeme aufgebaut sind. Dieser hier gibt dir eine Regel zum Mitnehmen und die Prompts dazu.
Das Spannungsdreieck: Zeit, Kosten, Qualität
Wer eine der drei Grössen maximiert, verliert bei den anderen. Schnell und billig heisst oft fehlerhaft. Fehlerfrei und billig dauert lange. Schnell und fehlerfrei kostet Rechenzeit auf dem teuren Modell.
Dabei sehen zwei Reflexe vernünftig aus und scheitern trotzdem. Der erste lautet: alles an das grösste Modell. Die Qualität stimmt, aber du bezahlst Urteilsvermögen für Arbeit, die keines braucht, etwa Umbenennen, Zählen oder Formatieren. Der zweite lautet: alles parallel. Das spart Wartezeit, bis zwei Agents dieselbe Datei anfassen oder gleichzeitig bauen. Dann kostet die Aufräumarbeit mehr, als die Parallelität gebracht hat.
Zudem unterschätzen viele das Preisschild. Anthropic beschreibt im Engineering-Blog zum Multi-Agenten-Forschungssystem (13. Juni 2025), dass Agenten rund viermal so viele Token wie ein Chat verbrauchen und Multi-Agenten-Systeme rund fünfzehnmal so viele. Mehrere Agents lohnen sich also dort, wo die Aufgabe den Mehrverbrauch wert ist.
Modellstufen: klein, mittel, gross
Fast jeder Anbieter staffelt seine Modelle in drei Stufen. Das kleine Modell ist schnell und billig, das mittlere bietet das beste Verhältnis aus Tempo und Leistung, das grosse denkt am gründlichsten und kostet am meisten. Bei Anthropic heissen die Stufen Haiku, Sonnet und Opus. Die Modellübersicht in der Dokumentation führt aktuell Haiku 5.5, Sonnet 5.5 und Opus 5.5, dazu Fable 5.1 als stärkste Stufe. Für die Arbeit mit Sub-Agents reichen die ersten drei. Preise nennt die Seite je Million Token (MTok), Stand 24. Oktober 2026.
| Stufe | Beispiel und Preis je MTok (Eingabe / Ausgabe) | Wofür die Stufe taugt |
|---|---|---|
| Klein | Haiku 5.5, ab 0,10 $ / ab 0,50 $ | Klassifizieren, Extrahieren, Routing, also Mechanik mit klarem Ergebnis |
| Mittel | Sonnet 5.5, 2 $ / 10 $ | Umsetzung: Code schreiben, Dateien ändern, Analysen mit klarem Auftrag |
| Gross | Opus 5.5, 4 $ / 20 $ | Planung, Architektur, Sicherheit und Fakten, bei denen ein Fehler teuer wird |
Quelle: Anthropic, Models overview (platform.claude.com), abgerufen am 24. Oktober 2026. Basispreise ohne Batch-Rabatt und Cache. Die Beschreibungen der Stufen folgen den Angaben dort. Andere Anbieter staffeln ähnlich, ihre Preise gehören in deren Preislisten.
Damit ist der Abstand zwischen den Stufen gross genug, dass sich die Zerlegung lohnt. Sonnet 5.5 kostet laut Tabelle halb so viel wie Opus 5.5, und Haiku 5.5 liegt bei der Eingabe 40-mal tiefer. Wie Anthropic das kleinste Modell positioniert, steht im Artikel Claude Haiku 5.5: Kleines Modell kostet 75 % weniger.
In Claude Code wählst du die Stufe je Auftrag. Laut Dokumentation zu Subagents setzt du das Modell beim Aufruf oder in der Definition des Subagents (sonnet, opus, haiku). Jeder Subagent startet mit einem leeren Kontext und bekommt nur seinen Auftrag. Daher muss der Auftrag alles enthalten, was er braucht. Die Doku nennt als Zweck ausdrücklich auch die Kostenkontrolle, indem Aufgaben an günstigere Modelle gehen.
Die sieben Regeln
- Zerlege, bevor du vergibst. Mechanik geht an das kleine Modell, Umsetzung an das mittlere, Urteil an das grosse. Ein Auftrag, der alles drei mischt, landet sonst bei der teuersten Stufe.
- Mach selbst, was kleiner ist als der Auftrag. Ein Auftrag zu schreiben, kostet Kontext, Wartezeit und die spätere Prüfung. Was du in wenigen Zeilen erledigst, delegierst du nicht.
- Parallel nur, was sich nicht in die Quere kommt. Höchstens vier Agents gleichzeitig, und wer dieselben Dateien anfasst, läuft nacheinander. Bauen, Veröffentlichen und Committen macht am Ende einer. Die vier sind ein Erfahrungswert, die Doku von Claude Code erlaubt bis zu 20 gleichzeitige Subagents.
- Jeder Auftrag nennt Ziel, Abnahme, Verbote und Obergrenze. Anthropic berichtet, dass vage Aufträge wie "recherchiere den Chipmangel" zu doppelter Arbeit führten. Gute Aufträge enthalten ein Ziel, ein Ausgabeformat, Hinweise zu Werkzeugen und klare Grenzen.
- Setze eine Zeitbox. Du steuerst einmal nach. Hilft das nicht, wechselst du die Stufe oder übernimmst selbst. Endloses Nachbessern frisst mehr Zeit als jeder Stufenwechsel.
- Berichte von Agents sind Behauptungen. Du prüfst Stichproben selbst und kritische Schalter immer. Ein Agent meldet "erledigt", weil er das glaubt, nicht weil du es gesehen hast.
- Gib einen Kurswechsel gesammelt weiter. Ändert sich die Richtung, bekommen alle laufenden Agents die Änderung in einer Nachricht. Tröpfchenweise Korrekturen erzeugen Widersprüche.
So beschreibt Anthropic das Muster im eigenen System: Ein führender Agent plant und verteilt, Subagents arbeiten parallel. In der Auswertung des Unternehmens schlug ein System mit Opus 4 als Lead und Sonnet-4-Subagents einen einzelnen Opus-4-Agenten um 90,2 Prozent. Die Zahl stammt aus einer internen Forschungsaufgabe und gilt nicht für jede Arbeit. Sie zeigt aber, dass die Aufteilung nach Stufen funktioniert.
Prompts zum Kopieren
Deshalb sind die folgenden Texte kurz. Passe Wörter wie "Dateien" oder "Veröffentlichen" an deine Arbeit an. Bei Texten, Tabellen oder Support-Tickets gelten dieselben Regeln.
a) Grundprompt für den Orchestrator
Er steht am Anfang der Sitzung oder in der Projektdatei (bei Claude Code in CLAUDE.md) und gilt für alle Delegationen.
Du orchestrierst mehrere Sub-Agents. Wäge jede Delegation nach drei Grössen ab:
Zeit (wann wird das Ergebnis gebraucht), Kosten (Modellstufe × Umfang) und
Qualität (was kostet ein Fehler). Opfere keine der drei für die anderen.
1. Zerlege jede Aufgabe in Urteil und Mechanik. Mechanik (Formatieren, Zählen,
Umbenennen, Links prüfen) geht an das kleinste Modell, Umsetzung an das
mittlere, nur Architektur, Sicherheit, heikle Fakten an das grösste.
2. Was du in wenigen Zeilen selbst erledigst, delegierst du nicht.
3. Höchstens 4 Agents gleichzeitig. Wer dieselben Dateien anfasst, läuft nacheinander.
Bauen, Veröffentlichen und Committen macht am Ende einer.
4. Jeder Auftrag nennt: Ziel, Abnahmekriterium, was nicht angefasst wird, Obergrenze.
5. Zeitbox: Einmal nachsteuern. Reicht das nicht, Modellstufe wechseln oder selbst übernehmen.
6. Berichte der Agents sind Behauptungen. Prüfe Stichproben selbst, kritische
Schalter immer, bevor du „fertig“ meldest.
7. Ändert sich die Richtung, gib die Änderung gesammelt an die Agents weiter.
b) Vorlage für einen einzelnen Auftrag
Ein Sub-Agent kennt dein Gespräch nicht. Alles, was er wissen muss, steht im Auftrag.
Ziel: <ein Satz: was am Ende vorliegen soll>
Kontext: <was der Agent über das Projekt wissen muss: Ort der Dateien,
Namensregeln, Stand der Arbeit, ein Beispiel für gutes Ergebnis>
Abnahme: <woran du erkennst, dass es stimmt: Befehl, Test, Kriterienliste>
Nicht anfassen: <Dateien, Dienste, Einstellungen, die tabu sind.
Nicht bauen, nicht veröffentlichen, nicht committen.>
Obergrenze: <höchstens N Dateien, höchstens M Minuten, höchstens ein
Nachbesserungsversuch. Wird es mehr, brich ab und melde den Grund.>
Bericht: <Format: 1. Was ist erledigt (Liste mit Dateinamen).
2. Was ist offen oder unsicher. 3. Was hast du selbst geprüft und wie.
Höchstens 15 Zeilen.>
c) Zeitbox und Eskalation
Du gibst ihn, wenn ein Agent zum zweiten Mal an derselben Stelle scheitert.
Der Agent hat die Abnahme zweimal nicht erreicht. Entscheide jetzt,
ohne weiteren Versuch mit demselben Auftrag:
1. Liegt der Fehler im Auftrag (unklares Ziel, fehlender Kontext)?
Dann schreibe den Auftrag neu und gib ihn derselben Stufe einmal.
2. Liegt er in der Aufgabe (zu viel Urteil für diese Stufe)?
Dann gib sie der nächsthöheren Stufe, mit dem bisherigen Ergebnis
und dem Grund des Scheiterns.
3. Ist der Rest in wenigen Zeilen erledigt? Dann mach ihn selbst.
Nenne in einem Satz, was du gewählt hast und warum.
d) Schlussprüfung
Er läuft, bevor du ein Ergebnis weitergibst oder "fertig" meldest.
Bevor du „fertig“ meldest, prüfe selbst, ohne dich auf die Berichte zu stützen:
1. Wähle drei Stichproben aus den Ergebnissen der Agents und öffne sie.
Stimmen Inhalt und Abnahmekriterium?
2. Prüfe jeden kritischen Schalter einzeln: Freigaben, Löschungen,
Berechtigungen, alles, was öffentlich oder nicht umkehrbar ist.
Kritische Schalter prüfst du immer, nie nur als Stichprobe.
3. Läuft der Gesamtstand (Build, Tests, Vorschau) ohne Fehler?
4. Erst wenn alles stimmt: melde „fertig“ mit einer Liste dessen,
was du selbst geprüft hast. Sonst melde, was offen ist.
e) Eine grosse Aufgabe in Urteil und Mechanik zerlegen
Zerlege diese Aufgabe, bevor du etwas vergibst:
<Aufgabe>
Liste alle Teilschritte. Ordne jeden einer Stufe zu:
- Mechanik (kleines Modell): Ergebnis ist eindeutig prüfbar.
- Umsetzung (mittleres Modell): Ergebnis hat einen klaren Auftrag.
- Urteil (grosses Modell): ein Fehler wäre teuer oder schwer zu erkennen.
Markiere, welche Schritte sich parallel laufen lassen (andere Dateien,
keine gemeinsame Abhängigkeit) und welche nacheinander. Nenne den Schritt,
der am Ende allein bauen, veröffentlichen oder committen darf.
Zeige mir die Tabelle, bevor du startest.
Meine Erfahrung
So habe ich am 24. Oktober 2026 diese Arbeitsweise an einem laufenden Projekt erprobt. Ich betreibe einen Blog und nutzte Claude Code mit Opus 5.5 als Orchestrator. An dem einen Tag liefen über ein Dutzend Artikel und mehrere Umbauten über Sub-Agents: ein zentrales Menü, eine zentrale Seitenleiste, ein Reporter mit Ressort-Quote und ein Baustein für die SharePoint-Startseite. Opus plante und prüfte, Sonnet führte aus. Haiku setzte ich nicht ein, obwohl mechanische Teile dabei waren. Dort habe ich Geld liegen lassen.
Dabei gingen zwei Dinge schief. Parallele Builds im selben Projekt störten sich: Einer löschte die Vorschau, während ein anderer sie las. Ausserdem verlor ein Artikel beim Überarbeiten seine Freigabesperre und ging ungewollt kurz live. Nach rund einer Stunde zog ich ihn zurück.
Daraus entstanden die Regeln 3 und 6 und zwei technische Sicherungen. Eine Bausperre lässt einen zweiten Bau warten, bis der erste fertig ist. Eine Freigabe-Liste erlaubt nur eingetragenen Artikeln den Weg nach draussen. Die Lehre daraus: Eine Regel im Prompt reicht nicht, wenn Agents sie befolgen müssen. Kritische Schalter brauchen eine technische Sicherung.
Einordnung: Was das für Teams, Entwickler, Redaktionen und KMU heisst
Daher sparen Teams, wenn sie Aufträge schriftlich fassen. Ziel, Abnahme, Verbote und Obergrenze verhindern Rückfragen, und die Vorlage zeigt jeder Person im Team, wie ein Auftrag aussieht. Entwickler profitieren von der Stufenwahl pro Aufgabe: Mechanik auf dem kleinen Modell senkt die Rechnung, Architektur und Sicherheit bleiben beim grossen. Redaktionen und Agenturen sollten Veröffentlichen und Freigeben technisch absichern, nicht nur per Anweisung, weil dort ein Fehler öffentlich wird. KMU brauchen keine eigene Agentenplattform. Es genügt der Grundprompt, ein Limit von vier gleichzeitigen Agents und eine Schlussprüfung vor jeder Freigabe. Und weil Multi-Agenten-Arbeit deutlich mehr Token verbraucht als ein Chat, lohnt sich ein Blick auf die Rechnung nach den ersten Wochen.
Fazit
Gutes Orchestrieren heisst, jede Delegation nach Zeit, Kosten und Qualität abzuwägen. Du zerlegst die Aufgabe, vergibst Mechanik an das kleine, Umsetzung an das mittlere und Urteil an das grosse Modell. Du begrenzt die Parallelität, schreibst vollständige Aufträge und prüfst Berichte selbst. Kopiere den Grundprompt, probiere ihn eine Woche und sichere alles ab, was nicht schiefgehen darf.
Quellen: Anthropic Engineering: How we built our multi-agent research system (13. Juni 2025), Claude Code: Create custom subagents, Claude Docs: Models overview mit Preisen. Stand: 24. Oktober 2026.
Geschrieben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.