20.12.2025 AI Engineering5 Minuten Lesezeit

Peer-Agenten und Subagenten aus ersten Prinzipien

Subagenten und Peer-Agenten stehen für unterschiedliche Architekturen, nicht für zwei Bezeichnungen derselben Idee. Wir leiten die Trennlinie aus zwei Grundfragen ab — wem gehören Kontext und Lebenszyklus? — und zeigen, wie daraus Vertrauensgrenzen, Token-Kosten und Testbarkeit folgen. Grundlage sind Messwerte aus Anthropics Multi-Agenten-Research-System und das A2A-Protokoll, Stand Dezember 2025.

Ein Begriff verdeckt zwei Architekturen

Der Sammelbegriff "Multi-Agenten-System" verdeckt zwei Konstruktionen, die wenig gemeinsam haben. Ein Subagent ist ein Arbeiter, den ein Orchestrator erzeugt, instruiert und anschließend verwirft. Ein Peer-Agent dagegen ist eine unabhängige Instanz mit eigenem Lebenszyklus, Gedächtnis und eigener Identität. Die Branche verwendet beide Begriffe oft austauschbar; die Architekturen sind es nicht. Wem Zustand und Kontrolle gehören, bestimmt 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.

Daraus folgt eine praktische Regel: Modellieren Sie die tatsächliche Grenze, nicht die bequemste. Wer einen Fremdagenten wie einen Subagenten behandelt, reicht ihm die eigenen Credentials. Wer dagegen einen internen Subagenten zum Peer erklärt, bezahlt Authentifizierung und Vertragsaufwand für eine Grenze, die gar nicht existiert. Beide Fehler sind verbreitet; sicherheitskritisch ist vor allem 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 unspektakulär, aber grundlegend: Agentenidentität, Abrechnung über Systemgrenzen hinweg und wiederabspielbare Spuren opaker Peers. Wer diese Testbarkeit belastbar löst, prägt den De-facto-Standard — unabhängig vom Protokoll. Unser Default bei Blue IT Systems bleibt deshalb klar: zuerst Subagenten; zum Peer wird eine Komponente erst, wenn eine reale Vertrauensgrenze es erzwingt.