Agenten als Teamkollegen: Hierarchie, Rollen und was 2025 uns gelehrt hat

Das Jahr, in dem Multi-Agent ernst wurde

Während des größten Teils von 2024 war die Diskussion über Multi-Agenten reine Stimmungsmache. Leute posteten Demos von "Agenten-Schwärmen", die Hochzeiten planten oder fiktive Firmen leiteten, und fast nichts davon überstand den Kontakt mit der Produktion. Das Versprechen war riesig. Die Evidenz war dünn.

Das änderte sich im April 2025, als Anthropic den technischen Bericht zu seinem Multi-Agenten-Forschungssystem veröffentlichte. Die Architektur war in ihrer Form einfach: Ein Lead-Agent auf Basis von Claude Opus 4 fungiert als Orchestrator, zerlegt eine Forschungsfrage in Teilaufgaben, startet Subagenten, die parallel recherchieren, und fügt anschließend deren Ergebnisse zusammen. In Anthropics interner Browsing-Evaluation schlug diese Konfiguration eine Single-Agent-Opus-4-Basislinie um 90,2 Prozent. (Anthropic Engineering, "How we built our multi-agent research system")

Das ist die Schlagzeile. Das Kleingedruckte ist wichtiger. Derselbe Bericht weist darauf hin, dass Multi-Agenten-Systeme etwa 15-mal mehr Tokens verbrauchen als ein normaler Chat. Der Token-Verbrauch erklärte in ihrem Evaluations-Framework rund 80 Prozent der Leistungsvarianz. Sie bekommen diese 90,2 Prozent nicht umsonst; Sie kaufen sie.

Die Frage für jeden Gründer, CTO oder Staff Engineer, der ein KI-Feature entwirft, lautet also nicht mehr: "Ist Multi-Agent ein echtes Muster?" Sondern: "Ist Multi-Agent das richtige Muster für diese Aufgabe, und zu welchen Kosten?" 2025 und die erste Hälfte von 2026 haben genügend Daten geliefert, um das mit mehr als Bauchgefühl zu beantworten. Die Muster, die gewonnen haben, die Muster, die verloren haben, und die wiederkehrenden Fehlerarten sehen stark nach klassischer Organisationsgestaltung aus. Das ist der rote Faden dieses Artikels.

---

Die Taxonomie der Fehlermuster: Was Cemri et al. dokumentiert haben

Im März 2025 veröffentlichten Mert Cemri und Mitarbeiter in Berkeley "Why Do Multi-Agent LLM Systems Fail?" (arXiv 2503.13657). Das Paper analysierte fünf populäre Multi-Agenten-Frameworks anhand von mehr als 150 Gesprächsprotokollen und lieferte etwas, das das Feld dringend brauchte: eine Taxonomie.

Vierzehn unterschiedliche Fehlermuster, gruppiert in drei Familien.

Fehler in Spezifikation und Systemdesign. Agenten missachten ihre Rollenspezifikation. Sie missachten die Aufgabenspezifikation. Sie verlieren den Gesprächsverlauf. Schritte werden wiederholt. Beendigungsbedingungen werden nie ausgelöst. Das System "kennt" die Aufgabe, aber der einzelne Agent vor Ihnen verhält sich nicht so, als ob er sie kennt.

Fehlausrichtung zwischen Agenten. Agenten setzen den Fortschritt zurück und fangen von vorn an. Sie halten Informationen voreinander zurück. Sie geraten in themenfremde Austausche. Sie machen Annahmen darüber, was ein anderer Agent getan hat, und handeln auf dieser Grundlage, ohne nachzuprüfen. Das ist der klassische "Ich dachte, du hast das übernommen"-Fehler eines jeden Teams.

Fehler in Aufgabenverifikation und Beendigung. Die Verifikation ist unvollständig oder fehlt ganz. Das System meldet Erfolg, wenn das Ergebnis falsch ist. Kein Agent ist für die endgültige Abnahme zuständig. Menschen entdecken das Problem erst nachgelagert, wenn das schlechte Ergebnis bereits weiterverarbeitet wurde.

Lesen Sie die Liste und das Muster wird offensichtlich. Das sind keine Modellfehler im engeren Sinn. Das sind Koordinationsfehler. Das sind dieselben Fehler, die ein brandneues fünfköpfiges Team in seinem ersten Monat macht, bevor irgendjemand aufgeschrieben hat, wer wofür verantwortlich ist.

