Multi-Agent — Was du jetzt wissen musst

TL;DR: Multi-Agent-Systeme wachsen laut einer Databricks-Auswertung von 20.000 Organisationen innerhalb von vier Monaten um 327 Prozent. Wer komplexe Geschäftsprozesse mit klar trennbaren Teilschritten hat, sollte jetzt ernsthaft evaluieren — alle anderen zahlen nur mehr für dasselbe Ergebnis.

Ein Multi-Agent-System besteht aus mehreren spezialisierten KI-Agenten, die arbeitsteilig an einer gemeinsamen Aufgabe arbeiten. Statt einem einzigen generalistischen Modell ü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.

Table of Contents

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 (Stand Q2 2026). 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-4o 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.
Informatik Aktuell, Architektur-Guide Multi-Agent 2026

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:

Die Aufgabe lässt sich in klar trennbare, sequenzielle oder parallele Teilschritte zerlegen, die voneinander abgegrenzt sind.
Einzelne Teilschritte erfordern unterschiedliche Tools, Datenquellen oder Modell-Typen — zum Beispiel Retrieval plus Code-Ausführung plus Validierung.
Die Gesamtaufgabe übersteigt ein realistisches Kontext-Fenster eines einzelnen Modells oder erfordert mehrere unabhängige Reasoning-Durchläufe.
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 dokumentiert dieses Muster in den Claude-Agent-Guides als den stabilsten Einstiegspunkt für Unternehmens-Deployments. 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. Laut Databricks-Auswertung ist dies das häufigste Einstiegsmuster beim Umstieg von Single-Agent auf Multi-Agent.

Auf Framework-Ebene sind derzeit relevant:

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): Tightly integrated mit Gemini und Google Cloud, seit Q1 2026 GA

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-4o) für Reasoning-intensive Schritte, ein schnelles und günstiges Modell (Haiku, GPT-4o mini, Llama 3) 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:

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