21.07.2026 AI Engineering 6 Minuten Lesezeit

Subagenten vs. Peer-Agenten — zwei Arbeitsmodi von Multi-Agenten-Systemen

Subagenten und Peer-Agenten heißen beide Multi-Agenten-Systeme, unterscheiden sich aber in Zustand, Lebenszyklus, Kosten und Vertrauensmodell. Dieser Artikel trennt die beiden Arbeitsmodi mit verifizierten Zahlen von Anthropic und Cognition, erklärt, was A2A 1.0 standardisiert — Agent Cards, Tasks, contextId —, zeigt, warum Unabhängigkeit die Simulation von Gegenübersystemen ermöglicht, und liefert sechs Entscheidungsregeln für die Wahl des richtigen Modus.

Ein Begriff für zwei Architekturen

Der Begriff Multi-Agenten-System bezeichnet zwei Architekturen, die außer dem Namen wenig teilen. Im Juni 2025 wurde die Verwechslung sichtbar: Am 12. Juni veröffentlichte Cognition "Don't Build Multi-Agents", einen Tag später Anthropic "How we built our multi-agent research system". Beide Texte sind korrekt — sie beschreiben unterschiedliche Arbeitsmodi auf unterschiedlichen Workloads. Der eine Modus delegiert Teilaufgaben innerhalb eines Systems. Der andere verbindet unabhängige Systeme, die Agenten sind. Wer beides vermischt, erhält falsche Kostenschätzungen, falsche Zuverlässigkeitserwartungen und falsche Protokolle.

Die Unterscheidung ist heute relevant, weil beide Modi innerhalb von zwölf Monaten gereift sind. Orchestrator-Frameworks wurden zur Standardausstattung von Coding-Tools und Research-Produkten, während das Agent2Agent-Protokoll im März 2026 Version 1.0 erreichte und unabhängigen Agenten einen stabilen Wire-Contract gab. Teams stehen damit vor einer echten Entscheidung mit belastbaren Zahlen — nicht vor einer Stilfrage.

Zwei Peers — jeder mit eigenem Zustand und privatem Graph. 1/4

Definition: Subagenten und Peer-Agenten

Ein Subagent ist eine LLM-Instanz, die ein Orchestrator für eine begrenzte Teilaufgabe startet. Er erhält seine Aufgabenbeschreibung vom Elternagenten, arbeitet in einem eigenen Kontextfenster, liefert ein Ergebnis und terminiert. Er hat keine Adresse, keinen persistenten Zustand und keine Existenz außerhalb der Delegation. Anthropics Research-System ist die Referenzimplementierung: Ein Lead-Agent zerlegt die Anfrage und startet parallele Such-Subagenten.

Ein Peer-Agent ist ein unabhängiges System. Er läuft mit eigenem Lebenszyklus, hält eigenen Zustand und ist unter einem Netzwerk-Endpunkt erreichbar — oft betrieben von einem anderen Team oder einer anderen Organisation. Sie starten ihn nicht; Sie senden ihm eine Nachricht, und er entscheidet, wie er antwortet. Aus Delegation wird Kommunikation. Die Tabelle fasst die Unterschiede zusammen.

Dimension	Subagent	Peer-Agent
Erzeugt durch	Orchestrator, je Teilaufgabe	Seinen Betreiber; läuft dauerhaft
Lebensdauer	Eine Delegation, dann Terminierung	Unabhängig von jeder einzelnen Aufgabe
Zustand	Eigenes Kontextfenster, nach Rückgabe verworfen	Eigener persistenter Zustand und Speicher
Adressierung	Interner Spawn / Tool-Aufruf	Netzwerk-Endpunkt über Agent Card
Vertrauensgrenze	Gleicher Prozess, gleicher Betreiber	Kann Team- und Organisationsgrenzen überschreiten
Fehlerbehandlung	Elternagent wiederholt oder plant neu	Task-Lebenszyklus, Timeouts, Neuverhandlung
Testbarkeit	End-to-End mit dem Elternagenten	Vertrag erlaubt simulierte Gegenüber

Was Orchestrierung leistet

