Subagents vs. Agent-Teams: Welche Architektur für welche Aufgabe?

Zwei Ansätze, ein Ziel

Wenn eine Aufgabe zu groß für einen einzelnen Agenten wird, gibt es zwei Wege:

Subagents: Ein Hauptagent delegiert Teilaufgaben an untergeordnete Agenten. Er bleibt der zentrale Koordinator, die Subagents liefern Ergebnisse zurück.

Agent-Teams: Mehrere spezialisierte Agenten arbeiten gleichberechtigt zusammen. Jeder hat eine klare Rolle, die Kommunikation läuft über definierte Schnittstellen.

Beide Ansätze lösen dasselbe Problem – Aufgabenverteilung – aber mit unterschiedlichen Trade-offs bei Latenz, Qualität, Kosten und Komplexität.

Die eigentliche Frage ist nicht, welches Muster „besser” ist, sondern wie viel Kontrolle gebraucht wird und wie viel Qualität abgesichert werden muss. Subagents optimieren auf Kontrolle und Effizienz. Agent-Teams optimieren auf Qualität durch Iteration. Alles Weitere folgt daraus.

Subagents: Der hierarchische Ansatz

Dieses Muster findet sich in Frameworks wie Claude Code (über den /agents-Befehl und Markdown-Konfigs im Projekt) oder LangChain, wo ein Orchestrator via Tool-Call an delegierte Ketten übergibt.

Wie es funktioniert

Ein Hauptagent (oft „Orchestrator” genannt) erhält die Aufgabe und zerlegt sie in Teilaufgaben. Für jede Teilaufgabe startet er einen Subagent – eine separate Agenten-Instanz mit eigenen Instruktionen und eigenem Kontext.

Der Subagent bekommt einen begrenzten Auftrag, führt ihn aus und liefert das Ergebnis an den Hauptagent zurück. Der Hauptagent entscheidet, ob das Ergebnis ausreicht oder ob der Subagent nacharbeiten muss.

Stärken

Einfache Kontrolle: Ein zentraler Punkt steuert alles. Fehler sind leicht zu lokalisieren, weil der Hauptagent alle Zwischenergebnisse sieht.

Geringer Setup-Aufwand: Du brauchst nur einen Orchestrator und klar definierte Teilaufgaben. Keine Kommunikationsprotokolle zwischen Agenten nötig.

Gut für sequentielle Aufgaben: Wenn Schritt B auf dem Ergebnis von Schritt A aufbaut, ist die hierarchische Struktur natürlich.

Kontextisolation: Jeder Subagent bekommt nur den Kontext, den er braucht. Kein Kontextüberlauf.

Schwächen

Latenz: Subagents arbeiten meist sequentiell. Jeder Schritt wartet auf den vorherigen. Bei 5 Subagents mit je 30 Sekunden Laufzeit: 2,5 Minuten Gesamtdauer.

Single Point of Failure: Wenn der Orchestrator einen Fehler macht – falsche Zerlegung, falscher Kontext, falsches Routing – scheitert die gesamte Kette.

Begrenzte Iteration: Subagents geben ihr Ergebnis ab und sind fertig. Es gibt keine natürliche Feedback-Schleife zwischen Subagents untereinander (nur über den Hauptagent).

Wann Subagents die richtige Wahl sind

• Klar zerlegbare Aufgaben: Die Teilaufgaben sind unabhängig und eindeutig definierbar
• Sequentielle Abhängigkeiten: Schritt B braucht das Ergebnis von Schritt A
• Einmalige Durchläufe: Keine Iterationen zwischen den Teilen nötig
• Kostensensitive Aufgaben: Weniger Token-Verbrauch als bei Teams

Typische Beispiele:

• Daten sammeln → analysieren → zusammenfassen
• Code generieren → testen → dokumentieren
• Recherchieren → vergleichen → Empfehlung erstellen

Agent-Teams: Der kollaborative Ansatz

AutoGen und CrewAI sind zwei bekannte Frameworks, die das Team-Pattern explizit umsetzen: Rollen werden deklarativ beschrieben, die Library übernimmt Routing, Turn-Taking und Abbruchkriterien zwischen den Agenten.

