Erklärung zu Claude Code Subagenten: Was sie sind und wann man sie verwenden sollte.

Agenten sind keine versteckten Fähigkeiten

Die übliche erste Reaktion auf die Claude Code Agenten ist, dass es sich um Fähigkeiten mit zusätzlichen Schritten handelt – um „intelligente“ Fähigkeiten, die autonomer agieren, weil ihre Anweisungen anders formuliert sind. Dieses Bild ist falsch. Ein Agent ist tatsächlich ein Prompt, genauso wie eine Fähigkeit. Der entscheidende Unterschied liegt darin, wo er ausgeführt wird. Ein Agent wird nicht innerhalb des Hauptgesprächs ausgeführt. Er erhält sein eigenes Kontextfenster, seinen eigenen Systemprompt, Zugriff auf eigene Tools sowie eigene Berechtigungen, arbeitet im Hintergrund und liefert anschließend ein Ergebnis zurück.

Was folgt, beginnt bei den Grundlagen: Was diese Agenten sind, wie man einen erstellt und wann sich die Anstrengung lohnt. Es wird vorausgesetzt, dass Sie bereits Claude Code verwenden und die Funktion richtig verstehen möchten, bevor Sie irgendwelche Einstellungen ändern. Der Ablauf geht zunächst auf das Vokabularproblem ein, dann auf die Gründe für die Existenz von Subagenten, anschließend folgt ein erster benutzerdefinierter Subagent, danach wird erklärt, wie sich diese von Skills unterscheiden, es werden Arbeitspraktiken erläutert, ein Blick auf Agent-Teams geworfen und schließlich die Fälle aufgezeigt, in denen ein Agent die falsche Wahl ist.

Vier Bedeutungen von „Agent“

In Claude Code umfasst das Wort „Agent“ mindestens vier verschiedene Dinge, und deren Verwechslung erschwert das Verständnis der gesamten Funktion. Ein wenig Pedanterie lohnt sich hier, denn dadurch wird das Vokabular mit tatsächlich nutzbaren Ressourcen in Einklang gebracht.

1. Claude Code ist an sich eine agierende Umgebung. Anthropic präsentiert es als einen agierenden Codierungshilfsassistenten: Er verfügt über Werkzeuge und einen Ausführungslauf, kann mehrere Schritte planen und ausführen, ohne bei jedem Schritt angesprochen zu werden. Er ist bereits agierend, bevor man irgendetwas konfiguriert.
2. Subagenten sind die benutzerdefinierten, im Produkt enthaltenen Agent-Primitiven. Wenn ein Nutzer sagt, er baue einen Agenten in Claude Code, meint er fast immer Subagenten. Laut den offiziellen Dokumentationen handelt es sich dabei um spezialisierte Assistenten für bestimmte Arten von Aufgaben, wobei jeder Subagent ein eigenes Kontextfenster, einen benutzerdefinierten Systemprompt, definierten Werkzeugs Zugriff sowie unabhängige Berechtigungen besitzt.

Agent-Teams gehören zu einer anderen, mehr-Sitzung-fähigen Funktion. Laut der Dokumentation zu Teams ist die Grenze klar definiert: Subagenten befinden sich innerhalb einer Sitzung, während Teams über mehrere Sitzungen hinweg koordinieren. Ein Team ist eine Gruppe unabhängiger Claude Code-Instanzen, die über eine gemeinsame Aufgabenliste sowie direkte Nachrichten untereinander kommunizieren. Diese Funktion ist experimentell, standardmäßig deaktiviert und muss über eine Umgebungsflagge aktiviert werden. Es handelt sich dabei nicht um „mehr Subagenten“; sie befindet sich auf einer anderen Ebene der Architektur.

Das Claude Agent SDK ist eine vierte Ebene. Es stellt dieselben Werkzeuge sowie den Agent-Loop zur Verfügung, die Claude Code antreiben, und zwar als Python- sowie TypeScript-Bibliothek für Teams, die ihre eigenen Agent-Anwendungen außerhalb der CLI entwickeln.