Gruppiert man die 14 Muster anders, schärft sich die organisatorische Parallele:

• Rollenmehrdeutigkeit. Unklare Aufgabenverantwortung. Zwei Agenten versuchen denselben Schritt, oder keiner tut es.
• Zustandsmehrdeutigkeit. Keine einzige Quelle der Wahrheit darüber, was erledigt, was ausstehend, was blockiert ist.
• Verantwortungslücken. Wer ist für das schlechte Ergebnis verantwortlich? In Peer-to-Peer-Systemen oft niemand.
• Koordinationsaufwand. Das "Meeting-Problem". Agenten verbrauchen Tokens damit, zu verhandeln, statt zu produzieren.
• Spezifikationsdrift. Dieselbe Anweisung wird über Agenten und über Gesprächsrunden hinweg unterschiedlich interpretiert.

Wenn Sie je ein Team neu aufgestellt haben, das nicht lieferte, haben Sie alle fünf gesehen. Die Lösung ist in menschlichen Teams dieselbe wie in Agentensystemen: ein Operating Model wählen, die Rollen aufschreiben, Übergaben definieren, die Arbeit instrumentieren.

---

Warum Peer-to-Peer-Agenten nicht funktionieren

Der häufigste Architekturfehler von 2024 und Anfang 2025 war Peer-to-Peer-Kollaboration: Man spawnt ein "Team" von Agenten mit verschiedenen Rollen-Prompts (CEO, Researcher, Coder, Reviewer), lässt sie in einem Gruppenchat miteinander reden und hofft, dass Koordination entsteht. AutoGen-artige Gruppenchats, frühe CrewAI-Demos und eine Welle von "KI-Startup-in-a-Box"-Projekten setzten alle auf dieses Muster.

Es scheiterte in der Produktion, und zwar durchgängig. Jedes Fehlermuster der Cemri-Taxonomie verstärkt sich in einer P2P-Konfiguration. Ohne Orchestrator verschwimmen Rollengrenzen, weil jeder Agent für alles angefragt werden kann. Der Zustand verteilt sich über den Gesprächsverlauf, weil kein Agent den kanonischen Stand hält. Verantwortlichkeit verschwindet, weil das System als Ganzes das Ergebnis erzeugt und das System als Ganzes keinen Namen darauf trägt.

Der Koordinationsaufwand ist der Killer. In einer Gruppe von fünf gleichgestellten Agenten erzeugt jede sinnvolle Aktion vier Beobachter, die sich verpflichtet fühlen, zu kommentieren. Die Token-Kosten explodieren. Das Signal-Rausch-Verhältnis bricht zusammen. Cemri et al. stellten fest, dass das Zurücksetzen eines Gesprächs, bei dem ein Agent einen abgeschlossenen Strang neu startet, weil er nicht erkennt, dass er abgeschlossen ist, eines der häufigsten und teuersten Fehlermuster in ihrem Korpus war.

Ein konkretes Beispiel. Ein Forschungsteam, mit dem ich Ende 2025 sprach, baute ein P2P-Agentensystem, um eine Wettbewerbsanalyse zu entwerfen. Fünf Agenten: Marktanalyst, Produktanalyst, Finanzanalyst, Schreiber, Lektor. Der erste Durchlauf dauerte 90 Minuten und produzierte ein Dokument von 14.000 Wörtern. Etwa 11.000 dieser Wörter waren die Agenten, die diskutierten, was das Dokument enthalten sollte. Die verbleibenden 3.000 waren das Dokument selbst, und sie widersprachen sich gegenseitig. Das Team baute es in der Folgewoche als Orchestrator-Worker-Setup um. Gleiche Aufgabe, 22 Minuten, 4.200 Wörter, intern konsistent. Etwa die Hälfte der Tokenkosten.

P2P scheiterte nicht, weil die Agenten nicht intelligent genug waren. Es scheiterte, weil es von ihnen das Schwierigste verlangte, was eine Gruppe tun kann: sich ohne Vorsitz selbst organisieren.

---

Orchestrator-Worker: Das Muster, das gewonnen hat

Anthropics Forschungssystem ist ein lehrbuchmäßiges Orchestrator-Worker-Setup. Ein Koordinator-Agent besitzt die übergeordnete Aufgabe. Er zerlegt die Aufgabe in Teilaufgaben, übergibt jede Teilaufgabe einem Worker-Agenten mit einem konkreten Auftrag, sammelt die Ergebnisse und entscheidet, was als Nächstes zu tun ist. Worker sprechen nicht miteinander. Sie sprechen mit dem Orchestrator.

