Claude Code Agent Teams: Wann auf mehrere Agenten umsteigen und wie

Eine gut koordinierte Gruppe von Agenten, die innerhalb des Claude Code Ökosystems miteinander kommunizieren können, ist bereits realisierbar, und eine fertige Version funktioniert durchaus gut. Allerdings ist es schwieriger, sie zum Laufen zu bringen, als es klingt, und viele Menschen gründen Agententeams, ohne die damit verbundenen Kompromisse abzuwägen. Agententeams scheinen der logische nächste Schritt zu sein, sobald Subagenten reibungslos arbeiten. Doch das ist nicht automatisch der Fall. Ein Team stellt eine Koordinationsschicht dar, die echte Tokenkosten verursacht, bekannte Fehlerquellen aufweist und nur eine begrenzte Anzahl von Problemen effektiv bewältigen kann.

Die weniger glanzvolle Lektion aus Monaten der tatsächlichen Nutzung mehrerer Agenten ist zugleich die nützlichste: Beginnen Sie mit einem gut konfigurierten Agenten, guten Werkzeugen und diszipliniertem Kontextmanagement. Fügen Sie nur dann weitere Agenten hinzu, wenn Sie einen konkreten Grund nennen können. Anthropics Anleitung zur Erstellung effektiver Agenten besagt dasselbe und rät Teams, nach der einfachsten praktikablen Lösung zu suchen und Komplexität nur dann hinzuzufügen, wenn sie erforderlich ist.

Im Folgenden wird beschrieben, wie man eine Entscheidung sorgfältig durchdenkt und was nach ihrer Getroffenheit zu tun ist. Dabei wird vorausgesetzt, dass Sie mit Subagenten vertraut sind, wie sie sich von Fähigkeiten unterscheiden und warum die Isolierung des Kontexts der Hauptgrund für deren Verwendung ist. Die offene Frage bleibt, ab wann ein einzelner Subagent, der Bericht erstattet, nicht mehr ausreicht und was an seiner Stelle entwickelt werden sollte.

Das Material behandelt diese Bereiche:

• Warum die meisten Teams derzeit noch nicht mehrere Agenten benötigen und der übliche Fehler, auf Teams zurückzugreifen, weil man sie für mächtiger hält.
• Vier konkrete Anzeichen dafür, dass ein Agent an Kapazität gescheitert ist.
• Vier Muster zur Kombination von Agenten in einer anbieterneutralen Taxonomie: Orchestrator, Pipeline, parallele Spezialisten und Schwarm.
• Der Anthropic-Stack für Agententeams, der das Stabile vom Experimentellen oder Nur-Vorab-Versionen-Trennt.
• Was Claude Code Agententeams sind und wie sie sich von Subagenten unterscheiden.
• Wie Agenten kommunizieren: drei Formen, vier Zeitmuster und was zwischen ihnen übertragen werden sollte.
• Acht Ausfallmöglichkeiten mit praktischen Gegenmaßnahmen.
• Ein Entscheidungskontext für native, selbst durchgeführte oder hybride Orchestrierung.

Die meisten Teams benötigen nicht mehr als einen Agenten

Viele Menschen, die nach Agententeams suchen, lösen das falsche Problem. Die übliche Argumentation lautet, dass Subagenten funktioniert haben, das System immer komplizierter wird und Teams der nächste Schritt seien. Diese Logik verwechselt Fähigkeit mit Komplexität. Ein Team macht das System nicht fähiger; es macht es nur dezentraler, und Dezentralisierung ist ein Kostenfaktor statt eine Verbesserung.

Anthropics Beitrag zur Erstellung effektiver Agenten erläutert die wirtschaftlichen Aspekte. Arbeitsabläufe, die keine Agenten nutzen, sind vorhersehbarer, günstiger und einfacher zu debuggen. Der Rat lässt sich darauf reduzieren: Wenn eine gewöhnliche Funktion die Aufgabe erledigen kann, sollte man diese verwenden anstatt ein Gremium aus Wahrscheinlichkeitsverteilungen zusammenzustellen. Dieser Punkt entgeht Menschen, die noch nicht verstanden haben, dass große Sprachmodelle probabilistisch sind, leicht. Selbst eine ausdrückliche Anweisung wird möglicherweise nicht korrekt befolgt. Jeder hinzugefügte Agent ist ein weiterer Komponente, der versagen, Halluzinationen erzeugen oder Ausgaben liefern kann, die vom nächsten Agenten falsch interpretiert werden – dadurch steigen im großen Maßstab die Fehlerquoten weiter an.