Der Rest konzentriert sich auf den zweiten Punkt, die Unteragenten. Die Teams verdienen später eine eigene Behandlung; es ist angebracht, mit einer ausführlichen Erklärung eines Unteragenten zu beginnen.

Warum es Unteragenten gibt

Der ursächliche Grund liegt darin, dass Sprachmodelle nur einen begrenzten Kontext haben, wodurch früher oder später eine lange Sitzung die Grenze erreicht. Ohne Gegenmaßnahmen tritt dieses Problem immer wieder auf.

Anthropics Artikel über die Gestaltung des Kontexts beschreibt diese Disziplin als das Auswählen dessen, was in ein begrenztes Fenster aufgenommen wird. Jeder Toolaufruf, jede Dateiabfrage sowie jede unvollendete Analyse wird dem Kontext hinzugefügt und bleibt dort. Je länger eine Sitzung andauert, desto mehr Platz im „Fenster“ wird von Hilfsmitteln eingenommen, die zwar zur Erzielung einer Antwort beigetragen haben, danach aber nutzlos sind. Dieser Überfluss beeinträchtigt die Qualität – ein Phänomen, das oft als Zerfall im Kontext bezeichnet wird. Das Modell verfügt über weniger Arbeitsraum, und immer mehr irrelevante Inhalte konkurrieren um seine Aufmerksamkeit.

Subagenten sind eine Lösung. Die Übersicht zu Claude Code besagt ausdrücklich: Ein Subagent kann Dutzende von Dateien lesen oder umfangreiche Suchen durchführen, doch das Hauptgespräch erhält nur eine Zusammenfassung, sodass die Zwischenergebnisse den Hauptkontext nie verbrauchen. Das ist praktisch, wenn die Zwischenschritte nicht sichtbar bleiben müssen.

Ein konkreter Fall: Sie bitten Claude, herauszufinden, warum eine Testsuite fehlschlägt. Bei der Untersuchung in der Hauptsession müssen zwanzig Dateien gelesen, Fehlermuster gesucht, die Testkonfiguration überprüft und aktuelle Commit-Änderungen durchgescannt werden. All das landet schließlich im Kontext. Am Ende haben Sie mehrere Tausend Tokens für die Zwischenergebnisse aufgewendet, wobei fast nichts davon Ihre weiteren Schritte beeinflusst.

Ein Subagent formt das Problem um. Die Untersuchung findet in ihrem eigenen Kontextfenster und mit ihrem eigenen Tokenbudget statt, und das Ergebnis ist ein kurzer Bescheid in der Art von „Die Störung rührt von einer Umgebungsvariable her, die in der CI-Einrichtung fehlt; drei Tests sind betroffen, und hier ist die Reparatur“. Der Hauptthread nimmt niemals den Suchlärm auf.

Die Kontextisolation ist der Hauptgrund, dazu kommen drei weitere Gründe:

1. Spezialisierung. Ein Subagent verfügt über seine eigene Systemanweisung. Ein fokussierter Prüfer mit Anweisungen zu den Standards Ihres Teams wird stabiler sein als ein allgemeiner Assistent, der versucht, diese Standards neben allem anderen zu berücksichtigen, was er weiß.

Durchsetzung von Einschränkungen. Sie entscheiden genau, welche Tools ein Subagent verwenden darf. Ein nur zum Lesen geeigneter Forschungsagent, der weder Dateien schreiben noch Shell-Befehle ausführen kann, weist ein völlig anderes Risikoprofil auf als der Hauptassistent – diese Einschränkungen werden explizit deklariert und durchgesetzt, anstatt darauf zu hoffen.

Kostenkontrolle. Ein Subagent kann auf einem anderen Modell laufen. Leichte Aufgaben an Haiku zu senden, während die Hauptsession Sonnet verwendet, ist eine praktische Methode zur Kostenkontrolle – eine Methode, die viele Menschen erst nach einer unangenehmen Rechnung entdecken.