Das bildet sich sauber auf menschliche Organisationsgestaltung ab, und genau deshalb funktioniert es. Ein kleines Startup mit einem Gründer und vier Auftragnehmern arbeitet so. Der Gründer hält die Spezifikation, das Budget, den Zeitplan und den gemeinsamen Kontext. Auftragnehmer führen abgegrenzte Aufgaben anhand eines Briefings aus. Informationen fließen über den Gründer nach oben; Aufgaben fließen vom Gründer nach unten. Auftragnehmer müssen sich, abgesehen von sorgfältig abgegrenzten Paarungen, nicht untereinander koordinieren.

Das Muster hat vier Eigenschaften, die für Zuverlässigkeit zählen.

Ein Eigentümer des gemeinsamen Zustands. Der Orchestrator hält den kanonischen Stand. Es gibt keine Mehrdeutigkeit darüber, was getan wurde.

Abgegrenzte Worker-Kontexte. Jeder Worker bekommt nur das, was er braucht. Das hält Kontextfenster handhabbar und reduziert die Wahrscheinlichkeit aufgabenübergreifender Kontamination.

Definierte Übergaben. Worker-Ergebnisse kommen in einem strukturierten Format zurück, das der Orchestrator verifizieren kann. Keine formfreien Verhandlungen.

Eine einzige Verantwortungsfläche. Wenn das Ergebnis falsch ist, ist der Orchestrator verantwortlich. Sie debuggen einen Ort.

Anthropics Bericht ist explizit darin, wie viel ihrer Zuverlässigkeitsarbeit innerhalb des Orchestrators stattfand: Der Prompt des Lead-Agenten ist der längste und am sorgfältigsten justierte Teil des Systems, denn dort leben die Rollendefinitionen, die Zerlegungsheuristiken und die Beendigungslogik. (Anthropic Engineering)

Begrenzte Kollaboration ist eine nützliche Variante. Zwei Worker dürfen sich vielleicht zu einer bestimmten Übergabe abstimmen, aber nur über einen strukturierten Kanal und nur zu einem definierten Thema. Sehen Sie es als geplantes Standup, nicht als Slack-Kanal. Die Begrenzung ist der Punkt.

---

Das 5-Stufen-Autonomie-Framework

Das andere Stück Gerüst aus 2025, das Sie kennen sollten, ist das Autonomie-Framework aus "Levels of Autonomy for AI Agents" (arXiv 2506.12469, mit einem begleitenden Governance-Beitrag bei Knight Columbia). Die Autoren definieren fünf Stufen, lose analog zur SAE-Fahrautomatisierung, aber für KI-Agenten.

Stufe 0: Assistiv. Das Modell schlägt vor; der Mensch handelt. Autocomplete, Inline-Code-Vorschläge, Entwurf von E-Mails.

Stufe 1: Operator. Der Mensch löst weiterhin jede Aktion aus, aber der Agent setzt Tool-Aufrufe und zusammengesetzte Schritte unter direkter Anweisung zusammen.

Stufe 2: Reviewer. Der Agent schlägt einen Plan vor und führt ihn unter Aufsicht aus. Der Mensch gibt an wichtigen Kontrollpunkten frei.

Stufe 3: Kollaborator. Der Agent verantwortet ganze Aufgaben autonom innerhalb einer abgegrenzten Grenze. Der Mensch prüft Ergebnisse, nicht Schritte.

Stufe 4: Experte. Der Agent arbeitet eigenständig an komplexer mehrstufiger Arbeit, der Mensch greift nur bei markierten Ausnahmen ein.

Stufe 5: Agent. Volle Autonomie über eine Domäne hinweg. Der Agent setzt Ziele, plant, führt aus und korrigiert sich selbst mit minimaler Aufsicht.

Anthropics ergänzende Arbeit "Measuring AI agent autonomy in practice" macht einen verwandten Punkt: In realen Einsätzen ist die Betriebsstufe selten gleichmäßig über ein System verteilt. Ein System der "Stufe 3" enthält normalerweise Teilkomponenten der Stufe 1 (Aktionen mit hohem Risiko) und Teilkomponenten der Stufe 4 (Hintergrundarbeit mit geringem Risiko). Wichtig ist, die Stufe an die Aufgabe anzupassen, nicht die Stufe global anzuheben.