Die Grenze für einen einzelnen Agenten ist höher, als man annimmt. Ein einzelner Agent, dem geeignete Werkzeuge zur Verfügung gestellt werden, der klare Systemanweisungen erhält, schwere Aufgaben sorgfältig an Unteragenten delegiert und den Kontext gut verwalten kann, ist in der Lage, erstaunlich viel zu bewältigen. Die Grenze wird erreicht, wenn mindestens eine von vier Bedingungen zutrifft:

1. Die Aufgabe ist zu umfangreich für ein einziges Kontextfenster – selbst bei Delegation an Unteragenten.
2. Unterschiedliche Teile erfordern tatsächlich unterschiedliche Spezialisierungen, was unterschiedlichen Werkzeugszenarien sowie Verhaltensbeschränkungen bedingt, und nicht nur unterschiedliche Anweisungen.
3. Ein Teil der Arbeit kann parallel durchgeführt werden, wobei die verstrichene Zeit eine Rolle spielt.
4. Die Qualität der Ausgabe benötigt eine unabhängige Bewertung, beispielsweise durch einen zweiten Agenten, der die Überlegungen des ersten nicht gesehen hat.

Niemand von diesen ist eine Aussage über die Fähigkeit. Sie beziehen sich alle auf die Architektur. Wenn ein Mechanismus angewandt wird, sind zusätzliche Agenten gerechtfertigt. Wenn keiner angewandt wird, verursachen sie nur zusätzlichen Widerstand, und wenn man keinen spezifischen Mechanismus nennen kann, bleibt der Weg mit einem einzigen Agenten weiterhin offen.

Die vier Auslöser mit Beispielen

Kontextisolierung. Angenommen, die Aufgabe besteht darin, Dutzende von Dateien zu lesen, umfangreiche Suchen durchzuführen und große Zwischenergebnisse zu speichern, wovon keines in der Hauptsession verbleiben muss. Dafür sorgt ein Subagent. Doch wenn die Untersuchung so umfangreich ist, dass selbst der Kontext eines Subagents ausgelastet wird, oder wenn die Aufgabe in unabhängige, parallele Untersuchungen aufgeteilt wird, sind mehrere Agenten notwendig. Dies ist der häufigste legitime Auslöser.

Spezialisierung. Die Aufgabe erfordert mehr als nur getrennte Anweisungen; sie benötigt unterschiedlichen Zugriff auf Werkzeuge sowie andere verhaltensbezogene Einschränkungen. Ein Code-Reviewer, der keine Dateien schreiben oder Shell-Befehle ausführen kann, weist ein völlig anderes Risikoprofil auf als ein Code-Generator. Dennoch können diese Unterschiede oft in separate Subagenten kodiert werden, wobei jeder Subagent seine eigene Systemanweisung sowie eine eingeschränkte Liste an Werkzeugen besitzt. Daher sollte allein die Spezialisierung nicht der Grund sein, auf Team-Ebene zu wechseln. In der Dokumentation zu Agent-Teams heißt es selbst, dass Subagenten in solchen Fällen besonders nützlich sind: isolierte Kontexte, Zusammenfassungen für den Aufrufer sowie an die Aufgabe angepasste Anweisungen.

Parallelarbeit. Die Aufgabe wird in unabhängige Teilaufgaben aufgeteilt, die keinen gemeinsamen, veränderbaren Zustand teilen: Drei Agenten untersuchen gleichzeitig verschiedene Aspekte eines Fehlers in einer Codebasis, oder vier Agenten prüfen jeweils ein anderes Kapitel eines Dokuments. In solchen Fällen bringen Mehr-Agentensysteme tatsächliche Zeitersparnisse, da die Agenten gleichzeitig arbeiten. Der Preis dafür sind mehr Gesamt-Token, wodurch der Austausch nur dann sinnvoll ist, wenn die verstrichene Zeit wichtiger ist als die Kosten.

Unabhängige Kritik. Die Ergebnisse benötigen eine zweite Meinung, die nicht von der Argumentation der ersten beeinflusst ist. Stellen Sie sich einen Bewertungsexperten vor, der nur das endgültige Ergebnis liest und nicht die dahinterliegenden Überlegungen, oder einen „Red-Team“-Agenten, der nach Fehlern sucht anstatt Behauptungen zu überprüfen. Das ist die Idee hinter Anthropics Mehr-Agenten-Forschungssystem, bei dem parallele Unteragenten verschiedene Aspekte untersuchen und ein Leitagent unabhängig synthetisiert.