Erstellung des ersten benutzerdefinierten Subagents

Technisch gesehen ist ein Subagent nichts anderes als eine Markdown-Datei mit einem YAML-Header. Zwei Orte sind zulässig:

• .claude/agents/ innerhalb eines Projekts, für Agenten, die mit dieser Codebasis verbunden sind. Speichern Sie diese Dateien ab, damit das Team sie teilen und verbessern kann.

~/.claude/agents/ im Home-Verzeichnis, für persönliche Agenten, die in jedem Projekt verfügbar sind.

Das Frontmatter verdient Aufmerksamkeit

Menschen neigen dazu, das YAML-Frontmatter nur flüchtig zu überfliegen, doch Claude Code speichert es im Speicher der Hauptsession, um herauszufinden, wofür jeder Agent dient. Im Grunde handelt es sich dabei um eine Zusammenfassung des Agents. Zwei Felder sind erforderlich, während weitere optional sind. Ein einfaches Beispiel zeigt, wie sie zusammenpassen:

---
name: code-reviewer
description: Reviews code changes for quality, security, and best practices.
             Use proactively after any significant code change.
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, read the changed files and provide
specific, actionable feedback on code quality, security, and best practices.
Focus on what matters. Don't restate what the code does — say what's wrong
or good about it. Flag security issues first, then logic problems, then style.

Von Feld zu Feld:

• name ist die eindeutige Identifikationsnummer, in Kleinbuchstaben und ausschließlich mit Bindestrichen. Die Protokolle zeigen sie an, und Claude verwendet sie intern zur Benennung des Agents.
• description ist am wichtigsten. Claude schaut darauf, um zu entscheiden, ob eine Aufgabe zu diesem Agent gehört; daher sollte sie das Verhalten beschreiben: die Aufgabe, die der Agent erledigt, sowie die Situationen, in denen er eingesetzt werden soll. Der Hinweis „proaktiv verwenden“ ist eine dokumentierte Anweisung an Claude, den Agent ohne Wartezeit auf einen expliziten Auftrag zu aktivieren. Entfernen Sie diesen Satz, falls der Agent nur dann antworten soll, wenn direkt gefragt wird.

tools begrenzt, was der Agent erreichen kann. Der oben beschriebene Prüfer kann Dateien lesen und suchen, aber nicht bearbeiten, Shell-Befehle ausführen oder Netzwerkaufrufe tätigen. Das ist beabsichtigt: Ein nur zum Lesen zugelassener Prüfer kann nicht versehentlich etwas ändern, was er prüft. Die Dokumentation selbst rät dazu, dem Agenten nur die Tools zu gewähren, die er benötigt – aus Sicherheitsgründen und um sein Verhalten vorhersehbar zu halten.

model leitet den Agenten auf ein bestimmtes Modell um: sonnet, opus, haiku oder eine vollständige ID wie claude-opus-4-6. Ohne diesen Parameter verwendet der Agent inherit, was bedeutet, dass er das gleiche Modell wie die Hauptsession verwendet.

Alles, was unter dem Frontmatter steht, wird zum Systemprompt des Agents. Dieser Prompt zusammen mit dem Arbeitsverzeichnis ist alles, was der Agent von der Hauptsession erhält.

Die vollständige Auflistung der optionalen Felder zeigt, wie viel weiter angepasst werden kann: permissionMode, maxTurns, skills, mcpServers, effort, memory, hooks, disallowedTools, color und weitere.

Nachdem man einen Agenten gesehen hat, könnte man denken, er sei einer Fähigkeit ähnlich. Das stimmt teilweise, doch man versteht dabei nicht ganz den Kernpunkt, der in den folgenden Abschnitten erläutert wird.

Wo die Datei abgelegt wird

Speichern Sie das Beispiel als .claude/agents/code-reviewer.md im Projekt. Die resultierende Struktur sieht wie folgt aus:

your-project/
├── .claude/
│   ├── agents/
│   │   └── code-reviewer.md          ← your new agent file
│   ├── skills/
│   └── rules/
├── src/
├── tests/
├── README.md
└── package.json