Die Stufe, auf die Sie zielen, prägt jede nachgelagerte Rollenentscheidung. Auf Stufe 2 brauchen Ihre Worker-Agenten klare Plan-Review-Affordanzen. Auf Stufe 4 brauchen sie das Markieren von Ausnahmen und reichhaltiges Tracing. Auf Stufe 5 brauchen sie formale Verifikation der Akzeptanzkriterien, denn sonst fängt nichts eine falsche Antwort ab. Entwickler, die diesen Schritt überspringen, wählen zuerst die Architektur und entdecken dann in der Produktion, dass die durch die Architektur implizierte Stufe nicht die Stufe ist, die die Aufgabe verträgt.

---

Stufen in der Praxis: Der Fall Devin

Cognitions Devin wurde 2025 zum meistzitierten Warnbeispiel. Im März 2024 als "der erste KI-Softwareentwickler" gestartet, erzielte Devin 13,86 Prozent auf SWE-bench Verified, was damals State of the Art war. Das Marketing implizierte Autonomie auf Stufe 4 oder Stufe 5: Ticket übergeben, funktionierenden PR zurückerhalten.

Bis Mitte 2025 setzten mehrere unabhängige Reviews Devins reale Erfolgsquote auf rund 15 Prozent an, also eine effektive Fehlerquote von rund 85 Prozent auf Aufgaben, die keine kuratierten Benchmark-Instanzen waren. Ein vielzitiertes Review von Answer.AI ging 20 echte Versuche durch und berichtete, dass 14 davon vollständig scheiterten, wobei mehrere selbstbewusst falsche Ausgaben produzierten, deren Debugging länger dauerte, als den Code von Grund auf neu zu schreiben.

Was passiert ist, ist die Lücke zwischen Benchmark und Produktion, in Reinform. SWE-bench-Verified-Aufgaben sind sauber: ein Repo, ein gut beschriebenes Issue, ein klares Testsignal, eine begrenzte Angriffsfläche. Reale Engineering-Tickets sind chaotisch: mehrdeutige Spezifikationen, übergreifende Belange, undokumentierte Annahmen, Entscheidungen, die von implizitem Wissen abhängen. Derselbe Agent, der auf dem Benchmark Stufe 3 erreichte, fiel im Wildbetrieb auf eine wackelige Stufe 2 zurück, manchmal schlechter.

Devin ist keine Geschichte über einen schlechten Agenten. Es ist eine Geschichte über eine Stufendiskrepanz. Die Architektur zielte auf Zuverlässigkeit der Stufe 5; die zugrunde liegende Leistungsfähigkeit trug im besten Fall Stufe 2 bei nicht kuratierter Arbeit. Das Marketing zwang die Nutzer, das System auf der beworbenen Stufe zu betreiben, wo es scheiterte. Cognitions spätere Kurskorrekturen, stärker abgegrenzte Anwendungsfälle, mehr Human-in-the-Loop-Affordanzen, eine ehrlichere Darstellung, sind ein Versuch, die Betriebsstufe wieder mit der Leistungsfähigkeit in Einklang zu bringen.

Die Lektion ist konkret. Wählen Sie das Autonomielevel, das Ihr System bei Ihrer schwersten realen Aufgabe halten kann, nicht bei Ihrem einfachsten Benchmark. Gestalten Sie Rollen, Aufsicht und Eskalationspfade für diese Stufe. Wenn Sie Marketing für Stufe 5 wollen, bauen Sie ein System der Stufe 5; wenn Sie ein System der Stufe 3 haben, vermarkten Sie es als solches.

---

Cursor 2.0 und der hardwaregestützte Workflow

Cursor 2.0 wurde im Februar 2026 ausgeliefert und löste leise eines der hartnäckigsten Probleme von Multi-Agenten-Coding: Workspace-Konflikte. Cursors Hintergrund-Agenten laufen jetzt auf Cloud-VMs, jeder in seinem eigenen Git-Worktree, und die IDE kann bis zu acht parallel koordinieren.

Das entscheidende architektonische Detail: Jeder Agent hat sein eigenes Dateisystem. Kein gemeinsamer Arbeitsbaum bedeutet keine Merge-Konflikte mitten in der Bearbeitung, kein "Agent A hat die Änderungen von Agent B überschrieben", keine instabilen Testläufe, weil zwei Agenten dieselben Dateien anfassten. Wenn ein Agent fertig ist, kann sein Branch wie jeder andere PR geprüft und gemergt werden. Wenn es schiefläuft, werfen Sie den Worktree weg.