Wenn eine dieser Aussagen eindeutig wahr ist und man erkennen kann, welche, lohnt sich das Hinzufügen weiterer Agenten durch den entstehenden Nutzen.

Vier Möglichkeiten, Agenten zu kombinieren

Nehmen wir an, die Entscheidung ist gefallen. Die Recherche zeigt schnell ein Durcheinander auf, denn die Grenzforschungslabore haben jeweils unterschiedliche Mehr-Agenten-Muster entwickelt, obwohl es einige gemeinsame Elemente gibt. Was folgt, ist eine synthetisierte Taxonomie, die aus Anthropics Arbeitsablaufdokumentation sowie der Produktionserfahrung seines Ingenieurteams stammt. Es handelt sich dabei nicht um eine offizielle Klassifizierung von Anthropic, sondern um eine analytische Zusammenfassung, die auf das zurückverweist, was diese Quellen beschreiben.

Sequenzieller Pipeline

Agenten oder Phasen laufen in einer festgelegten Reihenfolge ab, wobei spätere Phasen die Ausgaben früherer Phasen nutzen. Von den vier Varianten ist diese am einfachsten für Ingenieure zu erklären, da sie wie herkömmliche Software aussieht: zunächst Forschung dann Synthese, anschließend Entwurf dann Kritik, danach Extraktion dann Validierung.

Ihre Stärke liegen in expliziten Verträgen zwischen den Phasen. Ihre Schwäche sind kaskadierende Fehler, da ein Extraktionsfehler in der ersten Phase dazu führen kann, dass spätere Phasen mit großen Kosten falsch arbeiten. Validierungsmechanismen zwischen den Phasen sind zwingend erforderlich, da sie verhindern, dass der Prozess in die falsche Richtung weiterläuft. JSON-Vertragsschemas sowie andere Artefakte, die die Abhängigkeiten während des Ablaufs beibehalten, bilden die besten Validierungsmechanismen.

Zentrales Orchester oder Planer-Executor

Ein leitender Agent teilt die Aufgabe auf, delegiert sie an Arbeiter und synthetisiert die Ergebnisse. Die Arbeiter koordinieren nicht miteinander; sie berichten stattdessen an den Orchestrator. Dies ist die gebräuchlichste und nützlichste Standardkonfiguration. Verwenden Sie sie, wenn die Struktur der Unteraufgaben im Voraus nicht bekannt ist, aber eine klare Oberverantwortung wichtig ist. Die Research-Funktion von Anthropic folgt genau diesem Prinzip: Ein leitender Agent analysiert die Anfrage, startet spezialisierte Unteragente parallel und fügt später deren Erkenntnisse zusammen.

Verwenden Sie sie nicht, wenn der Workflow bereits so gut strukturiert ist, dass er per Skript abgewickelt werden kann; in solchen Fällen ist ein Pipeline-Ansatz einfacher und vorhersehbarer.

Ihre typische Schwäche ist der Orchestrator-Fehler: Ein leitender Agent, dessen Delegierungsanweisungen vage sind, veranlasst die Mitarbeiter dazu, dieselben Suchen wiederholt durchzuführen, Grenzen zu überschreiten oder Ergebnisse zu erzielen, die nicht zusammenpassen. Die Lösung besteht darin, jedem Mitarbeiter ein klares Ziel, einen erwarteten Ausgabeformat, Anleitungen zu den Quellen sowie klare Aufgabengrenzen zu geben.

Parallel arbeitende Spezialisten, Diskussionen und Red-Team-Ansätze

Hier übernehmen mehrere Agenten gleichzeitig dieselbe Aufgabe oder benachbarte Teilaufgaben, wobei ihre Ergebnisse anschließend abgestimmt, kritisiert oder zusammengefasst werden. Dies eignet sich für Fälle, in denen Widerstandsfähigkeit wichtiger ist als Ordnung: konkurrierende Erklärungen für einen Fehler, gegenseitige Überprüfung von Entscheidungsgrundlagen oder Sicherheitsbewertungen aus verschiedenen Perspektiven.

