Ein KI-Agent oder mehrere? Wann sich Subagenten lohnen
Ob sich Subagenten lohnen, hängt davon ab, wie viel gemeinsamen Kontext Ihre Aufgabe braucht und wie klar sich Teilaufträge abgrenzen lassen. Unabhängige Werkzeugaufrufe können auch innerhalb eines gemeinsamen Agentenablaufs parallel laufen. Parallelisierung allein ist deshalb kein Grund für mehrere Agenten.
Für technische Produktverantwortliche und IT-Teams lautet die entscheidende Frage: Welche Informationen müssen bei jeder Entscheidung gemeinsam verfügbar bleiben – und welcher Teilauftrag lässt sich mit einem begrenzten Informationspaket zuverlässig abschließen?
Dieser Beitrag vergleicht beide Ansätze, zeigt einen fiktiven Einkaufsfall und liefert eine Delegationskarte sowie einen kleinen Untersuchungsplan. Eine pauschal bessere Architektur lässt sich daraus nicht ableiten.
Was gemeinsamer Ablauf und Subagenten bedeuten
In einem gemeinsamen Agentenablauf entscheidet ein Agent wiederholt über den nächsten Schritt, verwendet Werkzeuge und verarbeitet deren Ergebnisse in einem gemeinsamen Arbeitskontext. Das bedeutet weder einen einzigen Modellaufruf noch einen riesigen Prompt. Fachanweisungen und passende Daten können bei Bedarf geladen werden.
Ein Subagent bearbeitet einen delegierten Teilauftrag in einem eigenen Kontext mit eigenen Anweisungen und zugewiesenen Werkzeugen. Ein koordinierender Agent übernimmt das Ergebnis und führt es mit weiteren Informationen zusammen. Dabei muss ausdrücklich festgelegt werden, was übergeben wird und was der Subagent entscheiden darf.
Die vorgelagerte Frage, ob überhaupt ein Agent erforderlich ist, behandelt KI-Agent vs. Workflow vs. Automation. Hier geht es um die Aufteilung innerhalb einer bereits agentisch bearbeiteten Aufgabe.
Was Anthropic aktuell empfiehlt – und was daraus nicht folgt
Im Beitrag vom 22. Oktober 2026 beschreibt Anthropic Erfahrungen aus Unternehmensanwendungen: Bestimmte Router-, Planungs- und Fachagenten lassen sich in einen gemeinsamen Ablauf mit bedarfsgerecht geladenen Anweisungen integrieren. Als Gründe für Subagenten nennt der Anbieter unter anderem messbare Kontextprobleme und unabhängige Arbeit mit frischen Kontextfenstern. Das sind Anbietererfahrungen mit Claude, kein allgemeiner Vergleich aller Architekturen. Quelle: Building agents.
Das steht nicht im Widerspruch zu Anthropics Bericht über das eigene Multi-Agent-Recherchesystem vom 13. Juni 2025. Dort beschreibt der Anbieter Vorteile bei breit angelegten Recherchen mit unabhängigen Suchrichtungen und Grenzen bei stark geteiltem Kontext. Die Erfahrungen beziehen sich auf dieses Recherchesystem und seine internen Evaluationen. Quelle: Multi-agent research system.
Auch Forschung spricht gegen eine pauschale Rangliste: Der am 14. Oktober 2026 eingereichte Preprint Same Context, Different Agents untersucht Kontexttechniken mit sieben Modellen auf 1.514 Aufgaben aus fünf Datenagenten-Benchmarks. Die Wirkung von Orchestrierung hängt dort vom Verhalten der Ausgangsagenten ab. Das untersucht weder jeden B2B-Prozess noch den folgenden Einkaufsfall. Quelle: Sourati et al., arXiv:2610.20959.
Die praktische Schlussfolgerung: Prüfen Sie das konkrete Problem Ihrer Anwendung. Ein unübersichtlicher Prompt, fehlende Fachanweisungen und zu große Quelldokumente sind unterschiedliche Probleme. Ein zusätzlicher Agent löst sie nicht automatisch.
Entscheidungstabelle: gemeinsamer Kontext oder begrenzte Delegation?
Die folgende Tabelle ist eine Architekturhilfe, kein gemessener Benchmark.
| Beobachtung in Ihrer Aufgabe | Gemeinsamer Kontext spricht dafür | Begrenzte Delegation spricht dafür |
|---|---|---|
| Neue Anforderungen ändern viele Entscheidungen | Eine aktuelle Vorgabe muss überall wirken | Änderungen sind versioniert und betroffene Aufträge lassen sich gezielt neu starten |
| Teilaufgaben hängen stark voneinander ab | Zwischenergebnisse verändern laufend die nächsten Schritte | Eine Teilaufgabe hat trotz der Abhängigkeiten einen stabilen, prüfbaren Abschluss |
| Viele Fachanweisungen werden selten gebraucht | Anweisungen bei Bedarf in denselben Ablauf laden | Facharbeit benötigt tatsächlich einen eigenen, längeren Untersuchungspfad |
| Umfangreiche Quellen verdrängen relevante Vorgaben | Zunächst gezielte Suche und Kontextauswahl prüfen | Ein Teilauftrag kann Quellen untersuchen und belegte Ergebnisse kompakt zurückgeben |
| Mehrere Datenabrufe sind unabhängig | Werkzeuge parallel aufrufen, Ergebnisse gemeinsam auswerten | Zusätzlich sind unabhängige mehrstufige Untersuchungen mit eigenen Kontexten nötig |
| Rechte unterscheiden sich | Werkzeuge und Ausführung technisch beschränken | Ein separater Dienst setzt die erforderliche Trennung tatsächlich durch |
Stellen Sie vor einer Aufteilung eine Gegenfrage: Kann der koordinierende Agent das Teilergebnis prüfen, ohne die gesamte Arbeit noch einmal durchführen zu müssen? Wenn dafür alle verworfenen Annahmen und Zwischenschritte nötig sind, ist die Grenze möglicherweise falsch gezogen.
Fiktives B2B-Beispiel: drei Lieferantenunterlagen, eine neue Vorgabe
Dieses Beispiel ist vollständig fiktiv. Es beschreibt keinen Kundenfall und keine durchgeführten Tests. Ein Einkaufsassistent soll Unterlagen von drei Softwarelieferanten vergleichen. Zu Beginn gelten Funktionsumfang, Preis und Betriebsmodell als Kriterien.
Während der Bearbeitung ergänzt der Einkauf: Für den erforderlichen Funktionsumfang darf keine externe Cloud-Anbindung nötig sein. Diese Anforderung erhält die Revision R2; die ursprüngliche Fassung ist R1. Eine optionale Cloud-Funktion ist damit nicht automatisch ein Ausschlussgrund. Entscheidend ist, ob der benötigte Betrieb ohne sie möglich ist.
Wie eine unvollständige Übergabe das Ergebnis verzerrt
Ein Subagent hat Lieferant A bereits nach R1 geprüft und meldet „geeignet“. Ein zweiter untersucht Lieferant B, hat aber nur den Auftrag „Betriebsmodell prüfen“ erhalten. Er liest „On-Premise verfügbar“, übersieht jedoch die verpflichtende Cloud-Lizenzprüfung. Der dritte liefert für C eine ältere Produktbeschreibung; die aktuelle Anlage nennt eine zusätzliche Cloud-Abhängigkeit.
Wer diese Ergebnisse ohne Revision und Quellenstand zusammenführt, vergleicht unterschiedliche Anforderungen und Dokumentstände. Ein plausibel formulierter Gesamttext kann dann einen ungeeigneten Lieferanten empfehlen. Die Anzahl der Agenten ist nicht der unmittelbare Fehler: Es fehlen ein gemeinsamer Anforderungsstand und eine belastbare Abnahme der Teilergebnisse.
Was beim Wechsel auf R2 passieren muss
- Der koordinierende Ablauf speichert R2 als gültige Anforderung und ermittelt die betroffenen Teilaufträge.
- Ergebnisse nach R1 bleiben nachvollziehbar, werden aber nicht als abschließend gültig übernommen. Betroffene Aufträge werden aktualisiert oder neu gestartet.
- Jedes Ergebnis benennt Dokumentversion, Fundstelle und die geprüfte Anforderungsrevision. „Nicht erwähnt“ bleibt „nicht belegt“.
- Vor der Empfehlung wird für alle drei Lieferanten dieselbe R2-Vorgabe geprüft. Widersprüche führen zu einer offenen Frage statt zu einer stillen Auswahl der bequemeren Quelle.
Ein gemeinsamer Agentenablauf spart hier Übergaben. Auch er kann jedoch eine alte Zusammenfassung weiterverwenden oder eine Vorgabe übersehen. Er benötigt ebenfalls einen expliziten Anforderungsstand, Quellenbelege und eine Abschlussprüfung. Geteilter Kontext ersetzt keine Validierung.
Delegationskarte zum Wiederverwenden
Die Karte hält fest, was über eine Kontextgrenze hinweg erhalten bleiben muss. Verwenden Sie sie vor der Delegation und ergänzen Sie den Ergebnisbereich bei der Rückgabe.
| Feld | Eintrag für Ihren Teilauftrag | Beispiel aus dem fiktiven Einkauf |
|---|---|---|
| Teilauftrag | Ziel, Grenze und Abschlusskriterium | Für Lieferant B prüfen, ob der benötigte Betrieb ohne externe Cloud möglich ist |
| Eingaben und Revision | Freigegebene Quellen, Dokumentstände, aktuelle Anforderungen | Unterlagen B mit Versionskennung; Kriterien R2; benötigter Funktionsumfang ausdrücklich benannt |
| Ergebnis und Quellen | Strukturierte Aussage, Fundstellen, fehlende Nachweise | Erfüllt / nicht erfüllt / ungeklärt; Dokument, Seite oder Abschnitt und kurze Belegstelle |
| Entscheidungsumfang | Erlaubte Entscheidungen und ausgeschlossene Aktionen | Eigenschaften beurteilen; keine Lieferantenauswahl, Kontaktaufnahme oder Bestellung |
| Konflikte | Vorgehen bei widersprüchlichen oder fehlenden Angaben | Beide Fundstellen nennen; Unklarheit an Koordination zurückgeben |
| Änderungen während der Arbeit | Revision prüfen, alte Ergebnisse markieren, Aktualisierung bestätigen | Bei R3 betroffene Prüfung anhalten; Auftrag aktualisieren; keine R2-Rückgabe als aktuell akzeptieren |
| Abschlussprüfung | Verantwortlicher und technische sowie fachliche Abnahme | Koordination prüft Revision, Quellen, Vollständigkeit und Cloud-Vorgabe vor der Gesamtempfehlung |
Ergänzen Sie in der technischen Umsetzung eine eindeutige Auftragskennung, eine Frist und einen Status wie „offen“, „gültig“, „überholt“ oder „fehlgeschlagen“. Ein verspätetes Ergebnis darf einen neueren Stand nicht überschreiben. Die Anwendung muss diese Regeln durchsetzen; eine freundliche Anweisung im Prompt genügt dafür nicht.
Drei Varianten für dieselbe Aufgabe
| Variante | Aufbau | Was Sie damit prüfen |
|---|---|---|
| A: gemeinsamer Agentenablauf | Ein Agent hält Anforderungen und Vergleich zusammen und ruft die freigegebenen Werkzeuge auf | Reicht der gemeinsame Arbeitskontext für die gesamte Aufgabe? |
| B: gemeinsamer Ablauf mit Fachanweisungen | Derselbe Ablauf lädt beispielsweise eine Prüfanweisung für Cloud-Abhängigkeiten bei Bedarf | Hilft eine gezieltere Bereitstellung von Wissen ohne zusätzliche Übergaben? |
| C: begrenzte Delegation | Ein Agent delegiert einen klaren Teilauftrag, etwa die belegte Prüfung von Lieferant B, und nimmt das Ergebnis ab | Rechtfertigt die eigenständige Untersuchung den Aufwand für Übergabe und Prüfung? |
Für einen fairen Vergleich erhalten alle Varianten dieselben Quellen, Anforderungen und erlaubten Aktionen. Halten Sie Modellversion, Einstellungen und Gesamtbudget fest. C bekommt kein verdeckt größeres Budget, nur weil mehrere Kontexte beteiligt sind. Parallel zulässige Werkzeugaufrufe stehen auch A und B zur Verfügung.
Sechs Prüffälle und 36 vorgeschlagene Läufe
Beginnen Sie mit diesen sechs Fällen. Definieren Sie die erwarteten Ergebnisse vor dem ersten Lauf.
| Prüffall | Erwartetes Verhalten |
|---|---|
| Vollständige Daten | Alle geforderten Eigenschaften mit aktuellen Belegen vergleichen |
| Fehlende Eigenschaft | Fehlenden Nachweis benennen; keine Eigenschaft aus anderen Angaben erfinden |
| Widersprüchliche Unterlagen | Konflikt mit beiden Fundstellen offenlegen; ohne definierte Auflösung keine sichere Eignung behaupten |
| Geänderte Anforderung | R2 übernehmen und betroffene R1-Ergebnisse erneut prüfen |
| Verspätetes Ergebnis | Überholte Rückgabe erkennen; aktuelle Entscheidung nicht überschreiben |
| Ausgefallener Teilauftrag | Lücke sichtbar machen und den vorab definierten Wiederholungs- oder Eskalationsweg verwenden |
Bei A und B werden für die letzten beiden Fälle ein verspäteter beziehungsweise ausgefallener Werkzeugschritt simuliert; bei C die entsprechende delegierte Arbeit. So bleibt das fachliche Problem vergleichbar. Eine Empfehlung mit unvollständiger Prüfung muss in allen Varianten als solche erkennbar sein.
Drei Varianten × sechs Fälle × zwei Wiederholungen = 36 vorgeschlagene Läufe. Das ist ein Untersuchungsplan. Für diesen Beitrag wurden diese Läufe nicht durchgeführt. Zwei Wiederholungen pro Fall ergeben keine statistisch belastbare Rangliste; sie können zunächst konkrete Fehlerbilder sichtbar machen.
Bewerten Sie zuerst Quellenrichtigkeit, vollständige Übernahme der Anforderungen, Umgang mit Konflikten und Einhaltung der erlaubten Aktionen. Erfassen Sie danach Laufzeit, Modell- und Werkzeugkosten sowie menschliche Nacharbeit. Ein schnellerer Lauf gleicht eine verletzte Muss-Anforderung nicht aus.
Die Anleitung zur KI-Agent-Evaluation vertieft die Abnahme von Ergebnissen und Werkzeugaufrufen. Für den wirtschaftlichen Vergleich eignet sich die Kennzahl Kosten pro erfolgreicher Aufgabe, einschließlich Fehlversuchen und Nacharbeit.
Ein eigener Agentenkontext ist keine Berechtigungsgrenze
Ein separater Prompt verhindert keinen unerlaubten Datenzugriff. Eine technische Grenze entsteht durch die tatsächlich durchgesetzten Identitäten, Werkzeugberechtigungen, Datenfilter und Ausführungsumgebungen.
Wenn ein Subagent heute nur lesend auf bestimmte Lieferantenunterlagen zugreifen darf, darf seine Integration in den gemeinsamen Ablauf den Zugriff nicht auf weitere Dokumente oder Schreibaktionen ausweiten. Prüfen Sie Berechtigungen vor und nach dem Umbau auf Anwendungsebene. Gleiches gilt für Mandantentrennung, Freigaben und Auditierbarkeit.
Der Satz „Keine Bestellung auslösen“ gehört in den Auftrag. Die fehlende Bestellberechtigung gehört in die technische Umsetzung.
Nächster Schritt: eine Grenze prüfen, dann entscheiden
Nehmen Sie einen konkreten Teilauftrag aus Ihrem bestehenden Ablauf. Füllen Sie die Delegationskarte aus und markieren Sie, welche Informationen sich während der Bearbeitung ändern können. Vergleichen Sie anschließend A, B und C mit den sechs Fällen.
Eine Variante scheidet aus, solange sie Muss-Anforderungen verliert, Quellen erfindet oder ihre Rechte überschreitet. Wenn mehrere Varianten fachlich bestehen, entscheiden Wartbarkeit, Kosten und Laufzeit. Verallgemeinern Sie das Ergebnis erst nach weiteren repräsentativen Fällen.
Wenn Sie diese Entscheidung für einen Pilot oder eine bestehende Anwendung absichern möchten, unterstütze ich Sie als AI Solution Architect & Hands-on AI Engineer bei Architekturentscheidung und Umsetzungsplanung. Ausgangspunkt sind Ihr konkreter Ablauf, seine Kontextabhängigkeiten und überprüfbare Abnahmekriterien.