Das ist hardwaregestützte Isolation in demselben Sinne, wie virtuelle Maschinen in den 2000er-Jahren Prozessisolation lieferten. Die Agentengrenzen sind nicht mehr "wir versprechen, uns nicht gegenseitig auf die Füße zu treten"; sie sind "das Betriebssystem lässt uns das buchstäblich nicht zu".

Warum das für die Cemri-Taxonomie zählt: Hardware-Isolation eliminiert eine ganze Klasse von Fehlausrichtungs-Fehlern zwischen Agenten. Zustand bleibt im Worktree. Nebenwirkungen bleiben in der VM. Der Orchestrator (Cursor selbst oder der Nutzer) sieht nur den Diff, den jeder Agent produziert. Die Abnahmeprüfung ist strukturell (besteht der PR die CI?) statt konversationsbasiert (behauptet dieser Agent, die Arbeit sei erledigt?).

Praktiker, die Cursor 2.0 neben Anthropics Claude Code, OpenAIs Codex CLI und anderen Parallel-Agenten-Tools betreiben, haben sich auf ein Muster eingependelt: drei bis acht Agenten auf unabhängigen Aufgaben starten, ihren Fortschritt über ein einheitliches Dashboard überwachen, die Gewinner mergen, die Verlierer verwerfen. Das Kostenmodell ähnelt eher "einen Junior-Auftragnehmer für eineinhalb Stunden mieten" als "einem Chatbot eine Frage stellen". Das Ergebnismodell ähnelt eher einem GitHub-PR-Review als einer Chat-Completion.

Anysphere (Cursor), Bolt, Lovable und v0 innerhalb von Vercel betreiben jetzt alle intern Varianten dieser Schleife. Die Firmen, die den meisten agentengetriebenen Code ausliefern, sind die Firmen, die die Workspace-Isolation zuerst gebaut haben.

---

Rollen für KI-Teamkollegen gestalten

Sobald Sie akzeptieren, dass Multi-Agenten-Versagen ein Problem der Organisationsgestaltung ist, beginnen Ihre Designentscheidungen wie klassisches Management auszusehen. Jede Agentenrolle braucht vier Artefakte.

Eine abgegrenzte Verantwortung. Ein Satz: was dieser Agent verantwortet und was nicht. Ein "Researcher"-Agent, der auch Prosa schreibt, ist zwei Agenten im Mantel. Trennen Sie sie.

Ein strukturiertes Eingabe-Briefing. Nicht "recherchiere X". Eine Vorlage, die ausfüllt: die Frage, den vorherigen Kontext, den der Agent annehmen soll, das Format der erwarteten Ausgabe, die Einschränkungen (Zeit, Tokens, Tools), die Quellenpräferenzen. Das ist das Agenten-Äquivalent eines Projekt-Briefings.

Definierte Akzeptanzkriterien. Wie sieht "erledigt" aus? Oft ist das ein Schema (die Ausgabe muss gegen diesen Zod-Typ validieren) oder eine deterministische Prüfung (der PR muss diese drei Testdateien bestehen). Wo deterministische Prüfungen nicht möglich sind, läuft ein separater Reviewer-Agent gegen eine explizite Rubrik.

Ein Eskalationspfad. Wenn der Agent feststeckt, was tut er? Sinnvolle Standardwerte: dem Orchestrator eine strukturierte Klärungsfrage stellen, eine markierte Ausnahme an einen Menschen weitergeben, mit typisiertem Fehler abbrechen. Der falsche Standard ist "weitermachen und improvisieren". Daher kommt halluzinierter Erfolg.

Wenden Sie Cemris Fehlermuster eines nach dem anderen an, und diese vier Artefakte decken die meisten ab. Rollenmehrdeutigkeit stirbt an der abgegrenzten Verantwortung. Zustandsmehrdeutigkeit stirbt am strukturierten Briefing. Verantwortungslücken sterben an den Akzeptanzkriterien. Koordinationsaufwand sinkt, weil der Agent nicht verhandeln muss; er hat ein Briefing und eine Rubrik. Spezifikationsdrift sinkt, weil die Spezifikation im Schema festgehalten ist, nicht in Stimmungen.