Orchestrierung kauft Breite. Anthropic berichtet, dass ein Multi-Agenten-Aufbau mit Claude Opus 4 als Lead und Claude Sonnet 4 als Subagenten den Einzelagenten Opus 4 in einer internen Research-Evaluation um 90,2 % übertraf. Der Mechanismus ist paralleler Kontext: Jeder Subagent erhält ein eigenes Fenster, das System liest also mehr, als ein einzelner Kontext fassen kann. Der Token-Verbrauch allein erklärte 80 % der Leistungsvarianz in der BrowseComp-Analyse.

Der Preis ist explizit. Anthropic maß rund das 15-Fache des Token-Verbrauchs einer Chat-Interaktion; ein Folgebeitrag vom Januar 2026 beziffert den Multi-Agenten-Overhead auf das 3- bis 10-Fache gegenüber einem Einzelagenten bei gleicher Aufgabe. Anthropic benennt auch die Grenze: Aufgaben, in denen Agenten Kontext teilen müssen oder deren Schritte voneinander abhängen — die meiste Programmierarbeit etwa — passen schlecht. Orchestrierung lohnt sich bei zerlegbarer Breitensuche, nicht per Default.

Wo Kontextteilung an Grenzen stößt

Cognitions Essay formuliert zwei Prinzipien: Teilen Sie vollständige Agent-Traces, nicht nur einzelne Nachrichten; und Aktionen tragen implizite Entscheidungen — widersprüchliche Entscheidungen erzeugen schlechte Ergebnisse. Parallele Subagenten, die einander nicht sehen, treffen inkompatible implizite Festlegungen zu Stil, APIs und Randfällen; die Konflikte zeigen sich beim Zusammenführen. Die Empfehlung von 2025 lautete: ein einzelner Agent mit durchgehendem Kontext.

Vollständige Trace-Teilung skaliert nicht. Traces wachsen schneller als Kontextfenster, und lange Kontexte verschlechtern messbar die Entscheidungsqualität. In einem Folgebeitrag von 2026 berichtet Cognition, dass funktionierende Multi-Agenten-Setups Schreiboperationen single-threaded halten, während zusätzliche Agenten Analyse beisteuern — ihr Review-Agent mit leerem Kontext findet Fehler gerade deshalb, weil er die Historie des Coding-Agenten nicht mitträgt; Cognition führt das auf Context Rot zurück. Über Organisationsgrenzen hinweg entfällt die Frage ganz: Mit einem System, das Sie nicht betreiben, können Sie keinen Kontext teilen. Das ist der Fall für Peer-Agenten.

Was A2A 1.0 standardisiert

Das Agent2Agent-Protokoll (A2A) adressiert genau diese Grenze. Google kündigte es am 9. April 2025 mit über 50 Partnern an; das Projekt liegt heute bei der Linux Foundation, gesteuert von einem technischen Komitee mit Vertretern von AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP und ServiceNow. Version 1.0 erschien am 12. März 2026 als erstes Release, das das Projekt als produktionsreif bezeichnet.

Drei Konstrukte tragen die Spezifikation. Die Agent Card ist ein JSON-Manifest mit Identität, Skills, Sicherheitsanforderungen und unterstützten Interfaces — jedes mit eigenem Protocol Binding (JSON-RPC, gRPC oder HTTP+JSON) und eigener Protokollversion; v1.0 ergänzt JWS-Signaturen zur kryptographischen Verifikation. Ein Task ist eine zustandsbehaftete Arbeitseinheit mit definiertem Lebenszyklus: unterbrochene Zustände wie input-required und terminale Zustände (completed, canceled, rejected, failed) — ein terminaler Task startet nie neu. Die contextId gruppiert zusammengehörige Tasks und Messages über eine Folge von Interaktionen hinweg.

Ebenso wichtig ist, was A2A nicht standardisiert: Prompts, Reasoning-Traces und Modellkontext überqueren nie die Leitung. Das Protokoll definiert den Umschlag — Discovery, Task-Zustand, Artefakte — und lässt das Innere jedes Agenten opak. Diese Opazität ist keine Lücke, sondern genau die Eigenschaft, die organisationsübergreifenden Betrieb überhaupt möglich macht.

