Der Konferenzkreislauf hat sich auf eine Erzählung geeinigt: Die Zukunft des Enterprise-AI ist Multi-Agent-Systeme. Orchestratoren, Subagents, Spezialistenrollen, Agent-zu-Agent-Protokolle. Die Demos sind beeindruckend. Sie sind auch fast universell die falsche Antwort auf die Frage, die die Organisation tatsächlich lösen muss.
Multi-Agent ist keine Architektur. Es ist eine Entscheidung, die eine spezifische Reihe von Bedingungen erfordert, um gerechtfertigt zu sein.
Das Multi-Agent-Hype-Muster
CrewAI, LangGraph, AutoGen und eine wachsende Liste von Orchestrierungs-Frameworks sind darauf ausgelegt, mehrere agents zu koordinieren. Die implizite Botschaft des Tooling-Ökosystems: Wenn ein agent nützlich ist, sind mehrere agents nützlicher. Die Realität: Die meisten Aufgaben, die als Multi-Agent-Workflows konzipiert werden, produzieren bessere Ergebnisse von einem einzelnen, gut umgrenzten agent mit guten Tools, einem expliziten Kontextfenster und einer klaren Definition von Fertiggestellt.
Das Hinzufügen von agents fügt Orchestrierungskomplexität hinzu. Der Orchestrator muss Arbeit verteilen, den Zustand über agents hinweg verwalten, Fehler an agent Grenzen handhaben, Outputs sammeln und synthetisieren und trotz Variabilität im Output jedes Subagents ein kohärentes Ergebnis aufrechterhalten. Das Debuggen eines Fehlers in einem Multi-Agent-System erfordert das Tracing durch agent Grenzen, wo Zustand transformiert, zusammengefasst oder verloren wurde. Jeder agent, der einem System hinzugefügt wird, multipliziert die Debugging-Oberfläche.
Die Frage, die jedem Multi-Agent-Design vorangehen sollte: Hat diese Aufgabe strukturelle Eigenschaften, die ein einzelner agent nicht handhaben kann? Wenn die Antwort nein ist, einen einzelnen agent deployen. Die Raffinesse liegt in der Architekturentscheidung, nicht in der Anzahl der agents.
Die drei legitimen Fälle für mehrere Agents
Drei strukturelle Eigenschaften rechtfertigen Multi-Agent-Design. Wenn keiner zutrifft, mit einem einzelnen agent fortfahren.
Fall 1: Echte Parallelität. Aufgaben, die wirklich unabhängig sind, ohne Abhängigkeit zwischen Arbeitseinheiten, können auf isolierte agents verteilt werden, die gleichzeitig laufen. Ein einzelner agent, der 500 Leads sequentiell verarbeitet, dauert fünf Stunden. Fünfhundert agents, die jeweils einen Lead verarbeiten, dauern Minuten. Der Orchestrator verteilt, die Subagents verarbeiten, der Orchestrator sammelt und synthetisiert. Keine Inter-Agent-Kommunikation erforderlich. Jeder Subagent erhält vollständigen, in sich geschlossenen Kontext für seine Einheit.
Anwendungen: Prospect-Anreicherung, Seiten-Audit über eine Website, Dokumentenklassifizierung in Bulk, Übersetzungsüberprüfung über Sprachpaare, Vertragsklausel-Extraktion aus einem großen Vertrags-Corpus. Die gemeinsame Eigenschaft: Jede Arbeitseinheit ist unabhängig von jeder anderen Einheit.
Fall 2: Adversariales Review. Ein zweiter agent mit einer anderen Rolle überprüft den Output des ersten agents, ohne Zugang zu den Überlegungen oder Zwischenschritten des ersten agents. Das ist keine Qualitätsprüfung. Es ist eine strukturelle Eigenschaft: Der Reviewer kann nicht sehen, was der Implementierer gesehen hat, sodass er seine Entscheidungen nicht rationalisieren kann. Es produziert frischere Kritik, deckt Annahmen auf, die der Implementierer unbewusst getroffen hat, und fängt Reasoning-Fehler ab, die Self-Review nie fängt, weil der überprüfende Geist bereits dieselben Prämissen akzeptiert.
Das Muster: Ein Implementierer-agent produziert Output. Ein Reviewer-agent erhält diesen Output plus explizite Bewertungskriterien, aber nicht den Kontext, Plan oder die Zwischenschritte des Implementierers. Ein Resolver-agent behandelt substantielle Meinungsverschiedenheiten. Enterprise-Anwendungen: Vertragsgestaltung plus unabhängige Klauselüberprüfung, Architekturvorschlag plus unabhängige Sicherheitsüberprüfung, Kundenprojekt plus unabhängige Risikobewertung.
Fall 3: Rollenspezialisierung, die wirklich unterschiedlichen Kontext erfordert. Ein Recherche-agent benötigt breiten Zugang zu Web-Quellen, große Kontextfenster zum Lesen und minimale Einschränkungen für das Abrufen. Ein Schreib-agent benötigt Markensprachen-Richtlinien, Stileinschränkungen, Zielgruppenspezifikationen und Content-Architektur. Ein Redaktions-agent benötigt Kriterienkatalog, Qualitätsstandards und die Fähigkeit, gegen ein definiertes Rubrik zu bewerten. Alle drei in ein einzelnes Kontextfenster zu zwingen degradiert jede Funktion: Der für Recherche erforderliche Kontext verunreinigt die fokussierten Einschränkungen, die für das Schreiben erforderlich sind, die die klaren Standards für die Redaktion verunreinigen.
Wenn die drei Fälle nicht vorhanden sind, ist ein einzelner agent mit gut definierten Tools und explizitem Kontext die richtige Architektur.
Das Parallelitätsmuster in der Praxis
Die Parallelitätsarchitektur ist ein Orchestrator-Subagent-Muster mit strikter Isolation. Jeder Subagent erhält vollständigen, in sich geschlossenen Kontext für seine spezifische Arbeitseinheit. Er kommuniziert nicht mit anderen Subagents. Er greift nicht auf gemeinsam genutzten Zustand zu. Er produziert Output, der einem definierten Schema entspricht.
Orchestrator
├── verteilt: [Einheit_1, Einheit_2, ... Einheit_N]
├── jeder Subagent: empfängt(vollständiger_Kontext_für_Einheit_i)
│ produziert(strukturiertes_Output_Schema)
└── sammelt: [Output_1, Output_2, ... Output_N]
synthetisiert: AbschlussberichtKeine Inter-Agent-Kommunikation auf der Subagent-Ebene. Jegliche Koordination geschieht auf der Orchestrator-Ebene, nachdem alle Subagent-Outputs gesammelt wurden. Der Orchestrator ist immer noch ein einzelner Entscheidungspunkt.
OpenSwarm (VRSEN, MIT-Lizenz) ist ein Open-Source-Framework für dieses Muster, das um deliverable-fokussierte Swarms anstatt um konversationelle Agent-Koordination herum gestaltet ist. Das GitHub-Repository war Anfang 2026 mit Tausenden von Stars aktiv [ESTIMATIVA: aktuelle Statistiken vor dem Zitieren verifizieren]; aktuellen Wartungsstatus vor der Adoption verifizieren.
Der zu vermeidende Fehler-Modus im Parallelitätsmuster: Subagents, die während der Ausführung Zustand teilen oder miteinander kommunizieren. Sobald Inter-Agent-Kommunikation erforderlich ist, sind die Einheiten nicht wirklich unabhängig, und die Parallelitätsarchitektur ist nicht gerechtfertigt. Als sequentielle oder graphbasierte Orchestrierung neu gestalten.
Das Adversariale-Review-Muster
Das adversariale Review-Muster funktioniert wegen dem, was der Reviewer nicht sieht. Der Implementierer-agent produziert Output mit vollem Zugang zu Ziel, Kontext, Einschränkungen und seinen eigenen Zwischenüberlegungen. Der Reviewer-agent erhält nur den Output plus explizite Überprüfungskriterien. Der Reviewer hat keinen Zugang zu den Überlegungen oder dem Entscheidungsprozess des Implementierers.
Diese Isolation ist wichtig. Self-Review scheitert, weil der den Output überprüfende Geist bereits dieselben Prämissen akzeptiert, die ihn produziert haben. Ein Implementierer, der eine Architektur wegen einer bestimmten Einschränkung gewählt hat, wird diese Einschränkung beim Self-Review nicht hinterfragen. Ein Reviewer, der die Einschränkung nie gesehen hat, wird hinterfragen, ob die Architektur angemessen ist. Die frische Perspektive ist eine strukturelle Eigenschaft der Isolation, kein Persönlichkeitsmerkmal des Reviewers.
Resolver-agent: behandelt Meinungsverschiedenheiten zwischen Implementierer und Reviewer, indem er beide Positionen gegen angegebene Kriterien analysiert. Produziert ein Urteil mit explizitem Reasoning. Das Urteil ist deterministischer Input für den nächsten Schritt.
Enterprise-Anwendungen, bei denen dieses Muster messbaren Wert hinzufügt: Vertragsgestaltung mit unabhängiger Klauselüberprüfung (fängt Mehrdeutigkeiten auf, die der Gestalter normalisiert hat), Kundenangebote mit Risikoüberprüfung (fängt Commitments auf, die der vertriebsorientierte Gestalter rationalisiert hat), Architekturdesign mit Sicherheitsüberprüfung (fängt Annahmen auf, die der Lösungsarchitekt akzeptiert hat) und technische Analyse mit unabhängiger Validierung (fängt Rechenfehler und fehlerhafte Prämissen auf).
Kontext-Budget als Multi-Agent-Design-Einschränkung
Die Designeinschränkung, ohne die die meisten Multi-Agent-Systeme gebaut werden: Jeder agent hat ein endliches Kontext-Budget, und Inter-Agent-Übergaben müssen explizit darüber sein, welche Informationen zwischen agents und in welcher Form sich bewegen.
Das Eisberg-Prinzip: Das Kontextfenster enthält nur das, was immer für die spezifische Funktion dieses agents sichtbar sein muss. Alles andere ist über Tools, Gedächtnisabruf oder Retrieval zugänglich, nicht standardmäßig in das Kontextfenster geladen. Ein agent, der die vollständige History aller Kontextfenster vorheriger agents trägt, akkumuliert bei jedem Schritt Verschmutzung.
Übergabe-Disziplin: Der Recherche-agent liefert strukturierten Output mit Quellen, Schlüsselbefunden und expliziten Prämissen. Er gibt keine rohen Web-Inhalte weiter. Der Datenanalyst liefert kuratierte Tabellen und validierte Befunde. Er gibt keine rohen Abfrageergebnisse weiter. Jede Übergabe ist auch ein Qualitäts-Gate: Der Output muss der Input-Spezifikation des empfangenden agents entsprechen, bevor er übergeben wird.
Ohne Übergabe-Disziplin verstärken Multi-Agent-Systeme Kontext-Verschmutzung statt sie zu reduzieren. Jeder agent fügt seinem Rauschen das des vorherigen agents hinzu. Der endgültige Output ist eine Synthese angehäufter Verwirrung.
Jede Übergabe ist auch eine architektonische Naht, wo Fehler eingeführt werden können, ohne an dem produzierenden agent erkannt zu werden. Ein Recherche-agent, der eine Zusammenfassung mit einem sachlichen Fehler produziert, gibt diesen Fehler als Grundwahrheit an den Schreib-agent weiter. Explizite Qualitätsprüfungen bei jeder Übergabe einbauen, nicht nur am endgültigen Output.
Das Kriterium, das die Entscheidung klärt
Vor dem Design eines Multi-Agent-Systems drei Fragen:
- Hat diese Aufgabe wirklich unabhängige Arbeitseinheiten, die parallel laufen können?
- Erfordert diese Aufgabe adversariales Review, bei dem der Reviewer die Überlegungen des Implementierers nicht sehen darf?
- Erfordert diese Aufgabe wirklich unterschiedlichen Kontext für verschiedene Funktionen, die nicht in einem Fenster koexistieren können?
Wenn die ehrliche Antwort auf alle drei nein ist, erzielt ein gut entworfener agent mit guten Tools und klarem Kontext das Ziel bei niedrigeren Kosten, niedrigerer Latenz und geringerer Debugging-Komplexität.
Der Datenpunkt, der die kommerzielle Realität kontextualisiert: Salesforce Agentforce erreichte über 540 Millionen USD ARR mit über 18.000 Kunden [ESTIMATIVA: über Salesforce-Gewinnmitteilungen verifizieren]. Der Großteil der deployten Anwendungsfälle in dieser Basis sind Single-Agent- oder einfache sequentielle Workflows. Der Enterprise-AI-Markt ist nicht primär ein Markt für orchestrierte Schwärme. Es ist ein Markt für zuverlässige, umgrenzte Automatisierung, die auditierbare Ergebnisse produziert.
Die Raffinesse liegt im Wählen der richtigen Architektur für die Aufgabe. Nicht im Deployen der komplexesten.
Multi-Agent ist die richtige Wahl für eine kleine Menge von Aufgaben mit spezifischen strukturellen Eigenschaften. Für die Mehrheit der Enterprise-Automatisierungsprobleme ist es Overengineering, das Wartungslast schafft, das Debuggen verkompliziert und den einfachen Wert verdeckt, den das Unternehmen tatsächlich benötigte.
Zuerst den einzelnen agent korrekt bauen. Dann entscheiden, ob die Aufgabenstruktur mehr erfordert.
Für Enterprise-Teams, die agent Architekturen gestalten, kartiert der AI Opportunity Sprint die geeignete Struktur für Ihren spezifischen Anwendungsfall, bevor der Build beginnt.