20.12.2025 AI Engineering 5 Minuten Lesezeit

Peer-Agenten und Subagenten aus ersten Prinzipien

Subagent und Peer-Agent bezeichnen zwei verschiedene Architekturen, nicht zwei Wörter für eine. Wir leiten die Unterscheidung aus ersten Prinzipien ab — wem gehört der Kontext, wem der Lebenszyklus — und zeigen, wie Vertrauensgrenzen, Token-Kosten und Testbarkeit daraus folgen. Mit gemessenen Zahlen aus Anthropics Multi-Agenten-Research-System und dem A2A-Protokoll, Stand Dezember 2025.

Ein Begriff verdeckt zwei Architekturen

"Multi-Agenten-System" umfasst zwei Konstruktionen, die fast nichts teilen. Ein Subagent ist ein Arbeiter, den ein Orchestrator erzeugt, instruiert und verwirft. Ein Peer-Agent ist eine unabhängige Instanz mit eigenem Lebenszyklus, eigenem Gedächtnis und eigener Identität. Die Branche verwendet beide Begriffe austauschbar. Die Architekturen sind es nicht: Sie unterscheiden sich darin, wem der Zustand gehört und wem die Kontrolle — und daraus folgen Vertrauensgrenzen, Kostenkurven und Teststrategie.

Zwei Fragen trennen die Muster. Erstens: Wem gehört der Kontext — fließt die Arbeit des Aufgerufenen in einen Speicher zurück, den der Aufrufer kontrolliert, oder in einen eigenen? Zweitens: Wem gehört der Lebenszyklus — kann der Aufrufer den Aufgerufenen beliebig erzeugen und beenden? Jede Aussage dieses Artikels lässt sich auf diese zwei Antworten zurückführen.

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

Subagenten sind Delegation in einem Orchestrator

Ein Subagent läuft innerhalb eines einzigen orchestrierenden Prozesses. Der Orchestrator erzeugt ihn mit einem begrenzten Auftrag, der Subagent arbeitet in einem isolierten Kontextfenster, und sein verdichtetes Ergebnis fließt an den Parent zurück. Danach existiert er nicht mehr. Anthropics Research-System, beschrieben am 13. Juni 2025, ist das kanonische Beispiel: Ein Lead-Agent zerlegt die Anfrage, startet drei bis fünf parallele Subagenten und synthetisiert deren Ergebnisse. Claude Code lieferte im Juli 2025 konfigurierbare Subagenten aus — Markdown-Dateien mit Systemprompt und expliziter Tool-Allowlist.

Ebenso wichtig ist, was ein Subagent nicht tut. Er hält keinen dauerhaften Zustand, ist von außen nicht adressierbar und überlebt seinen Parent nicht; Wiederverwendung heißt Neustart mit frischem Auftrag. Das sind keine Lücken. Es sind die Einschränkungen, die das Muster klein genug für eine Analyse halten.

Peer-Agenten sind Instanzen mit eigenem Zustand

Ein Peer-Agent ist eine separat betriebene Instanz: eigener Prozess, eigener Speicher, eigene Task-Queue, eigene Laufzeit. Kein Orchestrator besitzt ihn; Koordination geschieht über Nachrichten. Googles Agent2Agent-Protokoll (A2A), angekündigt am 9. April 2025 mit über 50 Partnern und am 23. Juni 2025 an die Linux Foundation übergeben, standardisiert genau diese Form: Agenten publizieren Fähigkeitsbeschreibungen, tauschen Tasks über HTTP aus und führen langlaufende Arbeit in eigenen Zustandsmaschinen. A2A ergänzt bewusst MCP (November 2024), das einen Agenten mit Werkzeugen verbindet — nicht Agenten untereinander.

Peers sind die richtige Form, wenn Agenten verschiedenen Teams, Anbietern oder Sicherheitsdomänen gehören — wenn kein einzelner Orchestrator alles besitzen kann. Sie sind die falsche Form, wenn ein Team den gesamten Workflow kontrolliert. Dann fügen Peers Netzwerk-Hops, Vertragsversionierung und verteilte Fehlermodi zu einem Problem hinzu, das In-Process-Delegation bereits löst.

Dimension	Subagent	Peer-Agent
Lebenszyklus	Vom Orchestrator erzeugt und beendet	Unabhängig; startet und stoppt selbst
Zustand	Flüchtig; Ergebnis fließt an den Parent	Persistent; eigener Speicher und Task-Zustand
Identität	Läuft unter den Credentials des Aufrufers	Eigene Identität; authentifiziert jeden Aufrufer
Kommunikation	In-Process-Delegation per Tool-Aufruf	Netzwerkprotokoll wie A2A über HTTP
Fehlerdomäne	Auf einen Prozess begrenzt	Verteilt; Teilausfälle sind normal
Kostenhebel	Orchestrator-Prompting und Spawn-Limits	Vertragsdesign und Nachrichtengröße

Vertrauensgrenzen folgen der Eigentümerschaft

