KI-Subagenten: Wenn aus einem KI-Mitarbeiter ein Team wird

KI-Subagenten sind spezialisierte Agenten, die ein Orchestrator-Agent startet und an die er Arbeit delegiert. Jeder bekommt sein eigenes Kontextfenster, seine eigenen Tools und eine eng gefasste Aufgabe. So landet eine große Aufgabe bei einem abgestimmten Team, das sie sich aufteilt, und nicht auf dem Schreibtisch eines einzigen überladenen Agenten. Du teilst nur dann in Subagenten auf, wenn die Arbeit wirklich verschiedene Arten von Fachwissen braucht, mehr Kontext, als ein einzelner Agent halten kann, oder Teilaufgaben, die gleichzeitig laufen müssen. Die meisten Aufgaben brauchen das nicht. Ein Team kostet Abstimmung, schafft mehr Stellen, an denen etwas schiefgehen kann, und treibt die Token-Rechnung deutlich nach oben. Deshalb ist im Normalfall ein einzelner guter Agent die ehrliche Antwort.

An einer Fertigungslinie stellst du keine zweite Maschine hin, weil auf dem Prospekt zwei abgebildet sind. Du stellst sie hin, wenn eine Maschine der Engpass ist. Bei Subagenten ist es dieselbe Entscheidung. Dieser Beitrag zeigt dir das Bild aus der Praxis: was ein Subagent ist, wann ein Team seine Kosten verdient, das Beispiel, das ich selbst nutze, und wann das Aufteilen die Sache schlimmer macht.

Was ist ein KI-Subagent?

Ein Subagent ist ein zweiter Agent, dem ein erster Agent ein Teilziel übergibt. Damit klar wird, warum das zählt, stell dir zuerst einen einzelnen Agenten vor. Er ist eine Schleife. Ein Modell bekommt ein Ziel und ein paar Tools, schlägt eine Aktion vor, etwas führt sie aus, das Ergebnis kommt zurück, und es schlägt den nächsten Schritt vor, immer weiter, bis das Ziel erreicht ist. Falls dir die Grundeinheit noch nichts sagt: Ich habe sie in Was ist ein KI-Mitarbeiter beschrieben.

Ein Multi-Agenten-System ist genau diese Schleife, nur mit einem neuen Element: Delegation. Ein Orchestrator-Agent läuft in seiner Schleife, aber manche seiner "Aktionen" sind keine Tool-Aufrufe. Sie übergeben ein ganzes Teilziel an einen Subagenten, der seine eigene Schleife läuft, mit eigenen Tools und eigenem Gedächtnis, und dann nach oben zurückmeldet. Aus einer Schleife wird ein ganzer Baum aus Schleifen. Anthropic nennt die typische Form das Orchestrator-Workers-Muster: Ein führender Agent zerlegt eine Aufgabe und delegiert an Subagenten, die parallel arbeiten (Anthropic, Building effective agents, 2024).

Jedes solche System hat dieselben vier Teile, und nur die ersten beiden tauchen überhaupt je in einer Demo auf:

Ein Orchestrator hält das Gesamtziel, entscheidet, wie er es aufteilt, und setzt zusammen, was zurückkommt. Der Generalunternehmer. Die eigentliche Facharbeit macht er nicht selbst.
Subagenten werden für eine fokussierte Aufgabe gestartet, jeder mit seinem eigenen Kontextfenster (damit einer, der in Quelldokumenten steckt, die Analyse eines anderen nicht verdrängt) und seinen eigenen Tools.
Eine Definition von "fertig" legt die Erfolgskriterien fest, an denen die Arbeit gemessen wird. Ohne sie liefert ein selbstständiges Team etwas Schnelles und Selbstbewusstes, aber nicht unbedingt das, was du gebraucht hast.
Ein Trace ist eine abspielbare Aufzeichnung, wer was getan hat, mit welchen Ein- und Ausgaben. Der einzige Weg, im Nachhinein zu rekonstruieren, was passiert ist.

Warum einen Agenten überhaupt in Subagenten aufteilen?

Zwei Gründe, und bei beiden geht es um Kontext. Der erste ist Abschottung: Ein Subagent bekommt ein sauberes, eigenes Kontextfenster für seinen Teil der Aufgabe. Wenn ich einen Recherche-Subagenten losschicke, um zwanzig Geschäftsberichte zu lesen, landet dieser ganze Rohtext in seinem Fenster, nicht im Fenster des Orchestrators, der nur die Zusammenfassung in drei Absätzen zurückbekommt. Der Hauptstrang bleibt übersichtlich, weil das Durcheinander in einem Worker eingesperrt ist, den man wegwirft, sobald er fertig ist.

