KI-News26. Mai 2026

Subagents in Claude Code: Wann Multi-Agent-Workflows wirklich Sinn machen

Subagents sind das Buzzword der ersten Jahreshälfte 2026. Anthropic hat sie in Claude Code etabliert, jede zweite Dev-Newsletter pitcht "Agent Teams" und in Demos zerlegen fünf parallele Subagents stolz ein Refactoring. Die Realität im Alltag ist ernüchternder: Subagents können das Vierfache an Tokens kosten, produzieren ohne klares Ownership-Modell parallele Verwirrung, und in den meisten Fällen schlägt eine gut geplante Single-Session ein schlecht koordiniertes Team. Dieser Artikel klärt, wann sich Claude Code Subagents tatsächlich lohnen und wann sie der falsche Hammer sind.

Was Subagents in Claude Code eigentlich sind

Ein Subagent ist eine spezialisierte AI-Instanz mit eigenem Kontext, eigenem Systemprompt und einer klar umrissenen Aufgabe. Der Haupt-Agent (die Session, in der man chattet) delegiert eine Teilaufgabe an einen Subagent, dieser arbeitet sie ab und liefert ein Ergebnis zurück. Anschliessend kann der Haupt-Agent das Ergebnis weiterverarbeiten oder den nächsten Subagent starten.

Technisch liegen Subagents als Markdown-Dateien unter ~/.claude/agents/<slug>.md. Sie haben ein YAML-Frontmatter mit Name, Beschreibung und Modell, gefolgt vom eigentlichen Systemprompt. Aufgerufen werden sie entweder über den /agents-Befehl in einer Session oder programmatisch über den Claude Agent SDK.

Wichtig ist die Abgrenzung zu sogenannten Agent Teams: Subagents arbeiten in der Regel isoliert und melden Ergebnisse zurück. Agent Teams hingegen koordinieren sich untereinander, teilen Discoveries und challengen gegenseitig Annahmen. Für 90 Prozent der Fälle reicht der einfachere Subagent-Modus völlig aus.

Drei Fälle, in denen Subagents klar gewinnen

Fall 1: Kontext-Trennung schützt das Hauptfenster

Wenn eine Teilaufgabe viel Input liest, aber nur ein kurzes Ergebnis liefert, ist ein Subagent ideal. Beispiel: Ein "Doc-Reader"-Subagent durchsucht 50 Markdown-Dateien einer Doku und liefert drei relevante Snippets zurück. Die Haupt-Session bleibt von 200.000 Tokens Doku-Rauschen verschont und kann den eigentlichen Code-Task fortsetzen.

Konkret: Bei Recherche-, Such- oder Vergleichsaufgaben, deren Output sich sauber zusammenfassen lässt, sind Subagents fast immer die richtige Wahl.

Fall 2: Spezialisierung über wiederkehrende Rollen

Bestimmte Aufgaben tauchen in Projekten immer wieder auf: Code-Review, Security-Audit, Test-Schreiben, Mail-Drafting, Blog-Texten. Für jede dieser Rollen lohnt sich ein eigener Subagent mit dediziertem Systemprompt. Ein "Reviewer"-Subagent muss nicht jedes Mal neu erklärt bekommen, dass er auf Fehlerklassen X, Y und Z achten soll – das steht in seinem Prompt fest.

Solche Rollen-Subagents sind die Marblism-Idee: Statt einer monolithischen AI hat man ein Team aus spezialisierten Mitarbeitern, die je nach Bedarf gerufen werden.

Fall 3: Parallelisierung unabhängiger Teilaufgaben

Wenn drei Tasks wirklich unabhängig voneinander laufen können – kein gemeinsamer State, keine Reihenfolgeabhängigkeit – beschleunigen parallele Subagents den Durchsatz spürbar. Beispiel: Drei Mikroservices müssen je eine Health-Check-Route bekommen. Drei Subagents, drei PRs, fertig.