Der nicht-offensichtliche Teil: Schreiben Sie die Rolle, als würden Sie eine Stellenbeschreibung für einen Auftragnehmer schreiben, nicht einen Prompt für einen Chatbot. Auftragnehmer sind das richtige Denkmodell. Sie haben ein Briefing, sie liefern ein Ergebnis, sie müssen den gesamten Unternehmenskontext nicht kennen, und Sie kündigen ihnen, wenn sie wiederholt die Spezifikation verfehlen.

---

Das Multi-Agenten-Playbook für Gründer

Hier die praktische Version, destilliert aus dem Anthropic-Bericht, dem Cemri-Paper, den Devin-Postmortems und den Workflow-Daten von Cursor 2.0.

Starten Sie bei Stufe 2 oder 3, nicht bei Stufe 5. Leistungsfähigkeit ist unter Verteilungsverschiebung fragil. Auch wenn Ihr Benchmark Stufe 4 sagt, liegt Ihre schwerste reale Aufgabe meist eine Stufe darunter. Zielen Sie auf die Stufe, die Ihre schwerste Aufgabe halten kann.

Nutzen Sie Orchestrator-Worker, nicht Peer-to-Peer. Ein Agent besitzt den gemeinsamen Zustand. Worker bekommen abgegrenzte Briefings. Begrenzte Kollaboration nur an sorgfältig entworfenen Nahtstellen. Keine Gruppenchats.

Definieren Sie eine Agentenrolle nach der anderen. Widerstehen Sie der Versuchung, ein System mit fünf Agenten auf einem Whiteboard zu entwerfen, bevor irgendetwas davon ausgeliefert wird. Liefern Sie einen Orchestrator und einen Worker aus. Beobachten Sie ihn eine Woche. Fügen Sie den nächsten Worker hinzu, wenn Sie den ersten haben scheitern und wieder reparieren sehen.

Schreiben Sie das Briefing wie eine Stellenbeschreibung. Verantwortung, Eingaben, Akzeptanzkriterien, Eskalation. Wenn Sie die Rolle nicht in vier kurzen Abschnitten beschreiben können, ist die Rolle nicht bereit für den Einsatz.

Instrumentieren Sie mit vollständigen Traces. Jede Agentenaktion, jeder Tool-Aufruf, jede Zwischenausgabe. Sie können Multi-Agenten-Systeme nicht debuggen, indem Sie die finale Ausgabe lesen. Der Bug liegt fast immer weiter oben in der Kette.

Budgetieren Sie 15-fache Token-Kosten. Anthropics Forschungssystem nutzte etwa 15-mal so viele Tokens wie eine Single-Agent-Basislinie. Planen Sie entsprechend. Wenn Ihre Stückkosten bei 15x kippen, ist Multi-Agent das falsche Muster für dieses Feature.

Halten Sie bei folgenreichen Aktionen einen Menschen in der Schleife. "Folgenreich" bedeutet meist: Schreibvorgänge auf ein kundenseitiges System, Versand externer Kommunikation, Geld ausgeben, Daten löschen, eine sicherheitsrelevante Ressource ändern. Die menschliche Prüfung kostet Sekunden; ihr Fehlen kann Monate kosten.

Bauen Sie die Workspace-Isolation vor der Agentenflotte. Cursors Lektion verallgemeinert. Git-Worktrees für Code, abgegrenzte Datenbanktransaktionen für Daten, dedizierte VMs für Arbeit, die die Umgebung berührt. Isolation ist billiger als Koordination.

Führen Sie in den ersten 90 Tagen ein Postmortem zu jedem Fehler durch. Markieren Sie jeden Fehler gegen die Cemri-Taxonomie. Muster zeigen sich schnell. Der dritte Fehler "Agent hat fertige Arbeit erneut gemacht" ist das Signal, dass Ihre Beendigungsbedingungen nachgezogen werden müssen.

Nichts davon ist exotisch. Es ist dasselbe Playbook, das eine kompetente Engineering-Leitung nutzt, um ein neues Team von Auftragnehmern einzuarbeiten. Der Grund, warum Multi-Agent funktioniert, ist, dass es dasselbe Problem mit engerer Rückkopplungsschleife ist.

---

Wohin die Reise geht

Die nächsten 12 bis 18 Monate drehen sich darum, diese Muster in Infrastruktur zu verwandeln. Ein paar Fäden, die zu beobachten sind.