Nach der Speicherung erkennt Claude den Agenten. Fordern Sie ihn auf, Codeänderungen zu überprüfen – er delegiert diese Aufgabe automatisch an code-reviewer, je besser die Anfrage zur Beschreibung passt. Für einen persönlichen Agenten, der in allen Projekten verwendet wird, verschieben Sie die Datei in ~/.claude/agents/code-reviewer.md. Format und Inhalt bleiben unverändert; nur der Speicherort ändert sich.

Agenten versus Fähigkeiten

Warum die beiden verwechselt werden

Drei Ähnlichkeiten erklären den größten Teil der Verwirrung:

1. Sowohl Agenten als auch Fähigkeiten werden über eine einfache Ordnerstruktur innerhalb von .claude/skills oder .claude/agents eingerichtet.
2. Sowohl Agenten als auch Fähigkeiten verwenden Frontmatter, wobei die Beschreibung in beiden der wichtigste Einstellungsparameter ist.
3. Sowohl Agenten als auch Fähigkeiten sind Bündel von Anweisungen, also Prompts. Eine Fähigkeit und ein Agent können genau dieselben Wörter enthalten.

So betrachtet wirken sie strukturell ähnlich.

Wo die Arbeit stattfindet

Doch ein sichtbarer, praktischer Unterschied trennt sie: Wo die Arbeit erledigt wird, also wo die Tokens ausgegeben werden. Das ist der einfachste Unterschied zu verstehen.

• Eine Fähigkeit wird in das laufende Gespräch eingebunden. Ihre Anweisungen, Vorlagen und Hilfdateien werden zum aktiven Kontext hinzugefügt, Claude arbeitet damit im selben Thread, und jeder Schritt wird im Hauptfenster angezeigt.
• Ein Subagent läuft separat in seinem eigenen Kontextfenster. Er erledigt die Arbeit, und das Hauptgespräch erhält ein Ergebnis.

Einstellmöglichkeiten

Zuvor gab es eine lange Liste von Feldern, die ein Agent in seinem Frontmatter einstellen kann. Im Gegensatz dazu akzeptieren Fähigkeiten eine viel kürzere Liste, die teilweise auch anders ist. Das deutet darauf hin, wie viel mehr Kontrolle den Agenten eingeräumt wird. Es ist daher nicht notwendig, alles in einen Agent umzuwandeln. Der Punkt ist vielmehr, dass das mentale Modell, das zur Gestaltung einer zuverlässigen Einrichtung verwendet wird, möglicherweise überdacht werden muss.

Eine Aufgabe, zwei Lösungen

Nehmen wir zum Beispiel den Wunsch, dass die Code-Review-Standards des Teams konsequent angewendet werden.

Falls Claude diese Standards während einer gesamten Sitzung kennen sollte, sie beim Schreiben von Code nutzen, sie in Ratschlägen zitieren und Verstöße sofort aufzeigen muss, eignet sich eine Fähigkeit dafür. Die Standards werden einmal geschrieben, und Claude zieht sie dann in den Kontext ein, wenn sie relevant werden, sodass alles, was in der Sitzung erledigt wird, auf ihnen beruhen kann.

Falls Sie stattdessen vierzig Dateien in einer einzigen Durchgangsüberprüfung bearbeitet haben möchten, ohne dass der Hauptkontext mit Dateiinhalten, Zwischenkommentaren und Suchergebnissen überflutet wird, dann eignet sich ein Subagent. Konfigurieren Sie einen Code-Review-Agenten, lassen Sie ihn in seinem eigenen Fenster arbeiten und erhalten Sie anschließend eine strukturierte Zusammenfassung. Sie könnten sogar vierzig Subagenten parallel starten, einen pro Datei. Der Hauptdialog erhält das Ergebnis ohne die dazugehörige Arbeitsprozessdokumentation.