Unabhängigkeit ermöglicht Simulation

Weil ein Peer vollständig durch seinen Vertrag definiert ist — Agent Card plus Task-Semantik —, kann alles seine Stelle einnehmen, was den Vertrag einhält. Das ermöglicht ein aus Microservices bekanntes Muster: Service-Virtualisierung. Bevor ein echtes Gegenüber verfügbar ist, entwickeln und testen Sie Ihren Agenten gegen einen simulierten Peer, der dasselbe Protokoll spricht. Er nimmt Tasks an, sendet Statusupdates, liefert Artefakte und weist fehlerhafte Anfragen zurück.

Hier verdient Unabhängigkeit ihre Kosten. Ein simulierter Peer spielt Fehlermodi deterministisch ab — Timeouts, abgelehnte Tasks, input-required-Schleifen, widerrufene Credentials —, die reale Gegenüber selten und unvorhersehbar erzeugen. Subagenten bieten kein Äquivalent, denn ihre Schnittstelle ist ein zur Laufzeit formulierter Prompt; es gibt keinen stabilen Vertrag, gegen den man simulieren könnte. Ehrliche Abgrenzung: Simulation validiert Protokollverhalten und die Fehlerbehandlung Ihres Agenten. Sie validiert nicht die tatsächliche Semantik des Partners. Ein Integrationstest gegen das reale System bleibt Pflicht.

Sechs Entscheidungsregeln

1. Ein Betreiber, eine Aufgabe, Ergebnisse fließen in eine Antwort zurück: Subagenten. 2. Die Arbeit zerfällt in Zweige, die einander nicht sehen müssen — Breitensuche, parallele Recherche: Subagenten lohnen sich; teilen die Schritte Zustand oder hängen sie von der Reihenfolge ab, verwenden Sie einen durchgehenden Einzelagenten statt eines Schwarms. 3. Das Gegenüber hat eigenen persistenten Zustand, eigenen Lebenszyklus oder einen eigenen Besitzer: Es ist ein Peer. Das System einer anderen Organisation können Sie nicht starten, nur adressieren.

4. Eine Vertrauensgrenze wird überschritten — Authentifizierung, Signaturen, Audit: Verwenden Sie einen protokolldefinierten Peer, keine interne Delegation; die signierten Agent Cards und Security-Schemes von A2A 1.0 existieren für diesen Fall. 5. Prüfen Sie das Budget: Rechnen Sie mit dem 3- bis 10-fachen Token-Overhead gegenüber einem Einzelagenten; der Wert der Aufgabe muss ihn decken. 6. Müssen Sie gegen ein noch nicht erreichbares Gegenüber entwickeln, entwerfen Sie contract-first und simulieren Sie den Peer — das geht nur im Peer-Modus.

Ausblick: Von der Hierarchie zur Föderation

Die beiden Modi werden sich zusammensetzen statt konkurrieren — so wie Funktionen und Services in klassischer Software. Innerhalb eines Produkts bleibt die Orchestrator-Subagenten-Hierarchie der effiziente Default: gemeinsamer Betreiber, gemeinsames Budget, keine Protokollsteuer. An Organisationsgrenzen übernehmen protokollvermittelte Peers — signierte Agent Cards, Multi-Tenancy und Versionsverhandlung in A2A 1.0 sind Infrastruktur für den Rand, kein internes Plumbing.

Wir erwarten, dass sich die Arbeit der nächsten Zeit auf die Nahtstellen konzentriert: Registries für Agent-Card-Discovery, Konformitäts-Testsuiten und simulierte Gegenüber als Standardwerkzeug in Agent-CI-Pipelines. Die offenen Probleme, die Cognition benennt — wann eskalieren, wie Kontext übertragen, ohne den Empfänger zu fluten —, sind Kommunikationsprobleme; sie werden inkrementell gelöst, nicht durch eine neue Architektur. Skalieren werden die Systeme, die wissen, in welchem Modus sie sich befinden.