Agent-zu-Agent-Protokolle. Googles A2A-Protokoll, die in IDE- und CLI-Tools entstehende AGENTS.md-Konvention und diverse Interop-Entwürfe in Arbeitsgruppen sind ein Versuch, zu standardisieren, wie Agenten einander entdecken, Fähigkeitsbeschreibungen austauschen und sich authentifizieren. (Anthropics Überblick zum Bauen von Agenten deutet in diese Richtung.) Der Punkt ist, Orchestrator-Worker-Muster über Anbieter hinweg komponierbar zu machen, statt sie an das SDK eines Anbieters zu binden.

Capability-Token-Autorisierung. Heute erben die meisten Agenten die vollen Anmeldedaten des Nutzers, der sie gestartet hat. Das ist für Stufe 3 und darüber eine schlechte Idee. Capability-Tokens, eng, zeitlich begrenzt, auf bestimmte Tool-Aufrufe und Ressourcen zugeschnitten, sind der Weg, wie Agenten die Berechtigungen bekommen, die sie wirklich brauchen, ohne die, die sie nicht brauchen. Erwarten Sie, dass das 2026 in Produktions-SDKs landet.

Verifizierte Agentenidentitäten. Wenn Agenten anfangen, andere Agenten über organisatorische Grenzen hinweg aufzurufen, muss die empfangende Seite wissen, was anruft. Signierte Agentenidentitäten, Attestierung von Training und Konfiguration und herstellerübergreifende Identitätsformate werden derzeit prototypisiert. Das Modell ist näher an Certificate Transparency als an OAuth.

Bessere Evaluation. SWE-bench, MLE-bench, GAIA und ähnliche Suites haben sich so weit gedehnt, dass Frontier-Modelle sie sättigen. Die nächste Generation von Evals wird Dinge messen, denen Benchmarks historisch ausgewichen sind: langfristige Aufgabenerfüllung, anhaltende Richtlinieneinhaltung, Erholung von Fehlern, Kosten pro Erfolg. Erwarten Sie, dass "Agentenzuverlässigkeit" zu einer messbaren Eigenschaft wird, so wie es "Uptime" für Dienste wurde.

Standardisiertes Fehler-Tagging. Cemri et al. haben dem Feld eine Taxonomie gegeben. Der natürliche nächste Schritt ist Tooling, das Traces automatisch gegen diese Taxonomie taggt, so wie Sentry Ausnahmen taggt. Gründer, die das früh aufsetzen, debuggen ihre Agentensysteme um eine Größenordnung schneller als jene, die es nicht tun.

Die Arbeit ist noch im Flug. Keiner dieser Fäden ist abgeschlossen. Aber die Form der nächsten Phase ist sichtbar: weniger Prompt-Handwerk, mehr Systems Engineering; weniger "Was kann das Modell?", mehr "Welche Rolle muss ich besetzen, und wie sieht erledigt aus?" Die Teams, die gedeihen, werden diejenigen sein, die Agenten als Teamkollegen behandeln, mit derselben Strenge, die sie auf jede Neueinstellung anwenden würden. Rollen, Briefings, Akzeptanzkriterien, Eskalationspfade. Die langweiligen Artefakte kompetenter Organisationen.

---

Häufig gestellte Fragen

Sollte jedes Team Multi-Agenten-Systeme bauen?

Nein. Die meisten produktiven KI-Features funktionieren immer noch am besten als Single-Agent-Setups mit guten Tools. Multi-Agent verdient sich seinen Platz, wenn die Aufgabe wirklich zerlegbar ist (unabhängige Teilaufgaben, die parallel laufen können), der Wert pro Aufgabe die 15-fachen Token-Kosten rechtfertigt und die Zuverlässigkeit zuerst auf der Single-Agent-Ebene bewiesen wurde. Ein scheiterndes Single-Agent-System wird nicht zu einem funktionierenden Multi-Agenten-System. Es wird meist zu einem teureren scheiternden System.

Was ist das einfachste produktionsreife Multi-Agenten-Muster?

Ein Orchestrator mit zwei Workern, beide mit deterministischen Akzeptanzkriterien. Der Orchestrator besitzt den gemeinsamen Zustand. Worker bekommen abgegrenzte Briefings. Ausgaben validieren gegen ein Schema, bevor der Orchestrator sie akzeptiert. Das reicht, um den größten Teil des Nutzens der Zerlegung einzufangen, ohne den Koordinationsaufwand größerer Teams. Skalieren Sie die Worker-Zahl erst hoch, wenn diese Basislinie zuverlässig läuft.