Eine einzige Aussage fasst den Unterschied zusammen: Eine Fähigkeit verändert, was Claude weiß oder wie es einen Arbeitsablauf angeht, während ein Subagent bestimmt, wer die Arbeit ausführt, in welchem Kontext und mit welchen Werkzeugen.

Beständige Arbeitspraktiken

Betrachten Sie die Beschreibung als Routing-Schnittstelle

Dies bekommt weniger Aufmerksamkeit, als es verdient. Claude liest die Beschreibungen der Unteragenten, um zu entscheiden, wann delegiert werden soll, und liest den Textkörper vor der Entscheidung nicht. Alles, was Sie im Prompt-Textkörper einfügen, bleibt unsichtbar, bis der Unteragent bereits erstellt wurde. Die Beschreibung muss daher ausreichend Informationen enthalten, damit Claude weiß, wann der Agent benötigt wird.

• Verwenden Sie präzise, verhaltensbezogene Formulierungen.
• Geben Sie an, was der Agent tut und in welchen Situationen er gewählt werden sollte.
• Nennen Sie die Arten von Aufgaben, mit denen er gut umgehen kann, sowie gegebenenfalls die, die er meiden sollte.
• „Proaktiv nach Code-Änderungen einsetzen“ ist ein erprobtes Muster, das in der Dokumentation als Möglichkeit zur Förderung der Delegation ohne explizten Auftrag erwähnt wird. Verwenden Sie es nicht für Agenten, die nur dann ausgeführt werden sollen, wenn sie direkt aufgerufen werden.

Vermeiden Sie Beschreibungen, die die Identität des Agents angeben, wie zum Beispiel „ein erfahrener Reviewer mit zwanzig Jahren Erfahrung“. Das gehört in den Systemprompt. Die Beschreibung dient dem Routing-Modell, nicht dem Agenten.

Um den Unterschied zu erkennen, geben Sie eine vage Beschreibung („Hilft bei der Codequalität und Review-Aufgaben“) neben eine für das Routing bestimmte Beschreibung: „Überprüft die eingereichten Änderungen auf Sicherheitslücken, Logikfehler und Stilprobleme. Führt diese Prüfung proaktiv nach jeder größeren Änderung durch. Es schreibt niemals Code oder bearbeitet Dateien.“

Werkzeuge absichtlich einschränken

Ein Agent, der alle Werkzeuge aus der Hauptsession erbt, ist schwer zu verstehen, wenn etwas schiefgeht. Gewähren Sie nur das, was die Aufgabe benötigt.

• Ein Reviewer sollte nur lesen können – nichts darüber hinaus: kein Schreiben, kein Shell, kein Netzwerk.
• Forschungsarbeiten erfordern Such- und Abruffunktionen, ohne die Möglichkeit, Dateien zu bearbeiten.
• Das Ausführen von Tests setzt Zugriff auf Bash voraus, doch es gibt keinen Grund, die Webfunktionen zu nutzen.

Die Einschränkung der verfügbaren Tools trägt zur Sicherheit und Klarheit bei. Ein begrenztes Toolset macht das Verhalten vorhersehbar, und wenn der Agent versagt oder ungewöhnliche Ergebnisse liefert, beschleunigt eine kurze Liste möglicher Tools die Diagnose. Zudem werden Fehlermöglichkeiten begrenzt und erkennbar. Das Feld disallowedTools ermöglicht es einem Agenten, die Tools der Hauptsession zu übernehmen und anschließend bestimmte davon wegzulassen – was bei Anforderungen wie „alles außer Bash“ oder „alles außer Write“ geeignet ist.

Geben Sie jedem Agenten eine Aufgabe

In der Dokumentation zu den Subagenten steht ausdrücklich, dass jeder Subagent in einer einzigen Aufgabe hervorragend sein sollte. Eine Beschreibung wie „Überprüft Code, schreibt Tests, aktualisiert Dokumentation und kümmert sich um Bereitstellungsprüfungen“ fasst vier Aufgaben in ein Feld zusammen. Claude kann diese Aufgaben ungleichmäßig zuweisen, und der Systemprompt muss gleichzeitig mit vier Betriebsmodi umgehen.

