Multi-Agent – Was du jetzt wissen musst

Ein Multi-Agent-System besteht aus mehreren spezialisierten KI-Agenten, die arbeitsteilig an einer gemeinsamen Aufgabe arbeiten. Statt eines einzigen generalistischen Modells übernimmt jeder Agent einen klar definierten Teilschritt (Recherche, Analyse, Validierung, Ausgabe) und koordiniert sich mit den anderen über einen Orchestrator oder Message-Bus. Das Ergebnis: bessere Fehler-Isolation, parallele Verarbeitung und die Möglichkeit, pro Teilschritt das jeweils stärkste Modell einzusetzen.

Stand: Mai 2026. Die Wachstums- und Verbreitungszahlen in diesem Beitrag stammen aus dem Databricks-Report «2026 State of AI Agents» (publiziert Januar 2026, Wachstum gemessen Juni bis Oktober 2025); Modell- und Framework-Namen entwickeln sich schnell weiter.

Warum explodiert das Interesse gerade jetzt?

Die Databricks-Auswertung von 20’000 Organisationen weltweit dokumentiert ein Wachstum von 327 Prozent bei Multi-Agent-Deployments innerhalb von vier Monaten (gemessen Juni bis Oktober 2025). Das ist kein gradueller Anstieg, das ist ein Kipp-Punkt. Parallel dazu setzen bereits 78 Prozent der befragten Unternehmen zwei oder mehr LLM-Familien ein (GPT, Claude, Llama, Gemini oder Qwen), oft je nach Aufgabentyp kombiniert.

Der Treiber ist nicht Neugierde, sondern Produktivitätsdruck. Dieselbe Auswertung zeigt: Unternehmen, die strukturierte Bewertungstools für ihre KI-Ausgaben einsetzen, bringen fast sechsmal mehr Projekte in Produktion. Unternehmen mit formalem KI-Governance-Framework sogar über zwölfmal mehr. Multi-Agent ist damit kein Architektur-Experiment mehr, sondern der Unterbau für skalierbare KI-Produktion.

Was unterscheidet ein Multi-Agent-System von einem klassischen Chatbot?

Ein klassischer Chatbot (auch ein gut geprompteter GPT-5 oder Claude Sonnet) verarbeitet eine Anfrage sequenziell in einem einzigen Kontext-Fenster. Das funktioniert gut für überschaubare Aufgaben. Sobald ein Prozess aber mehrere abhängige Schritte, unterschiedliche Datenquellen oder parallele Analyse-Pfade hat, stösst ein einzelner Agent an seine Grenzen.

Die wichtigsten strukturellen Unterschiede:

• Spezialisierung statt Generalist: Jeder Agent ist auf seinen Teilschritt optimiert: Ein Retrieval-Agent bekommt ein anderes Modell und andere Tools als ein Code-Execution-Agent.
• Parallelverarbeitung: Mehrere Agenten können gleichzeitig unterschiedliche Aspekte einer Aufgabe bearbeiten, was Latenz bei komplexen Pipelines deutlich reduziert.
• Fehler-Isolation: Wenn ein Agent fehlschlägt, kann das System neu routen oder den Schritt neu starten, ohne den gesamten Prozess abzubrechen.
• Modell-Flexibilität: Teure Frontier-Modelle nur dort, wo sie nötig sind; günstige, schnelle Modelle für einfache Routing- oder Extraktionsschritte.

Ein Multi-Agent-System ist nur so stark wie sein schwächster Orchestrator. Die Agenten-Logik ist trivial; die Schwierigkeit liegt im State-Management zwischen den Schritten.

Einordnung der Beirat-Redaktion

Wann lohnt sich eine Multi-Agent-Architektur, und wann nicht?

Die ehrliche Antwort: für die meisten einfachen Anwendungsfälle lohnt sie sich nicht. Ein einzelner Sonnet-Call mit sorgfältig strukturiertem Prompt ist billiger, schneller zu debuggen und einfacher zu warten als ein System mit fünf koordinierten Agenten. Multi-Agent zahlt sich aus, wenn mindestens zwei der folgenden Bedingungen zutreffen:

1. Die Aufgabe lässt sich in klar trennbare, sequenzielle oder parallele Teilschritte zerlegen, die voneinander abgegrenzt sind.
2. Einzelne Teilschritte erfordern unterschiedliche Tools, Datenquellen oder Modell-Typen, zum Beispiel Retrieval plus Code-Ausführung plus Validierung.
3. Die Gesamtaufgabe übersteigt ein realistisches Kontext-Fenster eines einzelnen Modells oder erfordert mehrere unabhängige Reasoning-Durchläufe.
4. Du benötigst Auditierbarkeit pro Teilschritt: Regulatorische Anforderungen oder interne Governance verlangen eine nachvollziehbare Entscheidungskette.

ERGO ordnet Multi-Agent als einen der zentralen Unternehmens-KI-Trends 2025/2026 ein und beschreibt den Kernnutzen als Fähigkeit, komplexe Geschäftsprozesse abzubilden, die für einen einzelnen Agenten zu breit oder zu lang sind. Als Gegenbeispiel gilt: ein einfacher FAQ-Bot, ein Klassifikations-Dienst oder ein Zusammenfassungs-Tool. Dort bringt Multi-Agent nur Overhead.

Welche Architekturen und Tools sind 2026 relevant?

Drei Muster dominieren die Praxis, je nach Anforderung:

1. Orchestrator-Subagent-Muster

Ein Manager-Agent zerlegt die Aufgabe, weist Teilaufgaben an spezialisierte Subagenten zu und konsolidiert deren Output. Anthropic beschreibt dieses Muster (Orchestrator-Workers) in seinen Agent-Guides; für Unternehmens-Deployments ist es aus unserer Sicht der stabilste Einstiegspunkt. Geeignet für strukturierte Prozesse mit vorhersehbarem Ablauf.

# Vereinfachtes Orchestrator-Muster mit Anthropic SDK
from anthropic import Anthropic
client = Anthropic()

def orchestrator(task: str) -> str:
    # Schritt 1: Manager-Agent zerlegt Aufgabe
    plan = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        messages=[{"role": "user", "content": f"Zerlege diese Aufgabe in 3 Teilschritte: {task}"}]
    )
    # Schritt 2: Subagenten verarbeiten Teilschritte parallel
    # Schritt 3: Konsolidierung
    return plan.content[0].text

2. Peer-to-Peer-Muster (komponierbare Agenten)

Agenten kommunizieren direkt miteinander ohne zentralen Orchestrator. Thinkia beschreibt im Mai 2026 «komponierbare Multi-Agenten-Systeme» als aufkommenden Ansatz, bei dem jeder Agent selbst entscheidet, wen er für den nächsten Schritt kontaktiert. Flexibler, aber deutlich schwieriger zu debuggen und zu auditieren.

3. Spezialist-Pool mit Router

Ein schlanker Router-Agent klassifiziert eingehende Anfragen und leitet sie an den passenden Spezialisten weiter. Gut geeignet, wenn du bereits mehrere funktionsfähige Einzel-Agenten hast und diese strukturiert zusammenführen willst. In der Praxis ist dies oft das Einstiegsmuster beim Umstieg von Single-Agent auf Multi-Agent.

Auf Framework-Ebene sind derzeit relevant:

Framework	Merkmal
LangGraph (LangChain)	Graph-basierter State-Machine-Ansatz, gut für komplexe Ablaufsteuerung
AutoGen (Microsoft)	Peer-to-Peer-Kommunikation zwischen Agenten, starke Community
CrewAI	Rollenbasierte Agenten-Definition, einsteigerfreundlich, schnell produktiv
Anthropic Agent SDK	Nativ für Claude-Modelle, direkte Tool-Use-Integration
Google Agent Development Kit (ADK)	Eng integriert mit Gemini und Google Cloud, v1.0 allgemein verfügbar seit Mai 2025 (ADK 2.0 seit Mai 2026)