Lohnen sich die 15-fachen Token-Kosten?

Das hängt vom Wert des Ergebnisses ab. Anthropics Forschungssystem ergibt wirtschaftlich Sinn, weil die Alternative ein menschlicher Forscher ist, der Stunden mit derselben Aufgabe verbringt. Für niedrigwertige, hochvolumige Arbeit (Intent-Klassifikation, einfache Zusammenfassung, Routine-Extraktion) sind 15-fache Token-Kosten fast nie lohnend; nutzen Sie ein Single-Agent-Setup oder ein kleineres Modell. Für hochwertige, niedrigvolumige Arbeit (tiefe Recherche, komplexe Coding-Aufgaben, mehrquellige Analyse) geht die Rechnung oft auf.

Wie weiß ich, wann ich einen Subagenten spawnen soll und wann ein längerer Prompt reicht?

Spawnen Sie einen Subagenten, wenn die Arbeit eine andere Kontextanforderung hat als die übergeordnete Aufgabe. Wenn die Teilaufgabe andere Tools, einen anderen System-Prompt oder Kontext braucht, der das Fenster des Eltern-Agenten verschmutzen würde, geben Sie ihr einen eigenen Agenten. Wenn die Teilaufgabe "mach einfach diese nächste Sache" lautet und den Kontext des Eltern-Agenten teilt, sind ein längerer Prompt oder ein Tool-Aufruf günstiger und zuverlässiger. Die entscheidende Frage lautet meist: Will ich diesen Kontext im Gedächtnis meines Orchestrators behalten, nachdem die Teilaufgabe erledigt ist?

Was ist der Unterschied zwischen einem Agenten und einem KI-Tool?

Ein Tool ist eine einzelne deterministische Fähigkeit, die das Modell aufrufen kann (eine Websuche, eine Datenbankabfrage, ein Code-Formatter). Ein Agent ist eine Schleife: Er beobachtet, plant, ruft Tools auf, bewertet das Ergebnis und entscheidet, was als Nächstes zu tun ist, oft über viele Runden hinweg. Tools sind Substantive; Agenten sind Verben. Ein gut gebauter Agent nutzt viele Tools. Ein "Tool", das intern ein Modell aufruft und seine eigene Schleife läuft, ist in der Praxis ein Agent.

---

Schlussgedanken

Die nützlichste Rahmung für den aktuellen Moment, die ich gehört habe, kam von einer Engineering-Leitung, die einen Multi-Agenten-Coding-Rollout durchführte: "Wir haben aufgehört, Agenten als smart zu betrachten, und angefangen, sie als Juniors mit unendlicher Ausdauer zu sehen." Juniors brauchen klare Rollen, schriftliche Briefings, definierte Akzeptanzkriterien und einen Eskalationspfad. Sie machen vorhersagbare Fehler. Sie werden mit Feedback besser. Sie scheitern, wenn niemand ihre Arbeit verantwortet.

Das ist die organisatorische Verschiebung, die sich in der Multi-Agenten-Diskussion versteckt. Die schwierigen Probleme von 2025-2026 sind keine Leistungsfähigkeitsprobleme mehr. Die Modelle sind gut genug. Die schwierigen Probleme sind dieselben, die es schon immer schwer gemacht haben, Teams aus Menschen zu führen: Wer verantwortet was, wer hält den Zustand, wer prüft die Arbeit, wer ist verantwortlich, wenn etwas schiefgeht. Cemris Taxonomie, das Autonomie-Framework, das Orchestrator-Worker-Muster, das Devin-Postmortem, das Cursor-Isolationsmodell: Sie sind alle Antworten auf Varianten derselben Frage.

Wenn Sie Gründer eines agentengetriebenen Produkts in 2026 sind, sind die langweiligen Artefakte der Hebel. Schreiben Sie die Rollen. Schreiben Sie die Briefings. Definieren Sie erledigt. Bauen Sie die Workspace-Isolation. Instrumentieren Sie die Traces. Halten Sie den Menschen in der Schleife, wo es zählt. Die Teams, die das tun, werden zwei Monate lang langsamer und zwei Jahre lang schneller aussehen. Die Teams, die es überspringen, werden den Rest des Jahres damit verbringen, Fehlermuster gegen eine Taxonomie zu taggen, die jemand anderes bereits geschrieben hat.

Die Agenten sind jetzt Teamkollegen. Führen Sie sie wie welche.