Der zweite ist Parallelität. Drei Subagenten, die gleichzeitig drei Quellen lesen, sind ungefähr in der Zeit fertig, die einer allein braucht. Wenn die Teilaufgaben wirklich unabhängig sind, geht die Sache spürbar schneller durch.

Mit dieser Brille solltest du den Rest lesen: Subagenten bringen dir Kontext-Abschottung und parallele Geschwindigkeit. Intelligenz bringen sie dir nicht. Ein Team aus fünf mittelmäßigen Agenten bleibt genau das: fünf mittelmäßige Agenten mit einem Abstimmungsproblem. Eng verwandt damit ist die Frage, wie du überhaupt einem einzelnen Agenten eine enge, klar umrissene Aufgabe gibst. Das ist die Skills-Ebene, die du besser richtig hinbekommst, bevor du nach einem zweiten Agenten greifst.

Wann brauchst du wirklich ein Team aus KI-Agenten?

Jetzt kommt der Teil, der jeder Demo widerspricht: Ein Multi-Agenten-System ist ein Kostenpunkt. Es ist etwas, das du dir leistest, wenn es sich lohnt. Mehr Agenten heißt mehr Abstimmung, mehr Stellen, an denen etwas schiefgehen kann, mehr zu beobachten und mehr zu warten. Anthropics eigenes Engineering-Team schreibt, dass Multi-Agenten-Systeme ein Vielfaches an Tokens verbrennen können im Vergleich zu einem einzelnen Chat, weshalb sie sie für hochwertige Arbeit reservieren und im Alltag die Finger davon lassen (Anthropic, How we built our multi-agent research system, 2025).

Es gibt also drei ehrliche Antworten, und nur eine lautet "bau das Team":

Ein Agent reicht meistens. Wenn die Arbeit ein einziger Gedankengang über eine überschaubare Menge Kontext ist, erledigt das ein Agent in einer Schleife, und du hast eine Sache zu beaufsichtigen statt fünf. Der übliche Rat lautet, das einfachste Muster zu finden, das funktioniert, und Komplexität nur dann hinzuzufügen, wenn sie das Ergebnis nachweislich verbessert (Anthropic, 2024).
Ein Team lohnt sich, wenn die Arbeit wirklich parallel und spezialisiert ist. Eine tiefe Recherche zum Beispiel zerfällt in klar getrennte, unabhängige Untersuchungen, die jede von eigenem Fokus und Kontext profitieren und davon, gleichzeitig zu laufen. Da verdient ein Team sein Geld.
Manchmal sollten es gar keine Agenten sein. Wenn die Schritte fest sind und die Eingaben sauber, ist deterministischer Code günstiger und zuverlässiger. Wenn an der Entscheidung echte Konsequenzen hängen, gehört sie zu einem Menschen. Vielleicht bereiten Agenten die Arbeit vor, aber sie treffen die Entscheidung nicht.