Ein Subagent erbt das Vertrauen seines Aufrufers. Er läuft unter denselben Credentials; seine Rechte lassen sich nur einschränken, etwa über Tool-Allowlists. Verifikation ist billig, weil der Parent das vollständige Transkript der Subagenten-Arbeit lesen kann. Ein Peer-Agent steht hinter einer Vertrauensgrenze. Er muss Aufrufer authentifizieren, sein Inneres ist nicht einsehbar, und jede eingehende Nachricht ist ein potenzieller Prompt-Injection-Vektor. A2A behandelt Agenten bewusst als opake Endpunkte — zugleich Interoperabilitätsmerkmal und Verifikationskosten.

Die praktische Regel: Modellieren Sie die Grenze, wie sie ist — nicht, wie es bequem wäre. Wer einen Fremdagenten als Subagenten behandelt, reicht ihm die eigenen Credentials. Wer den eigenen Subagenten als Peer behandelt, bezahlt Authentifizierung und Vertragsaufwand für eine Grenze, die nicht existiert. Beide Fehler sind verbreitet; gefährlich ist nur der erste.

Warum die Unterscheidung die Kosten bestimmt

Die Kostendaten sind öffentlich. Anthropic hat im Juni 2025 gemessen, dass einzelne Agenten etwa das 4-Fache der Token einer Chat-Interaktion verbrauchen, Multi-Agenten-Systeme etwa das 15-Fache. Token-Verbrauch allein erklärte 80 % der Leistungsvarianz in der BrowseComp-Evaluation; ein Opus-4-Lead mit Sonnet-4-Subagenten übertraf einen einzelnen Opus-4-Agenten im internen Research-Eval um 90,2 %. Delegation vervielfacht Token, weil der Parent dreimal zahlt: für das Schreiben des Auftrags, für den Lauf des Arbeiters und für das Lesen des Ergebnisses.

Peers fügen einen zweiten Multiplikator hinzu. Weil kein Speicher geteilt wird, muss jede Nachricht ihren eigenen Kontext tragen, und beide Seiten stellen ihr Verständnis bei jedem Austausch neu her. Persistenter Zustand kostet außerdem im Leerlauf. Die Stellhebel unterscheiden sich entsprechend: Subagenten-Kosten steuert man über Orchestrator-Prompting — Spawn-Anzahl und Aufwandsskalierung —, Peer-Kosten über Vertragsdesign. Multi-Agenten-Architekturen rechnen sich nur, wo der Wert der Aufgabe den Multiplikator deckt; Anthropic hat das offen ausgesprochen.

Warum die Unterscheidung die Testbarkeit bestimmt

Ein Subagent testet sich wie eine Funktion. Der Auftrag ist die Eingabe, die zurückgegebene Zusammenfassung die Ausgabe, und zwischen Läufen überlebt kein Zustand. Eine aufgezeichnete Delegation lässt sich wiederholen und das Ergebnis prüfen; das Orchestrator-Transkript ist eine vollständige Spur. Das Modell bleibt nichtdeterministisch, aber der Prüfstand ist geschlossen: ein Prozess, eine Uhr, kein Netzwerk.

Ein Peer-Agent testet sich wie ein verteiltes System. Zustand überdauert Nachrichten, also braucht jeder Test Auf- und Abbau des Peer-Speichers. Zu den Fehlermodi gehören Timeouts, teilweise erledigte Tasks und Versionsdrift zwischen unabhängig deployten Agenten. Die passende Disziplin ist die der Microservices — Contract-Tests gegen das Protokoll, Mocks an der Nachrichtengrenze — mit nichtdeterministischen Komponenten auf beiden Seiten. Das ist machbar, aber eine Größenordnung mehr Arbeit. Kalkulieren Sie das ein, bevor Sie sich für Peers entscheiden.

Ausblick vom Dezember 2025

Stand Dezember 2025 sind die Produktionssysteme, die nachweislich funktionieren, Orchestrator-Subagenten-Designs; Peer-Deployments sind überwiegend Piloten. Wir erwarten, dass diese Rangfolge 2026 Bestand hat. Delegation innerhalb einer Vertrauensdomäne ist billiger zu betreiben und billiger zu testen, und die meisten Unternehmens-Workflows leben noch in einer Vertrauensdomäne. Peers werden dort wachsen, wo die Grenze zwingend ist — zwischen Unternehmen, zwischen Anbietern —, und das A2A-Projekt unter der Linux Foundation mit über 100 unterstützenden Firmen (Stand Juni 2025) ist das wahrscheinlichste Substrat.

Die offenen Probleme sind unglamourös: Agentenidentität, Abrechnung über Grenzen hinweg, wiederabspielbare Spuren opaker Peers. Wer Peer-Agenten testbar macht, setzt den De-facto-Standard — Protokoll hin oder her. Unser Default bei Blue IT Systems bleibt unverändert: Subagenten zuerst; zum Peer wird eine Komponente erst, wenn eine Vertrauensgrenze es erzwingt.