Die Praxisgrenze liegt laut den meisten 2026er-Erfahrungsberichten bei drei bis fünf parallelen Subagents. Darüber wird die Mergerei am Ende zum Bottleneck.

Drei Fälle, in denen Subagents schaden

Fall 1: Die Aufgabe ist klein und linear

Wer einen Bugfix in einer Datei hat, braucht keinen "Implementation-Subagent" plus "Test-Subagent" plus "Review-Subagent". Das Setup dauert länger als der Fix selbst, die Tokens vervierfachen sich und die Koordination liefert keinen Mehrwert. Faustregel: Unter 30 Minuten Arbeitsaufwand fast nie Subagents.

Fall 2: Tasks brauchen gemeinsamen Kontext

Wenn Subagent A die Datenbankschema-Aenderung macht und Subagent B die API anpasst, müssen beide wissen, was der andere tut. In dem Moment, in dem Kontext geteilt werden muss, ist eine einzige Session mit klarer Planungsphase praktisch immer besser.

Fall 3: Kein klarer Output-Vertrag

Subagents funktionieren, wenn der Haupt-Agent genau weiss, was er zurückbekommt. Wenn man nicht in einem Satz formulieren kann "Subagent X liefert Y zurück", produziert die Delegation nur Reibung.

Die Token-Frage: Was kostet das wirklich?

Subagents laufen in eigenen Kontextfenstern. Jeder einzelne trägt Systemprompt, Task-Beschreibung und ggf. eingelesene Dateien neu in seinen Kontext. Wer drei Subagents startet und sie jeweils 20.000 Tokens an Input lesen lässt, zahlt 60.000 Input-Tokens – plus den Output, plus den Round-Trip im Haupt-Agent.

Bei Sonnet 4 mit 3 USD pro Million Input-Tokens und 15 USD pro Million Output-Tokens addiert sich das schnell. Eine "harmlose" Multi-Agent-Recherche kann pro Run bei 1,50 bis 3,00 Euro landen – für ein Ergebnis, das eine einzelne, gut geplante Session für 50 Cent geliefert hätte.

Das ist nicht teuer im absoluten Sinne, aber es ist teuer ohne Mehrwert. Genau diese Kosten/Nutzen-Frage entscheidet, ob ein Subagent-Setup eine Investition oder Verschwendung ist.

Eine pragmatische Heuristik für 2026

Vor jedem Multi-Agent-Setup drei Fragen stellen:

Lässt sich die Aufgabe sauber in unabhängige Teile zerlegen? Wenn nein, eine Session.
Hat jeder Teil einen klaren Output-Vertrag? Wenn nein, eine Session.
Spart die Parallelisierung mehr Zeit, als die Koordination kostet? Wenn nein, eine Session.

Erst wenn alle drei Antworten Ja lauten, lohnt ein Subagent-Setup. Und auch dann: lieber drei spezialisierte Subagents mit klaren Rollen als fünf generische, die sich gegenseitig im Weg stehen.

Fazit

Subagents in Claude Code sind ein präzises Werkzeug, kein Universalhammer. Ihre Stärken liegen in Kontext-Trennung, Rollen-Spezialisierung und echter Parallelisierung. Ihre Schwächen zeigen sich bei kleinen Aufgaben, geteiltem State und unklaren Verträgen. Wer die Heuristik im Kopf hat und ehrlich beantwortet, ob die jeweilige Aufgabe wirklich profitiert, vermeidet teure Multi-Agent-Theater und nutzt das Feature dort, wo es zählt.

Wer 2026 produktiv mit Claude Code arbeitet, sollte nicht fragen "Wie viele Subagents kann ich starten?" sondern "Welche eine Rolle wäre klar genug definiert, um sie auszulagern?". Das ist der Unterschied zwischen Agent-Hype und Agent-Handwerk.

Call-to-Action: Beim nächsten größeren Task: vor dem Start drei Minuten Planung. Aufgabe zerlegen, Output-Verträge skizzieren, dann entscheiden – nicht andersrum.