Wie es funktioniert

Mehrere Agenten mit definierten Rollen arbeiten gleichberechtigt an einer Aufgabe. Die Kommunikation läuft über strukturierte Formate – jeder Agent produziert Outputs, die andere Agenten als Input nutzen.

Es gibt keinen zentralen Orchestrator. Stattdessen folgen die Agenten einem definierten Workflow: Wer gibt wann an wen weiter, wie viele Iterationen sind erlaubt, wann ist der Prozess abgeschlossen.

Stärken

Höhere Qualität: Durch Iterationsschleifen (Designer ↔ Kritiker) werden Ergebnisse mehrfach geprüft und verbessert.

Parallelisierbarkeit: Unabhängige Rollen können gleichzeitig arbeiten. Der Recherche-Agent kann bereits neue Daten sammeln, während der Erstellungs-Agent den letzten Batch verarbeitet.

Spezialisierung: Jeder Agent ist für seine Rolle optimiert – eigene Instruktionen, eigener Fokus, eigene Bewertungskriterien.

Robustheit: Kein Single Point of Failure. Wenn ein Agent ausfällt, können die anderen weiterarbeiten oder auf ein Fallback wechseln.

Schwächen

Höherer Setup-Aufwand: Rollen definieren, Kommunikationsformate festlegen, Iterationsregeln bestimmen, Abbruchkriterien setzen.

Mehr Token-Verbrauch: Jede Iteration zwischen Designer und Kritiker kostet Token. Bei 3 Iterationen × 4 Agenten kann der Token-Verbrauch das 5-10-fache eines einzelnen Durchlaufs betragen.

Kommunikationsoverhead: Agenten müssen sich „verstehen”. Unklare Übergabeformate führen zu Missverständnissen und Qualitätsverlust.

Schwerer zu debuggen: Wenn das Endergebnis schlecht ist, muss man die gesamte Kommunikationskette nachvollziehen. Bei Subagents reicht ein Blick auf den jeweiligen Subagent-Output.

Kommunikationsdesign entscheidet über Erfolg

Der häufigste Grund, warum Agent-Teams in der Praxis scheitern, ist nicht die Modellqualität, sondern das fehlende Kommunikationsdesign. Ohne klare Übergabeformate reden Agenten aneinander vorbei: Der Kritik-Agent liefert Fließtext, der Erstellungs-Agent weiß nicht, welche Punkte verbindlich sind und welche optional.

Strukturierte Formate lösen das Problem. Ein Kritik-Agent produziert zum Beispiel:

{
  "issues": ["fehlende Quelle in Abschnitt 2", "unklare Argumentation im Fazit"],
  "severity": "medium",
  "action": "revise"
}

Der Erstellungs-Agent kennt das Schema, kann die Issues einzeln abarbeiten und gibt die Überarbeitung wieder strukturiert zurück. Je präziser das Übergabeformat, desto weniger Iterationen sind nötig – und desto besser lässt sich der Workflow auch auditieren.

Wann Agent-Teams die richtige Wahl sind

• Qualitätskritische Outputs: Wenn das Ergebnis stimmen muss (Veröffentlichung, Produktion, Kundenkommunikation)
• Komplexe, iterative Aufgaben: Wenn mehrere Perspektiven nötig sind
• Wiederkehrende Workflows: Der Setup-Aufwand amortisiert sich bei Wiederholung
• Kreative oder analytische Aufgaben: Wo verschiedene Blickwinkel das Ergebnis verbessern

Typische Beispiele:

• Wöchentlicher Marktbericht (Recherche → Entwurf → Review → Finalisierung)
• Feature-Entwicklung (Analyse → Implementierung → Code Review → Integration)
• Content-Produktion (Themenrecherche → Texterstellung → Redaktion → Publikation)

Der Vergleich im Detail