Einschränken Sie den Umfang und erstellen Sie drei separate Dateien, wobei jede eine klare Beschreibung enthält. In der Datenwissenschaft könnten das ein Modellvalidierungsagent, ein Qualitätsprüfer für Daten und ein Überprüfer von Notebooks sein. In der Software wären es möglicherweise ein Code-Überprüfer, ein Testgenerator und ein Dokumentationsaktualisierer. Dieses Prinzip gilt in jedem Bereich. Jeder Agent erhält eine einzige Aufgabe, seine eigene Datei sowie eine Beschreibung, die eine eindeutige Zuweisung ermöglicht.

Nutzen Sie das Modellfeld zur Kostenkontrolle

Menschen, die noch nicht von ihrer Nutzungrechnung überrascht wurden, ignorieren dieses Feld in der Regel am meisten. Die Einstellung model: haiku bei leichten Agenten senkt die Kosten erheblich, wenn mehrere Agenten in einer Sitzung laufen. Die Einstellung model: opus bei einem Agenten, der über einen großen Kontext ausführlich nachdenken muss, rechtfertigt seinen Preis. Wenn man den Standardwert inherit beibehält, verwendet jeder Agent das Modell, das in der Hauptsession genutzt wird – oft das leistungsstärkste Modell – und zwar gleichmäßig für Aufgaben, die es nicht benötigen.

Was sich in der Community durchgesetzt hat

Die Sammlung der VoltAgent-Subagenten umfasst mehr als hundert spezialisierte Subagenten – darunter Sprachexperten, Sicherheitsprüfer, Debugger, Infrastrukturhelfer und Orchestrierer. Eine weitere solche Sammlung befindet sich im Everything Claude Code-Repository. Nur wenige Menschen bräuchten selbst ein Fünftel davon, daher ist die Anzahl nicht das Interessante – vielmehr die Struktur. Jeder Eintrag in diesen Sammlungen hat einen eng begrenzten Aufgabenbereich, sei es ein TypeScript-Spezialist, ein SQL-Experte, ein Kubernetes-Operator oder ein Sicherheitsauditor. Keiner versucht, mehr als ein Fachgebiet abzudecken. Das ist nach mehr als einem Jahr echter Nutzung die allgemeine Erkenntnis: Viele fokussierte Agenten sind besser als ein allgemein einsetzbarer Agent.

Ein kurzer Überblick über Agent-Teams

Agent-Teams sind zwar erwähnenswert, stellen aber eine andere Funktion als Subagenten dar.

Subagenten bleiben innerhalb einer Sitzung. Die Hauptinstanz von Claude Code erzeugt sie, sie arbeiten isoliert und liefern Ergebnisse zurück, während Sie als Orchestrator fungieren.

Agententeams sind unabhängige Claude Code-Sitzungen, die miteinander über eine gemeinsame Aufgabenliste sowie direkte Peer-Nachrichten kommunizieren. Jedes Teammitglied verfügt über sein eigenes Kontextfenster und Sitzungszustand und kann Aufgaben an andere zuweisen sowie sie erhalten.

In der Dokumentation zu den Teams wird aufgeführt, wo die zusätzlichen Mechanismen hilfreich sind: bei der Forschung oder Überprüfung, wenn mehrere Teammitglieder gemeinsam verschiedene Ansätze untersuchen; beim Debuggen durch konkurrierende Hypothesen, wobei die Teammitglieder gegenseitig Theorien überprüfen; sowie bei der Entwicklung neuer Module, wobei jedes Teammitglied für seinen eigenen Bestandteil verantwortlich ist und Kollisionen mit den anderen vermeidet.

Ihre Einrichtung ist nicht einfach, weshalb sie außerhalb des hier behandelten Rahmens liegen. Es gibt keinen Grund, aus Angst, etwas zu verpassen, sofort darauf umzusteigen. Teams führen zusätzliche Koordinationsaufwände mit sich und verbrauchen erheblich mehr Token, da jedes Teammitglied ein eigenes Kontextfenster hat, das separat abgerechnet wird. Sie sind experimentell und standardmäßig deaktiviert; sie werden nur über eine Umgebungsvariable aktiviert.