Die Kosten sind offensichtlich. Mehr Agenten bedeuten deutlich mehr Token, mehr Aggregationsarbeit sowie das Risiko einer falschen Zuversicht durch Konsens. Berichten zufolge musste Anthropics Forschungssystem Aufwandsbudgets sowie strengere Delegationsregeln einführen, um zu verhindern, dass die Mitarbeiter ohne Disziplin arbeiteten. Wenden Sie dieses Muster nur an, wenn der Anwendungsbereich es tatsächlich erfordert.

Schwarm oder dezentraler gemeinsamer Kontext

Koordination entsteht durch einen gemeinsamen Zustand, gemeinsame Nachrichtenstränge oder Veränderungen in der Umgebung – anstatt durch einen strengen Leiter. Hier beginnen mehr-Agenten-Systeme, zu verteilten Systemen zu werden, mit all der damit verbundenen Komplexität: unklarer Eigentumsanspruch, Rennbedingungen beim gemeinsamen Zustand und schwieriges Debuggen. Dies eignet sich für wirklich offene Probleme, bei denen die Agenten über Sitzungs- oder Laufzeitgrenzen hinweg miteinander arbeiten müssen. Vermeiden Sie es, wenn eine einfache Rechenschaftspflicht oder strenge Einhaltung erforderlich ist.

Für die meisten Anwender decken die ersten beiden Muster fast alles ab.

Was Anthropic heute anbietet

Bevor man eigene Lösungen entwickelt, lohnt es sich, zu prüfen, was Anthropic bereits bereitstellt und welche Erkenntnisse seine Konzepte liefern. Es existieren mehrere Ansätze für agierendes Arbeiten, und diese sind nicht austauschbar. Stellen Sie sich eine Leiter vor, die von der direkten Steuerung bis zur gehosteten Verwaltung reicht. Das untenstehende Bild zeigt einen Zustand aus etwa April 2026 – diese Produkte ändern sich schnell.

1. Messages API. Sie haben die volle Kontrolle über den Prozess. Es gibt zwar Werkzeuge, doch Sie schreiben die Ausführungslogik selbst, und es gibt keine eingebaute Unterstützung für mehrere Agenten. Es handelt sich um die flexibelste Stufe – aber auch um die arbeitsintensivste.

Claude Agent SDK. Der Agent-Loop, die Tools, die Handhabung des Kontexts, Subagenten, Hooks sowie die Kostenverfolgung stammen von Anthropic, laufen aber auf der von Ihnen betriebenen Infrastruktur. Subagenten sind integriert, und alles, was über mehrere Agenten hinausgeht, ist größtenteils Ihre eigene Konstruktion. Die Authentifizierung erfolgt über Bedrock, Vertex AI und Azure Foundry, wodurch dies die am meisten portablen Lösung darstellt.

Claude Managed Agents. Anthropic betreibt den Laufzeitumfeld für Sie: Container, Komprimierung, Prompt-Caching, Ereignishistorie, stateful Sessions sowie eine Reihe von integrierten Tools. Der Einsatz mit einem einzelnen Agenten ist bereits ausgereift, während mehrere-Agenten-Sessions sich in einer separaten, vorab zugänglichen Vorabversion befinden.

Gemanagte Multi-Agenten. Eine Forschungsvorabversion mit eingeschränktem Zugang und einer bedeutenden Einschränkung: Das Design unterstützt nur ein Koordinatorebene. Ein Koordinator kann andere Agenten aufrufen, doch die von ihm aufgerufenen Agenten können keine weiteren Agenten aufrufen. Das ist Multi-Agenten-Orchestrierung, allerdings noch keine allgemeine rekursive Gesellschaft von Agenten.

Claude Code-Subagenten. Isolierte Arbeitskontexte innerhalb einer Hauptsession, die ihre Ergebnisse zurückmelden. Eine offizielle Funktion, aber keine Peer-to-Peer-Teams.

Claude Code-Agententeams. Stand dem Zeitpunkt des Snapshots im April 2026 handelt es sich um eine experimentelle Funktion, die standardmäßig deaktiviert ist und über eine spezifische Umgebungsvariable aktiviert werden muss. Zu den bekannten Einschränkungen gehören das Verhalten bei Wiederaufnahme der Session, Randfälle in der Aufgabenkoordination sowie wiederbelebte Sessions, die auf Teammitglieder verweisen, die nicht mehr existieren.

In der Praxis gilt die Aussage „Claude unterstützt Agententeams“, während „Claude bietet produktionstaugliche, allgemein einsetzbare Multi-Agent-Orchestrierung auf jeder Plattform“ nicht zutrifft.