Einen kuratierten Überblick über Agenten-Werkzeuge für den praktischen Einsatz im DACH-Raum findest du in unserem DACH-Agenten-Guide.

Was kostet ein Multi-Agent-Pilotprojekt realistisch?

Die grösste Kostenfalle ist nicht das Modell, sondern der Entwicklungsaufwand für State-Management und Fehlerbehandlung. Als Richtwerte für einen internen Piloten mit einem dreiköpfigen Entwicklungsteam im DACH-Raum (Stand Q2 2026):

• Aufwand Konzeption und Architektur: 3–5 Tage: Aufgaben-Zerlegung, Agent-Definitionen, Tool-Auswahl
• Aufwand Implementierung MVP: 10–20 Tage, je nach Komplexität der Teilschritte und Anzahl Agenten
• Laufende API-Kosten: Bei 1’000 Prozess-Durchläufen täglich mit Claude Sonnet und Haiku gemischt ca. 80–200 CHF/Monat, abhängig stark von Kontext-Länge pro Agent
• Evaluation-Setup: Ohne strukturiertes Evals-Framework werden Produktionsprobleme spät entdeckt. Die Databricks-Auswertung belegt den 6x-Produktivitätsvorteil von Bewertungstools, diesen Aufwand nicht einsparen.

Der häufigste Fehler in DACH-Piloten: Agenten-Granularität zu fein gewählt. Zehn Agenten für einen Prozess, der mit drei gut designten Agenten dieselbe Qualität liefern würde, verdreifacht den Debugging-Aufwand ohne Mehrwert.

Häufige Fragen

Muss man alle Agenten mit demselben Modell betreiben?

Nein, und das ist einer der Hauptvorteile. 78 Prozent der Unternehmen in der Databricks-Studie mischen bereits mehrere LLM-Familien. Typisch ist: ein starkes Frontier-Modell (Claude Sonnet, GPT-5) für Reasoning-intensive Schritte, ein schnelles und günstiges Modell (Haiku, GPT-5 mini, Llama 4) für Routing, Klassifikation und einfache Extraktion.

Wie handhabt man geteilten State zwischen Agenten?

State-Management ist die technisch kritischste Entscheidung. Die drei gängigen Ansätze sind: zentraler State-Store (z.B. Redis oder eine einfache Datenbank), den jeder Agent liest und schreibt; Message-Passing über einen Bus (Kafka, SQS), bei dem Agenten nur auf Nachrichten reagieren; oder in-memory State im Orchestrator, der jeden Agenten mit dem relevanten Kontext versorgt. Für die meisten DACH-Unternehmens-Piloten ist der Orchestrator-with-in-memory-State-Ansatz die wartbarste Startoption.

Fazit: Wann einsteigen, wann warten?

327 Prozent Wachstum in vier Monaten bedeutet: der Markt setzt Multi-Agent-Systeme produktiv ein, nicht nur als Experiment. Wenn du Geschäftsprozesse hast, die sich in drei oder mehr trennbare Teilschritte zerlegen lassen und heute entweder manuell überbrückt oder mit mehreren Einzeltools bearbeitet werden, dann ist jetzt der richtige Zeitpunkt für einen strukturierten Piloten.

Wenn dein primärer Anwendungsfall ein FAQ-Bot, ein Zusammenfassungs-Service oder ein einfaches Klassifikations-Tool ist: bleib beim einzelnen Modell mit gutem Prompt-Design. Du bekommst 90 Prozent des Nutzens ohne den Overhead einer verteilten Agenten-Architektur.

Konkrete nächste Schritte für einen soliden Einstieg:

1. Einen bestehenden Prozess mit 3–5 Teilschritten identifizieren, der heute manuell koordiniert wird.
2. Agenten-Grenzen nach Verantwortlichkeit, nicht nach technischer Bequemlichkeit ziehen.
3. Evaluation-Framework vor dem ersten Agenten aufsetzen, nicht danach.
4. Mit Orchestrator-Subagent-Muster starten; Peer-to-Peer erst einführen, wenn der einfachere Ansatz an echte Grenzen stösst.