Es gibt sogar ein starkes Gegenargument dafür, Systeme so weit wie möglich einsträngig zu halten, weil das Aufteilen von Arbeit über mehrere Agenten die Wege vervielfacht, auf denen Kontext zwischen ihnen verloren geht (Cognition, Don't Build Multi-Agents, 2025). Das Scheitern, das ich am häufigsten sehe: Ein Team greift zu Subagenten, weil alle gerade Multi-Agent vorführen, und steht am Ende mit fünf Agenten und einem Abstimmungsproblem da, um eine Aufgabe zu erledigen, die ein Agent oder ein geplantes Skript still erledigt hätte.

Wie sieht ein Subagenten-Team in der Praxis aus?

Nimm eine Aufgabe, die ich tatsächlich aufteile: ein geprüftes Markt-Briefing zu einem Wettbewerber erstellen. Mit "fass diese Seite zusammen" ist es nicht getan. Gefragt ist ein Ergebnis: Finde die Fakten im Netz, schreib das Briefing, prüfe jede Aussage gegen eine Quelle, und komm zu keinem Schluss, bevor die Aussagen halten. So läuft es über einen Orchestrator und drei Subagenten.

Der Orchestrator liest das Ziel und teilt es auf. Er startet einen Recherche-Subagenten, einen Schreib-Subagenten und einen Prüf-Subagenten, jeder mit seinem eigenen sauberen Kontextfenster.
Der Recherche-Subagent geht in die Breite: Er liest Quellen, zieht Zitate und Zahlen heraus, meldet ein strukturiertes Ergebnispaket nach oben. Der ganze rohe Seitentext bleibt in seinem Fenster, nicht in dem des Orchestrators.
Der Schreib-Subagent nimmt nur dieses Paket, nicht die zwanzig Rohseiten, und schreibt das Briefing aus einer sauberen, verdichteten Eingabe. So kann er sich auf die Formulierung konzentrieren statt auf den Quellen-Wust.
Der Prüf-Subagent bekommt den Entwurf plus das Ergebnispaket und macht genau eine Sache, und die ist bewusst kritisch angelegt: Er prüft jede Aussage gegen ihre angegebene Quelle und markiert alles, was nicht belegt ist. Das ist der Schritt, der einen Agenten dabei erwischt, wenn er selbstbewusst falsch liegt. Ein frischer Agent mit engem Auftrag entdeckt eine erfundene Zahl weit besser als der Agent, der sie geschrieben hat.
Markierte Aussagen gehen zurück in die Recherche. Der Orchestrator lässt Entwurf und Prüfung so lange kreisen, bis das Briefing die Definition von "fertig" erfüllt, und setzt dann die endgültige Antwort zusammen.

Achte darauf, was jede Aufteilung gebracht hat. Der Wust des Recherche-Subagenten verschmutzt nie den Entwurf. Die Prüfung funktioniert, weil sie ein frischer, unvoreingenommener Blick ist und nicht der Autor, der seine eigenen Hausaufgaben korrigiert. Und die drei konnten ihre ersten Durchläufe parallel machen. Nichts davon braucht ein klügeres Modell. Es braucht begrenzten, getrennten Kontext, und genau den kann dir ein einzelner überladener Agent nicht geben.

Wie betreibt Brixon die eigene Agentur mit Subagenten?

Wir betreiben unsere eigene Agentur mit rund neun KI-Agenten, und die ehrliche Antwort ist, dass die meisten davon einzelne Agenten für sich sind. Teams sind die Ausnahme. Die Lead-Sichtung ist ein Agent. Der Newsletter-Schreiber ist ein Agent. Wir machen etwas nicht zu einem Multi-Agenten-System, weil es beeindruckend klingt. Wir machen es, wenn ein Agent gegen eine echte Wand läuft, meistens eine Kontext-Wand, oder eine "diese zwei Durchläufe sollten sich kein Gehirn teilen"-Wand, wie beim Schreiben und Prüfen oben.

Dieselbe Disziplin bringe ich in Kundenprojekte. Ich bilde zuerst den Prozess ab und entscheide Schritt für Schritt, was deterministischer Code sein sollte, was ein Agent mit menschlichem Freigabepunkt, was Subagenten rechtfertigt und was menschlich bleiben sollte. Process First. Das heißt regelmäßig, dass ich gegen das Agententeam rate, mit dem ein Kunde begeistert reinkommt. Die Kurzformel, auf die ich immer wieder zurückkomme, ist KI fürs Urteilen, Code fürs Handeln, und ein Team vervielfacht das Urteilen, mit allen Abstimmungskosten, die das mit sich bringt. Wenn du noch nicht beobachten kannst, was deine Agenten tun, bring das in Ordnung, bevor du weitere hinzufügst. Warum, habe ich in Hör auf, KI-Agenten zu bemuttern beschrieben.

Was schiefgeht, wenn du zu früh aufteilst

Ein Team, das nicht begrenzt ist, keine Definition von "fertig" hat und nicht beobachtbar ist, scheitert nicht laut. Es scheitert, indem es schnell, selbstbewusst und falsch ist, und es hinterlässt keine Spur, wie es dazu kam. Fehler pflanzen sich durch ein Team fort: Eine wacklige Zahl vom Recherche-Subagenten wird zur Eingabe für den Schreib-Subagenten, der ein selbstbewusstes Briefing für den Orchestrator füttert, und der Fehler wird zu etwas reingewaschen, das seriös aussieht.

Auch die Abstimmungskosten sind real. Jede Übergabe ist eine Stelle, an der der Orchestrator eine Meldung falsch lesen kann, an der eine Teilaufgabe zu locker definiert sein kann, an der Kontext zwischen Agenten verloren geht. Bevor du aufteilst, ist der Test, den ich anlege, einfach: Kann ein Agent den ganzen Kontext halten, den diese Aufgabe braucht, und ist die Arbeit tatsächlich sequenziell? Wenn eines von beidem "ja" ist, gewinnt der eine Agent. Das Aufteilen musst du dir an einer echten Grenze verdienen. Es ist die Ausnahme, für die es einen konkreten Grund geben muss. Die Disziplin, die das Ganze ehrlich hält, egal ob einzelner Agent oder Team, ist Messung. Deshalb behandle ich Evals als nicht verhandelbar.

Häufige Fragen

Was ist der Unterschied zwischen einem KI-Agenten und einem Subagenten?

Ein KI-Agent ist ein Modell, das eine Schleife läuft: Es bekommt ein Ziel und Tools, schlägt Aktionen vor und arbeitet, bis das Ziel erreicht ist. Ein Subagent ist einfach ein Agent, dem ein anderer Agent (ein Orchestrator) ein Teilziel delegiert, mit eigenem, getrenntem Kontextfenster und eigenen Tools. Der Subagent macht seine fokussierte Aufgabe und meldet ein Ergebnis nach oben. "Subagent" beschreibt also eine Rolle in einem Team. Im Grunde ist es dasselbe wie ein Agent, nur in einer anderen Position.

Wann sollte ich ein Multi-Agenten-System statt eines einzelnen Agenten nutzen?

Nutze ein Team nur, wenn die Arbeit wirklich verschiedene Arten von Fachwissen braucht, mehr Kontext, als ein Agent halten kann, oder Teilaufgaben, die parallel laufen müssen, damit es sich lohnt. Wenn die Schritte fest sind und die Eingaben sauber, ist deterministischer Code besser. Wenn an der Entscheidung hohe Konsequenzen hängen, gehört ein Mensch ans Ruder. Ein Team sind Kosten, die du auf dich nimmst, wenn eine konkrete Grenze es erzwingt.

Was ist ein Orchestrator-Agent?

Ein Orchestrator-Agent hält das Gesamtziel, entscheidet, wie er die Arbeit aufteilt, delegiert Teilziele an spezialisierte Subagenten und setzt zusammen, was zurückkommt, zu einer endgültigen Antwort. Er ist der Generalunternehmer des Systems: Er stimmt das Team ab, macht die Facharbeit aber nicht selbst. Anthropic nennt das Orchestrator-Workers-Muster.

Machen Subagenten ein KI-System klüger?

Nein. Subagenten bringen dir Kontext-Abschottung und parallele Geschwindigkeit. Am Denkvermögen ändern sie nichts. Jeder Subagent bekommt ein sauberes Kontextfenster für seinen Teil der Aufgabe, und unabhängige Teilaufgaben können gleichzeitig laufen. Ein Team aus fünf mittelmäßigen Agenten bleibt aber fünf mittelmäßige Agenten plus ein Abstimmungsproblem. Das Aufteilen löst Grenzen bei Kontext und Durchsatz. Die Qualität des Denkens bleibt davon unberührt.

Wie viele KI-Agenten brauchst du wirklich?

Weniger, als die Demos nahelegen. Wir betreiben unsere eigene Agentur mit rund neun Agenten, und die meisten davon arbeiten für sich allein. Zu Teams greifen wir selten. Wir teilen nur dann in Subagenten auf, wenn ein Agent gegen eine Kontext-Wand läuft oder zwei Durchläufe sich wirklich kein Gehirn teilen sollten. Fang mit einem guten Agenten pro Aufgabe an und füge ein Team erst hinzu, wenn du auf die konkrete Grenze zeigen kannst, die die Aufteilung erzwingt.

Quellen und Weiterführendes

Anthropic, Building effective agents (2024): wann man Agenten statt Workflows nutzt; das Orchestrator-Workers-Muster; die einfachste Lösung bevorzugen. anthropic.com
Anthropic, How we built our multi-agent research system (2025): Multi-Agenten-Orchestrierung, Token-Kosten und Beobachtbarkeit in der Praxis. anthropic.com
Cognition (Walden Yan), Don't Build Multi-Agents (2025): das Argument für einsträngige Systeme und die Kosten verlorenen Kontexts zwischen Agenten. cognition.ai

Ich baue Agenten so, wie ein Ingenieur Maschinen an eine Linie stellt: nur am Engpass, und nur, wenn das neue Teil seine Abstimmungskosten verdient. Das meiste, was ich für Kunden ausliefere, ist ein sauber zugeschnittener KI-Mitarbeiter, der eine echte Aufgabe in den Tools erledigt, die sie ohnehin nutzen, mit einem Team aus Subagenten nur dort, wo sich die Arbeit wirklich aufteilt. Wenn du sehen willst, wie das als betriebener Dienst aussieht, hier bauen wir Fertige KI-Mitarbeiter, oder du sagst mir einfach, welche Aufgabe dein Engpass ist.