Claude Code Agententeams in der Praxis

Ein kurzer Überblick zum Unterschied:

• Subagenten laufen innerhalb einer einzigen Hauptsession. Die Hauptinstanz von Claude Code erzeugt sie; jeder Subagent arbeitet für sich in seinem eigenen Kontextfenster und sendet die Ergebnisse zurück. Sie sind dafür verantwortlich, die Orchestrierung vorzunehmen, wobei die Hauptsession die zur Erzeugung eines Ergebnisses durchgeführte Arbeit niemals aufnimmt.

Agent-Teams sind separate Claude Code-Sitzungen, die miteinander kommunizieren. Jeder Teammitglied hat sein eigenes Kontextfenster und Sitzungszustand, sowie eine gemeinsame Aufgabenliste und einen Posteingang für direkte Nachrichten. Teammitglieder können Aufgaben gegenseitig weiterleiten und sich koordinieren, ohne darauf warten zu müssen, dass der Leiter jede Anweisung weitergibt. Der Leiter legt die Richtung fest, und die Teammitglieder können darauf reagieren und untereinander kommunizieren.

Die Einrichtung

1. Die Teamkonfiguration befindet sich bei ~/.claude/teams/{name}/config.json.
2. Die gemeinsame Aufgabenliste liegt bei ~/.claude/tasks/{name}/.
3. Teammitglieder werden in wiederverwendbaren Agenten-Dateien definiert, also im Grunde Subagenten mit zugewiesenen Rollen.
4. Hooks können als Qualitätskontrollen zwischen den Aufgabentransitionen dienen.

Zwei architektonische Aspekte sind für das Design wichtig. Erstens können Subagenten ihr eigenes automatisches Gedächtnis beibehalten. Das unterstützt die Spezialisierung, doch sobald die Arbeit auf mehrere Agenten mit separaten Gedächtnissen aufgeteilt wird, muss eine architektonische Entscheidung getroffen werden darüber, welche Kenntnisse lokal bleiben, welche geteilt werden und welche zusammengefasst zurückgegeben werden. Das ist eine Frage des Systemdesigns.

Zweitens macht die Dokumentation deutlich, in welchen Fällen Teams schlechter abschneiden als Subagenten: bei sequentiellen Aufgaben, Änderungen am selben Datei und Arbeiten mit vielen Abhängigkeiten zwischen den Schritten. Wenn Agenten denselben Output nacheinander weitergeben müssen und nicht parallel arbeiten können, sind Subagenten in einer sequentiellen Pipeline einfacher und vorhersehbarer.

Da Teams zu diesem Zeitpunkt noch experimentell waren und standardmäßig deaktiviert waren, sollten sie nur aus einem der oben genannten klaren Gründe aktiviert werden – und man sollte mit Unvollkommenheiten rechnen.

Wie Agenten miteinander kommunizieren

Die Kommunikation zwischen Agenten wird oft als ein Problem der Anweisungsgabe betrachtet. In großem Maßstab handelt es sich dabei um ein Systemproblem. Es gibt drei Hauptformen.

1. Mitteilungen in Alltagssprache. Die offensichtlichste Form, die jedoch in großem Maßstab am wenigsten zuverlässig ist. Claude Code-Teammitglieder kommunizieren direkt über die Postfächer miteinander. Das ist flexibel, doch natürliche Sprache ist weniger präzise als strukturierte Aufrufe, was mehr Raum für Fehldeutungen zwischen Agenten lässt.
2. Strukturierte Aufrufe. Tool-Definitionen nach JSON Schema sowie strenge Anwendung dieser Tools. Anthropics Tool-Definitionen garantieren Argumente, die dem Schema entsprechen. Diese Schicht macht die Kommunikation zwischen Agenten und Tools zuverlässig, und derselbe Mechanismus sorgt dafür, dass Anrufe zwischen Agenten präziser werden, wenn sie als Tool-Aufrufe statt als freie Nachrichten modelliert werden.

Gemeinsamer Zustand oder Artefakte. Die am meisten unterschätzte Form. In den Forschungsberichten von Anthropic zu mehreren Agenten wird empfohlen, dass Subagenten ihre Ausgaben in ein Dateisystem oder ein externes System schreiben und leichte Referenzen zurückgeben, anstatt alles über den Kontext des führenden Agenten zu leiten. Der Grund ist einfach: Eine Datei kann direkt überprüft, versioniert und inspiziert werden, während eine Nachricht, die eine Datei zusammenfasst, keines dieser Merkmale aufweisen kann.