Kriterium	Subagents	Agent-Teams
Latenz	Niedriger (sequentiell, aber weniger Durchläufe)	Höher (Iterationen kosten Zeit)
Qualität	Gut für klar definierte Aufgaben	Besser durch Feedback-Schleifen
Kosten	Geringer (weniger Token)	Höher (mehr Iterationen)
Setup	Einfach	Komplex
Debugging	Einfach (linearer Ablauf)	Komplex (Kommunikationskette)
Skalierung	Gut für mehr Teilaufgaben	Gut für höhere Qualität
Fehlertoleranz	Single Point of Failure	Robuster
Iteration	Keine (ohne extra Logik)	Eingebaut

Iteration ist nicht gleich Iteration. Bei Subagents verläuft sie linear: Der Orchestrator entscheidet, ob ein Subagent nacharbeiten muss. Bei Teams verläuft sie zyklisch: Die Agenten treiben sich gegenseitig, die nächste Runde initiiert nicht immer derselbe Akteur. Die Strukturfrage dahinter lautet: Wer startet die nächste Runde – ein zentraler Controller oder die Agenten selbst? Die Antwort bestimmt, wie kontrollierbar der Workflow bleibt.

Determinismus vs. Emergenz

Hinter den beiden Mustern steckt ein Unterschied, der in der Praxis oft wichtiger ist als Latenz oder Kosten: Wie reproduzierbar ist das Ergebnis?

Subagents sind weitgehend deterministisch. Gleiche Inputs führen zu ähnlichen Outputs, weil der Orchestrator den Ablauf kontrolliert. Das ist die Grundlage für reproduzierbare Pipelines – wichtig, wenn Prozesse auditierbar sein müssen oder jeder Durchlauf derselben Struktur folgen soll.

Agent-Teams sind emergent. Das Ergebnis entsteht aus der Interaktion zwischen den Rollen. Das kann Qualität hervorbringen, die ein einzelner Orchestrator nicht erreicht – kann aber auch zu unerwarteten Abweichungen führen. Zwei Durchläufe mit identischem Input liefern selten exakt dasselbe Ergebnis.

Die Konsequenz:

• Reproduzierbare Pipelines → Subagents. Wenn jeder Durchlauf nachvollziehbar sein muss.
• Exploration oder Qualitätsmaximierung → Teams. Wenn das beste Ergebnis zählt, nicht der gleiche Ergebnistyp.

Tooling beeinflusst die Architektur

Die Architektur-Entscheidung wird in der Praxis selten auf dem grünen Tisch getroffen. Das gewählte Framework drängt bereits zu einem bestimmten Muster:

• Claude Code – Subagent-first. Der /agents-Befehl und projektlokale Markdown-Konfigs machen die Orchestrator-Delegation zum Default-Weg.
• LangChain – flexibel, aber orchestration-heavy. Beide Muster lassen sich bauen, das Chain- und Tool-Call-Modell läuft aber am besten in hierarchischen Setups.
• AutoGen und CrewAI – Team-first. Rollen, Turn-Taking und Abbruchkriterien sind deklarativ, das Framework übernimmt das Routing.

In der Praxis wählt man also oft nicht die Architektur – das Tool zwingt einen indirekt dazu. Das ist kein Problem, solange die Wahl bewusst erfolgt: Erst die Aufgabenart klären, dann das passende Framework auswählen. Wer mit dem Tool beginnt, bekommt die Architektur als Nebenwirkung.

Die Entscheidungsmatrix

Häufigkeit und Qualitätsanforderung spannen einen einfachen Quadranten auf, der fast immer die richtige Architektur vorschlägt:

Konkret heißt das:

• Einmalige Aufgabe mit niedriger Qualitätsanforderung → ein Prompt reicht
• Einmalige Aufgabe mit hoher Qualitätsanforderung → Subagents (Zerlegung, jeder Teil liefert sauberen Output)
• Wiederkehrende Aufgabe mit niedriger Qualitätsanforderung → Subagents (effizient, wiederholbar)
• Wiederkehrende Aufgabe mit hoher Qualitätsanforderung → Agent-Team (Iterationen, Feedback, Qualitätskontrolle)

Schnelle Heuristik für den Alltag

Vier Fragen, die die Entscheidung im Alltag abkürzen:

• Kann die Aufgabe in klare Schritte zerlegt werden? → Ja: Subagents.
• Brauche ich Feedback-Schleifen zwischen Rollen? → Ja: Agent-Team.
• Muss das Ergebnis reproduzierbar sein? → Ja: Subagents.
• Ist das Ergebnis öffentlich oder geschäftskritisch? → Ja: Team oder Hybrid.

Drei von vier Antworten zeigen meist schon, wo die Architektur hin soll. Bei zwei und zwei lohnt sich der Hybrid-Ansatz.

Hybride Ansätze

In der Praxis sind reine Agent-Teams selten stabil genug für produktive Systeme. Die meisten erfolgreichen Setups sind hybrid: Subagent-Orchestrierung mit gezielten Feedback-Loops an den Stellen, wo Qualität kritisch ist. Der Hybrid ist nicht die Ausnahme, sondern der realistische Default – er kombiniert die Kontrollierbarkeit des Orchestrators mit der Qualität iterativer Rollen.

Subagents mit eingebautem Kritiker

Der Orchestrator delegiert an Subagents, aber einer davon ist ein Kritiker-Agent. Der Workflow:

1. Orchestrator zerlegt die Aufgabe
2. Subagent A erstellt den Output
3. Subagent B (Kritiker) prüft
4. Bei Problemen: Subagent A überarbeitet
5. Orchestrator führt alles zusammen

Das gibt dir die Einfachheit von Subagents mit der Qualitätskontrolle von Teams.

Agent-Team mit zentraler Steuerung

Ein Team aus spezialisierten Agenten, aber mit einem dedizierten Koordinator, der den Workflow steuert:

1. Koordinator startet den Recherche-Agent
2. Ergebnis geht an den Erstellungs-Agent
3. Koordinator routet den Output zum Kritiker
4. Koordinator entscheidet: Noch eine Iteration oder fertig?
5. Integrations-Agent erstellt das Endergebnis

Das gibt dir die Qualität von Teams mit der Kontrolle von Subagents.

Praktische Beispiele

Beispiel 1: E-Mail-Beantwortung (Subagent)

Einfach, schnell, tolerant gegenüber kleinen Fehlern.

Gesamtdauer: unter 30 Sekunden. Kosten: minimal. Qualität: ausreichend für interne und Standardantworten.

Beispiel 2: Technische Dokumentation (Agent-Team)

Komplex, qualitätskritisch, wird veröffentlicht.

Gesamtdauer: 5-10 Minuten. Kosten: höher. Qualität: nahe an manuell erstellter Dokumentation.

Beispiel 3: Code-Refactoring (Hybrid)

Technisch komplex, aber strukturiert genug für Subagents mit Qualitätskontrolle.

Schnellstart: Subagent in Claude Code

Claude Code bringt das Subagent-Pattern direkt mit. Ein eigener Subagent ist eine Markdown-Datei mit YAML-Frontmatter – entweder projektlokal unter .claude/agents/ oder global unter ~/.claude/agents/.

Mit dem Befehl /agents

Im Claude-Code-Prompt /agents eingeben und Create new agent wählen. Claude fragt nach Name, Beschreibung, Tool-Auswahl und Modell und legt die Datei automatisch an. Anschließend lässt sich der Subagent per @name oder in natürlicher Sprache ansprechen („use the code-improver agent to…”).

Manuelle Konfiguration

Alternativ direkt als Datei, z. B. .claude/agents/code-reviewer.md:

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
memory: user
---
You are a code reviewer. Analyze diffs and give actionable
feedback on quality, security, and best practices. Keep comments short.

Wichtige Felder

Feld	Zweck	Beispiel
tools	Allowlist (erbt sonst alle Tools)	Read, Grep (kein Write)
disallowedTools	Denylist	Edit, Write
model	sonnet, haiku oder inherit	haiku für schnelle Prüfungen
memory	Persistenter Speicher	project (versionierbar)
permissionMode	Umgang mit Tool-Berechtigungen	acceptEdits

Der Reviewer-Agent läuft damit in einem eigenen Kontextfenster mit reduzierter Toolmenge – das hält den Orchestrator-Kontext frei und reduziert unbeabsichtigte Schreibzugriffe.