Eine praktische Regel: Solange Ihre Subagenten Ihnen Bericht erstatten und nicht miteinander kommunizieren müssen, sind Teams nicht notwendig. Wenn ein Subagent die Ergebnisse einem anderen übergeben muss oder dessen Schlussfolgerungen in Frage stellt, beginnt die Erweiterung, sich zu lohnen. Bis dahin reichen Subagenten aus.

Wenn ein Agent das falsche Werkzeug ist

Anthropics eigene Richtlinien zur Erstellung effektiver Agenten verdienen es, ernst genommen zu werden. Sie empfehlen, die einfachste funktionierende Lösung zu finden und Komplexität nur dann hinzuzufügen, wenn sie notwendig ist – was bedeuten kann, dass überhaupt keine agentbasierten Systeme entwickelt werden.

Das gilt direkt. Einige Situationen, in denen ein Subagent nur Verzögerungen verursacht und nichts bringt:

• Einzelfälle.** Ein Subagent erzeugt zusätzliche Aufwände bei der Erstellung: Benennung, Schreiben der Beschreibung, Auswahl von Tools, Testen, Wartung. Eine einmalige Aufgabe rechtfertigt das nicht, daher sollte stattdessen ein guter Prompt verwendet werden. Die Investition lohnt sich nur, wenn ein Arbeitsablauf häufig genug wiederholt wird, um die Definition aufrechtzuerhalten.

Fälle, in denen der Kontext kein Problem darstellt. Der Hauptgrund für die Verwendung eines Sub-Agenten besteht darin, den eigentlichen Kontext vor aufwendiger Arbeit zu schützen. Wenn die Aufgabe einfach ist, das Arbeitsfenster nicht überlastet wird und keine besonderen Tools oder Einschränkungen erforderlich sind, fügt ein Sub-Agent nur Überindirektheit hinzu. Einfaches Anfordern in der Hauptsession ist schneller, einfacher und leichter zu debuggen.

Die Monolithenfalle. Ein einzelner Agent, der versucht, Forschung, Implementierung, Überprüfung und Dokumentation abzudecken, ist nicht umfassend. Er ist nicht testbar und die Auswahl erfolgt inkonsistent. Eine präzisere, spezifischere Beschreibung führt zu weitaus besserer Konsistenz.

Das allgemeine Prinzip lautet, das einfachste Tool zu verwenden, das das eigentliche Problem löst. Fügen Sie Agenten hinzu, wenn es um Kontextisolation, spezialisierte Einschränkungen oder dedizierte Ausführung geht – nicht weil Agenten angeblich mächtiger sind.

Kurzfassung

Einfach ausgedrückt übernehmen Subagenten die Verwaltung des Kontexts und markieren eine Ausführungsgrenze, obwohl die meisten Menschen sie eher als Leistungssteigerung betrachten.

Ein sorgfältig konfigurierter Agent erfordert etwa eine Nachmittagsarbeit. Hier ist kein Orchestrierungssystem notwendig: eine präzise Beschreibung, ein eingeschränktes Werkzeugset sowie eine klare Aufgabe reichen aus. Die Komplexität kann von dort aus zunehmen, muss aber nicht so beginnen.

Es gibt einige Fragen, die man sich stellen sollte. Welche Aufgabe in Ihrem aktuellen Workflow würden Sie am liebsten an einen isolierten Agenten übertragen, und was hält Sie davon ab? Wenn Sie bereits Subagenten verwenden, welche war die erste Aufgabe, bei der die Isolation wirklich wichtig war – bei der eine Ausführung in der Hauptsession zu echten Problemen geführt hätte? Und wie handhaben Sie den Zugriff auf Werkzeuge: durch Einschränkung pro Agent oder durch Übernahme aus der Hauptsession mit anschließender Anpassung?