Die Zeitgestaltung ist genauso wichtig wie das Format. Es gibt vier Muster:

• Synchrone Aufrufe. Ein Manager ruft einen Spezialisten an, wartet und setzt dann fort. Das ist leicht nachvollziehbar, stellt aber ein potenzielles Engpass dar. Laut Angaben des Forschungsteams von Anthropic wurde die synchrone Ausführung durch langsame Arbeiter blockiert, weshalb eine Steuerung während des Vorgangs ausgeschlossen wurde.

Sequenzielle Übergabe. Die Verantwortung wechselt von einem Agenten zum nächsten – einer erzeugt ein Ergebnis und der nächste übernimmt es. OpenAI zieht eine klare Linie zwischen zwei Ansätzen: Bei einer Übergabe erhält der Spezialist die Verantwortung für den weiteren Ablauf, während ein als Tool genutzter Agent den Manager weiterhin für die Steuerung zuständig macht. Wer verantwortlich ist, hängt davon ab, welcher Ansatz verwendet wird.

Ereignisgesteuert oder strömungsbasiert. Agenten reagieren auf Ereignisse anstelle von synchronen Aufrufen. Dies eignet sich besser für lang andauernde Aufgaben, ist jedoch schwieriger zu debuggen und zu testen; manchmal helfen Hilfsmechanismen dabei.

Shared-State Polling. Nicht besonders attraktiv, doch oft die zuverlässigste Option. Die Agenten prüfen in einer gemeinsam genutzten Datei oder einem Datenspeicher den Fortschritt, speichern ihre Aktualisierungen dort und gehen weiter. Anthropics langjährige Arbeit mit Harness sorgt dafür, dass JSON-Featurelisten, Fortschrittsdateien sowie Git-Commits als zuverlässiger gemeinsamer Zustand erhalten bleiben, wobei menschliche Überprüfpunkte nahtlos integriert werden können.

Wie die Agenten miteinander kommunizieren, bestimmt die Zuverlässigkeit des gesamten Systems. Die Übermittlung der gesamten Konversationshistorie maximiert die Kontinuität, erhöht aber Kosten und Latenz linear. Eine komprimierte Zusammenfassung ist oft besser – und genau das tun die Subagenten von Claude Code von vornherein. Die Übermittlung auf die Aufgabe zugeschnittener Artefakte wie strukturierte Ausgabedateien, Code-Änderungen, JSON-Listen mit Funktionen sowie gespeicherte Berichte stellt in der Regel den praktischen Kompromiss dar. Der Empfänger-Agent kann das Artefakt direkt überprüfen, anstatt sich auf eine Zusammenfassung zu verlassen, wodurch das System in einer Weise auditiert werden kann, die konversationelle Übertragungen nicht erreichen.

Was übermittelt wird, bestimmt auch, wie und wann es übermittelt wird – was den zentralen Punkt unterstreicht: Das Aufbauen von Agententeams ist ein Problem des Systemsdesigns, und solche Probleme sind schwieriger zu lösen als ein linear organisiertes Ablaufschema.

Acht Gründe, warum Agententeams scheitern

Die meisten Multi-Agent-Tutorials überspringen diesen Teil. Anthropics Ingenieurnotizen sind eine gute Quelle. Sie lesen weniger wie ein Forschungspapier und eher wie das Tagebuch eines Teams, das Schritt für Schritt erkannte, dass zusätzliche Agenten die Verwaltungsprobleme vermehren. Daraus lassen sich acht Lektionen ziehen.

• Koordinationsverschiebungen. Unklare Delegationen führen dazu, dass die Mitarbeiter dieselben Suchvorgänge wiederholen, Grenzen überschreiten oder Ergebnisse liefern, die nicht zusammenpassen. In einem Forschungspost von Anthropic wurde dies direkt festgestellt, und die Lösung bestand darin, dem Orchesterer beizubringen, für jeden Mitarbeiter das Ziel, das Ausgabeformat, die Richtlinien sowie den Umfang klar zu definieren. Wo keine Verantwortlichkeiten festgelegt sind, improvisieren die Agenten – und das oft schlecht, genauso wie Menschen es tun.