Kosten-Nutzen im Überblick

Für eine typische wiederkehrende Aufgabe (wöchentlicher Report):

Subagent-Ansatz:

• Token pro Durchlauf: ca. 50.000 (Input + Output)
• Kosten: ca. 0,50 Euro
• Qualität: 70-80 Prozent des manuellen Ergebnisses
• Zeit: 1-2 Minuten

Agent-Team-Ansatz:

• Token pro Durchlauf: ca. 200.000 (4 Agenten × Iterationen)
• Kosten: ca. 2,00 Euro
• Qualität: 85-95 Prozent des manuellen Ergebnisses
• Zeit: 5-10 Minuten

Manuelle Erstellung:

• Kosten: 4h × 80 Euro = 320 Euro
• Qualität: 100 Prozent (Referenzwert)
• Zeit: 4 Stunden

Die Kosten-Frage ist also nicht „Subagent oder Team?”, sondern „Wie viel Qualität brauche ich?” Der Sprung von 0,50 auf 2,00 Euro ist vernachlässigbar gegenüber 320 Euro – die Qualitätsfrage entscheidet.

Der größte Kostenfaktor ist dabei selten das Modell, sondern falsche Iterationen. Ein schlecht designtes Agent-Team kann den Token-Verbrauch vervielfachen, ohne bessere Ergebnisse zu liefern – Kritik-Agent und Erstellungs-Agent drehen Schleifen, ohne dass die Qualität noch nennenswert steigt. Deshalb lohnt es sich, Iterationsregeln explizit festzulegen: Wie oft darf der Kritik-Agent Nacharbeit auslösen? Wann gilt das Ergebnis als „gut genug”? Ohne diese Grenzen wird ein Team schnell teuer, ohne besser zu werden.

Observability: nachvollziehen, was passiert

Spätestens wenn ein Agenten-System in Produktion läuft, wird Nachvollziehbarkeit entscheidend. Wer nicht sehen kann, warum ein Ergebnis entstanden ist, kann es auch nicht debuggen.

Subagents liefern ein lineares Log pro Durchlauf: Schritt 1 → Schritt 2 → Schritt 3. Jeder Subagent hat einen definierten Input, einen Output und einen Status. Audits sind einfach, Fehler gut lokalisierbar.

Agent-Teams brauchen Logging auf Nachrichtenebene: Wer hat wann was an wen geschickt, welche Iteration war die letzte, welches Argument hat den Abbruch ausgelöst? Ohne diese Ebene ist das Team eine Black Box – das Endergebnis ist sichtbar, der Weg dorthin nicht.

Für produktive Systeme heißt das: Observability einplanen, bevor die erste Iteration läuft. Bei Subagents reicht meist das Standard-Logging. Bei Teams braucht es strukturierte Nachrichten-Traces, vergleichbar mit dem Debugging verteilter Systeme.

Empfehlungen für den Einstieg

Wenn du gerade anfängst

Starte mit Subagents. Der Orchestrator-Pattern ist einfach zu verstehen und zu debuggen. Du lernst, wie Aufgaben zerlegt werden und wie Kontext übergeben wird.

Wenn die Qualität nicht reicht

Ergänze einen Kritiker-Subagent. Das allein hebt die Qualität deutlich – bei minimalem Zusatzaufwand.

Wenn der Workflow komplex wird

Wechsle zu einem Agent-Team. Definiere die Rollen (Recherche, Erstellung, Kritik, Integration), lege die Kommunikationsformate fest, bestimme die Iterationsregeln.

Wenn es produktionsreif sein muss

Nutze einen hybriden Ansatz: Agent-Team mit zentraler Steuerung. Die Kombination gibt dir Qualität und Kontrolle.

Die Architektur-Entscheidung – Subagents, Team oder Hybrid – ist kein einmaliges Setup, sondern eine laufende Abwägung. Der Einstieg muss nicht groß sein. Ein Orchestrator mit zwei Subagents für eine wiederkehrende Aufgabe. Ein Kritiker-Agent für die Qualitätskontrolle. Von dort wächst die Architektur mit den Anforderungen.