Halluziniertes Eigentumsgefühl. Agent A glaubt, Agent B habe etwas überprüft, was in Wirklichkeit niemand überprüft hat. Die Lösung sind explizite Abschlussmerkmale: Aufgabenhaken, End-to-End-Überprüfungen, bevor etwas als abgeschlossen markiert wird, sowie dauerhafte Zustandsdateien, die aufzeichnen, was tatsächlich bestätigt wurde – und nicht nur, was angenommen wurde.

Schweigende Zwischenfehler. Für das Debuggen war eine vollständige Überwachung in der Produktumgebung erforderlich, da nichts darauf hindeutete, ob ein Fehler auf schlechte Suchanfragen, schwache Quellen oder einen Fehler in den Tools zurückzuführen war. Der oberste Sessions stream bietet nur eine gekürzte Ansicht; um zu verstehen, was ein aufgerufener Agent tatsächlich getan hat, muss man die Historie auf Worker-Ebene prüfen. Implementieren Sie die Überwachung bereits zu Beginn, lange bevor das erste Problem in der Produktumgebung auftritt.

Kontextüberlastung und Speicherverschmutzung. Das Kontextfenster ist eine begrenzte Ressource, und gemeinsam genutzter Speicher, der veraltet oder unübersichtlich wird, verschlechtert das gesamte System. Jeder Toolaufruf, jede Dateiabfrage sowie jede teilweise Analyse landen im Kontext und bleiben dort – bei einem Team verstärkt sich dieses Problem noch. Zu den bekannten Abhilfemethoden gehören das Zusammenfassen abgeschlossener Phasen, die Isolierung aufwändiger Aufgaben in Unteragenten sowie der Einsatz kleinerer, gezielter Speicherdateien anstelle großer gemeinsamer Dateien.

Schema-Unübereinstimmungen und brüchige Prompt-Vereinbarungen. Agenten, die in natürlicher Sprache Daten austauschen, sind anfällig für Fehler. Der zweite Agent interpretiert die Zusammenfassung des ersten falsch, wodurch sich der Fehler stillschweigend ausbreitet. Eine strenge Nutzung von Tools ist notwendig, da unstrikte Aufrufe inkompatible Typen oder fehlende Felder erzeugen können. Enge Vereinbarungen zwischen Agenten und Tools verringern die Möglichkeiten, dass solche Probleme auftreten – ein ironischer Einsatz herkömmlicher ingenieurtechnischer Vereinbarungen in einem KI-Umfeld.

Falsche Nutzung von Tools und Sicherheitsmängel. Mehr offene Umgebungen bedeuten mehr Eingangspunkte für Prompt-Injection-Angriffe, und mehr Tools bieten Angreifern weitere Möglichkeiten, sobald sie sich im System befinden. Anthropics Forschung zu vertrauenswürdigen Agenten bezeichnet Prompt-Injection als Cyberangriffsvektor und nicht als Sonderfall. Laut METRs Red-Teaming-Aktionen zur Überprüfung von Anthropics internem Agentenmonitoring wurden sogar in einem gut ausgestatteten internen System neue Schwachstellen entdeckt. Gegenmaßnahmen sind eingeschränkte Berechtigungen, Tools, die auf die Anforderungen der Aufgabe beschränkt sind, sowie menschliche Genehmigung für entscheidende Aktionen.

Kostenexplosion und Latenzsteigerung. Teams verwenden weitaus mehr Tokens als in einer einzigen Sitzung. Parallelisierung kann die Gesamtlaufzeit verkürzen, erhöht aber den gesamten Tokenverbrauch anstelle ihn zu senken, da die Beschleunigung dadurch entsteht, dass gleichzeitig mehr strukturierte Anstrengungen unternommen werden. Sofern die Aufgabe diesen Aufwand nicht rechtfertigt, ist ein sorgfältig konstruierter einzelner Agent schneller und günstiger.

Bewertungsschwierigkeit. Ganz unterschiedliche interne Abläufe können alle zu einem Ergebnis führen, das erfolgreich erscheint. Wenn die einzige Prüfung darin besteht, ob der endgültige Text plausibel klingt, wird das System eher bewundert als wirklich bewertet. Anthropics Empfehlung ist, zu überprüfen, ob der korrekte Endzustand erreicht wurde – nicht, ob der vorgesehene Prozess befolgt wurde. Der Prozess variiert, und das Ergebnis ist das, was man überprüfen kann.

Eingebettet, selbst erstellt oder hybrid

Daher die große Frage: Soll man die Orchestrierung selbst entwickeln oder eine fertige Lösung verwenden? Es handelt sich um ein architektonisches Abwägungsproblem zwischen drei Optionen – es gibt sicherlich noch mehr –, daher sollten Sie dies als eine subjektive Sichtweise betrachten.

1. Eingebettete, verwaltete Lösungen bedeuten, dass Anthropic den Laufzeitumfeld und die Koordinierungsmechanismen kontrolliert: Claude Managed Agents sowie, enger gefasst, Managed Agents für mehrere Agenten oder Claude Code Agent-Teams. Die Vorteile sind geringerer Engineering-Aufwand sowie eine gehostete Infrastruktur, die nicht selbst gewartet werden muss. Die Nachteile sind eingeschränkte Portabilität (Managed Agents sind nur über die direkte Claude API erreichbar), ein noch experimenteller oder in einer begrenzten Vorabversion verfügbarer Mehr-Agenten-Mechanismus sowie Abhängigkeit von Drittanbietern. Wählen Sie diese Option, wenn die Infrastruktur ein Problem darstellt und anthropic-spezifische Einschränkungen tolerierbar sind.

DIY bedeutet, dass Sie die Orchestrierungslogik sowie in der Regel auch den Laufzeitmechanismus selbst kontrollieren, wobei die Messages API das reinste Beispiel dafür ist. Sie bietet den größten Kontrollumfang, kommt aber mit den höchsten ingenieurtechnischen Kosten. Wählen Sie diese Variante, wenn Ihre Geschäftslogik außergewöhnlich ist, die Konformitätsregeln streng sind, die Routen auf Ihr spezifisches Gebiet zugeschnitten sind oder die Portierbarkeit beim Anbieter eine echte Notwendigkeit darstellt.

Hybrid bedeutet, dass Anthropic den Loop und die Tools bereitstellt, während Sie das System entwerfen – das Claude Agent SDK ist das deutlichste Beispiel dafür. Sie erhalten Anthropics Agent-Loop, Kontextverwaltung, Hooks, Subagenten sowie Funktionen zur Überwachbarkeit, behalten aber weiterhin die Kontrolle über das höherwertige Design. Die Authentifizierung über Bedrock, Vertex AI und Azure Foundry bietet einen erheblichen Vorteil in Bezug auf die Portabilität im Vergleich zu native, verwalteten Lösungen. Wählen Sie diesen Ansatz, wenn Sie Anthropics Loop nutzen möchten, ohne die gesamte Architektur an Anthropics derzeitige Sichtweise davon zu binden, wie mehrere Agenten zusammenarbeiten sollten.

Kurz gesagt: native, verwaltete Lösungen, wenn die Infrastruktur das Problem ist; DIY-Lösungen, wenn Topologie und Richtlinien das Problem darstellen – und hybride Lösungen, wenn Sie Anthropics Grundbausteine nutzen möchten, aber Raum für eigene architektonische Entscheidungen benötigen.

Die Architekturfrage

Der gängige Ansatz, den die meisten Menschen bei Agententeams verfolgen, basiert auf der Fähigkeit – mit der Annahme, dass mehr Agenten mehr Fähigkeiten bedeuten. Der hilfreichere Ansatz ist die Architektur: Welches Problem löst ein zusätzlicher Agent und was kostet das?

Subagenten entscheiden, wer die Arbeit in welchem Kontext und mit welchen Werkzeugen erledigt. Agententeams fügen eine Koordinationsschicht darauf hinzu, die einen gemeinsamen Aufgabenzustand, Teammitglieder, die direkt miteinander kommunizieren, sowie parallele Abläufe bietet, die sich selbst organisieren. Eine solche Schicht lohnt sich nur bei Problemen, die sie tatsächlich erfordern.

Ein gut konfiguriertes Team aus einem Agenten reicht für einen echten Anwendungsfall aus, um eine Woche Arbeit zu bewältigen. Die Komplexität kann von dort aus zunehmen, muss aber nicht dort beginnen. Das oben genannte Versagenskatalog und die Kommunikationsmuster dienen als Referenzmaterial, nicht als Plan, um alles auf einmal zu erstellen. Beginnen Sie damit, herauszufinden, welcher der vier Auslöser tatsächlich zutrifft; falls keiner zutrifft, ist der Weg mit einem einzigen Agenten weiterhin der richtige.