Ein Multi-Agenten-System ist eine Software-Architektur, in der mehrere spezialisierte KI-Agenten gemeinsam an einer Aufgabe arbeiten: Ein koordinierender Agent zerlegt das Ziel in Teilaufgaben und delegiert sie an Worker-Agenten, die jeweils ein eng umrissenes Mandat, eigene Werkzeuge und ein eigenes Kontextfenster haben. Statt eines Generalisten, der alles können soll, entsteht ein Team aus Spezialisten — mit denselben Vorteilen und denselben Koordinationsproblemen, die auch menschliche Teams kennen.
Der Begriff selbst ist älter als der aktuelle KI-Boom. Multi-Agenten-Systeme sind seit den 1980er-Jahren ein eigenes Forschungsfeld der verteilten künstlichen Intelligenz. Neu ist, dass die einzelnen Agenten heute von Large Language Models angetrieben werden und dadurch Aufgaben übernehmen können, die sich nicht vorab in feste Regeln gießen lassen: Recherche, Klassifikation, Textarbeit, Entscheidungen mit Kontext.
Wie ein Multi-Agenten-System aufgebaut ist
Das Muster, das sich in der Praxis durchgesetzt hat, heißt Orchestrator-Worker (manchmal auch Supervisor-Pattern oder Lead-Agent-Architektur). Es trennt zwei Rollen sauber voneinander: Planung und Ausführung.
Der Orchestrator
Der Orchestrator ist der Projektleiter des Systems. Er nimmt die eigentliche Aufgabe entgegen, entwickelt eine Strategie, zerlegt sie in Teilaufgaben und formuliert für jeden Worker einen präzisen Auftrag: Ziel, erlaubte Werkzeuge, erwartetes Ausgabeformat, Grenzen. Anschließend sammelt er die Ergebnisse ein, bewertet sie, erkennt Lücken und entscheidet, ob weitere Arbeitsschritte nötig sind oder das Gesamtergebnis steht.
Die Qualität des Gesamtsystems hängt überproportional an dieser Rolle. Ein Orchestrator, der schwammige Aufträge verteilt („recherchiere mal zum Markt"), erzeugt Worker, die doppelt arbeiten, sich widersprechen oder ins Leere laufen. Ein guter Orchestrator-Prompt beschreibt Delegation so präzise wie eine gute Führungskraft.
Die Worker-Agenten
Jeder Worker ist ein eigenständiger Agent mit einem engen Mandat: ein Rechercheur, ein Datenprüfer, ein Texter, ein Code-Reviewer. Entscheidend sind drei Eigenschaften. Erstens hat jeder Worker sein eigenes Kontextfenster — er sieht nur, was für seine Teilaufgabe relevant ist, und wird nicht vom Ballast des Gesamtprojekts abgelenkt. Zweitens hat er nur die Werkzeuge, die er braucht: Der Agent, der Rechnungen liest, kann keine überweisen. Drittens arbeiten Worker parallel, wo die Teilaufgaben unabhängig sind — das ist einer der größten Leistungshebel des Musters.
Kommunikation und Tool-Anbindung
Damit die Agenten mit realen Systemen arbeiten können, brauchen sie standardisierte Schnittstellen. Für die Anbindung von Werkzeugen und Datenquellen hat sich das Model Context Protocol (MCP) als offener Standard etabliert; CRM, ERP oder Warenwirtschaft stellen ihre Funktionen als MCP-Server bereit, und jeder Agent im System kann sie nutzen. Für die Kommunikation zwischen Agenten verschiedener Hersteller wurde 2025 zusätzlich das Agent2Agent-Protokoll (A2A) vorgestellt, das Google initiiert und noch im selben Jahr an die Linux Foundation übergeben hat. Beide Standards zielen auf dasselbe Problem: Agenten-Systeme sollen nicht an einen Anbieter gefesselt sein.
Multi-Agent oder Einzel-Agent: wann sich der Aufbau lohnt
Ein Multi-Agenten-System ist kein Selbstzweck. Für viele Aufgaben ist ein einzelner Agent — oder ein deterministischer Workflow ganz ohne Agent — die bessere Wahl. Die Unterschiede im Überblick:
| Kriterium | Einzel-Agent | Multi-Agenten-System |
|---|---|---|
| Geeignete Aufgaben | Klar umrissene Einzelaufgaben mit wenigen Schritten | Komplexe, zerlegbare Aufgaben mit parallelisierbaren Teilschritten |
| Kontextfenster | Ein Fenster für alles — füllt sich schnell mit Ballast | Jeder Worker hat ein frisches, fokussiertes Fenster |
| Fehlerisolation | Ein früher Fehler zieht sich durch den ganzen Lauf | Fehler bleiben im Worker; der Orchestrator kann neu delegieren |
| Token-Kosten | Rund das Vierfache einer Chat-Interaktion | Rund das Fünfzehnfache einer Chat-Interaktion |
| Latenz | Sequenziell, aber kürzere Gesamtkette | Parallelisierung beschleunigt; Koordination kostet Zeit |
| Debugging | Ein Trace, überschaubar | Mehrere Traces; ohne sauberes Logging kaum beherrschbar |
Die Token-Zahlen stammen aus Messungen von Anthropic am eigenen Produktivsystem und markieren den zentralen Zielkonflikt: Multi-Agenten-Systeme kaufen ihre höhere Leistung mit deutlich höherem Rechenaufwand ein. Sie lohnen sich deshalb nur für Aufgaben, deren Ergebnis diesen Aufwand rechtfertigt — Recherche über viele Quellen, komplexe Analysen, Aufgaben mit echter Parallelität. Für eine simple Ticket-Klassifikation ist ein Multi-Agenten-Aufbau Overengineering.
Ein reales Beispiel: Anthropics Research-System
Das am besten dokumentierte produktive Multi-Agenten-System stammt von Anthropic selbst. Die Research-Funktion von Claude arbeitet mit einem Orchestrator (Lead-Agent), der eine Rechercheanfrage zerlegt und mehrere Sub-Agenten parallel auf Teilfragen ansetzt; jeder Sub-Agent durchsucht eigenständig Quellen, bewertet Ergebnisse und liefert an den Orchestrator zurück. In Anthropics internem Benchmark übertraf dieser Aufbau (Claude Opus 4 als Orchestrator, Sonnet-4-Worker) einen Einzel-Agenten mit identischem Spitzenmodell um 90,2 Prozent. Das Engineering-Team hat die Architektur, die Prompt-Prinzipien und die Kostenrechnung in einem ausführlichen Engineering-Bericht offengelegt — inklusive der ernüchternden Zahl, dass Multi-Agenten-Läufe rund das Fünfzehnfache der Tokens einer Chat-Interaktion verbrauchen.
Interessant an dem Bericht ist, wie viel der Erfolgsfaktoren nichts mit dem Modell zu tun hat: präzise Delegations-Prompts, klare Aufgabengrenzen pro Sub-Agent, Werkzeugbeschreibungen, die eine Maschine nicht missverstehen kann, und aufwendiges Tracing für die Fehlersuche. Das deckt sich mit der Praxiserfahrung aus Unternehmensprojekten: Der Engpass ist selten die Intelligenz des Modells, fast immer die Qualität der Arbeitsteilung.
Warum das für den Mittelstand relevant ist
Für mittelständische Unternehmen ist das Muster aus zwei Gründen interessant. Erstens senkt es das Risiko einzelner Agenten: Weil jeder Worker nur begrenzte Rechte und ein enges Mandat hat, ist der Schaden eines Fehlläufers begrenzt — ein zentraler Baustein von Guardrails in Agenten-Systemen. Zweitens spiegelt es die Organisation, die es automatisiert: Ein Unternehmen, das seine Prozesse in Rollen und Verantwortlichkeiten beschreiben kann, kann diese Beschreibung fast wörtlich in eine Agenten-Architektur übersetzen.
Typische Einsatzfelder, in denen sich der Aufbau heute rechnet:
- Recherche und Marktbeobachtung: parallele Auswertung vieler Quellen mit anschließender Synthese.
- Angebots- und Ausschreibungsprüfung: ein Agent extrahiert Anforderungen, einer prüft Machbarkeit, einer kalkuliert.
- Support-Triage: Klassifikation, Wissensrecherche und Antwortentwurf als getrennte, prüfbare Schritte.
- Datenabgleich zwischen Systemen: Extraktion, Validierung und Schreibvorschlag als getrennte Agenten mit getrennten Rechten.
Häufige Missverständnisse
„Mehr Agenten = mehr Intelligenz." Nein. Mehr Agenten bedeuten zunächst nur mehr Koordinationsaufwand und mehr Kosten. Der Leistungsgewinn entsteht durch Parallelität und fokussierte Kontexte — und nur bei Aufgaben, die sich sinnvoll zerlegen lassen. Eine Aufgabe, die sequenziell und einfach ist, wird durch fünf Agenten nicht besser, sondern nur fünfmal teurer.
„Multi-Agenten-Systeme sind autonome Schwärme." In der Unternehmensrealität sind sie das Gegenteil: streng hierarchisch orchestrierte Systeme mit definierten Übergabepunkten, Rechtekonzept und Human-in-the-Loop-Freigaben für alles Irreversible. Frei interagierende Agenten-Schwärme sind ein Forschungsthema, kein Produktionsmuster.
„Das Framework macht die Architektur." Werkzeuge wie LangGraph, CrewAI, das Microsoft Agent Framework (hervorgegangen aus AutoGen) oder das OpenAI Agents SDK nehmen einem die Verdrahtung ab — Zustandsverwaltung, Retries, Übergaben. Die eigentliche Architekturarbeit, nämlich der Zuschnitt der Mandate und die Definition der Erfolgskriterien, bleibt beim Team. Ein schlecht zugeschnittenes System bleibt in jedem Framework schlecht.
Grenzen und offene Probleme
Multi-Agenten-Systeme erben alle Schwächen ihrer Einzelteile und fügen eigene hinzu. Fehler sind kumulativ: Ein Worker, der früh falsch abbiegt, liefert dem Orchestrator plausibel klingenden Unsinn, der ins Endergebnis einsickert. Nicht-Determinismus erschwert das Testen — derselbe Auftrag kann unterschiedliche Pfade nehmen. Und die Angriffsfläche wächst: Jeder Agent, der externe Inhalte liest, ist ein potenzielles Einfallstor für Prompt Injection, und in einem Multi-Agenten-System kann eine kompromittierte Teilantwort andere Agenten anstecken. Produktionsreife heißt deshalb: lückenloses Tracing jeder Delegation, Checkpoints zum Wiederaufsetzen, Evaluation mit realen Testfällen vor jeder Änderung.
Dazu kommt die betriebswirtschaftliche Grenze: Der Fünfzehnfach-Faktor beim Token-Verbrauch ist kein Schönheitsfehler, sondern der Preis des Musters. Wer ihn ignoriert, baut Systeme, deren Stückkosten den Nutzen auffressen. Die nüchterne Reihenfolge lautet deshalb: erst deterministische Workflows für alles Regelbasierte, dann ein einzelner Agent mit engem Mandat, und erst wenn dessen Aufgabe nachweislich zu groß für ein Kontextfenster ist, ein Multi-Agenten-Aufbau.
Ausblick
Die Standardisierung schreitet schnell voran: MCP für die Werkzeug-Anbindung liegt seit Ende 2025 bei der Linux Foundation, A2A für die Agent-zu-Agent-Kommunikation ebenso. Damit zeichnet sich eine Zukunft ab, in der Agenten verschiedener Hersteller in einem System zusammenarbeiten — der Orchestrator eines Anbieters delegiert an Spezial-Agenten eines anderen. Gleichzeitig zeigen Prognosen wie die von Gartner (über 40 Prozent der Agentic-AI-Projekte werden bis Ende 2027 abgebrochen), dass die Architektur allein kein Erfolgsgarant ist. Die Unternehmen, die heute mit kleinen, eng geschnittenen Systemen Erfahrung sammeln und ihre Prozesse sauber dokumentieren, werden die Standards nutzen können; die anderen werden Folien präsentieren.
Häufige Fragen zu Multi-Agenten-Systemen
Was ist der Unterschied zwischen einem Multi-Agenten-System und einem Workflow?
Ein Workflow (etwa in n8n) folgt einem festen, von Menschen vorgezeichneten Pfad — gleiche Eingabe, gleicher Ablauf. In einem Multi-Agenten-System entscheiden die Agenten selbst, welche Schritte und Werkzeuge sie nutzen. Das macht sie geeignet für Aufgaben ohne festen Ablauf und ungeeignet für alles, was sich deterministisch abbilden lässt.
Wann lohnt sich ein Multi-Agenten-System statt eines einzelnen Agenten?
Wenn die Aufgabe sich in unabhängige Teilaufgaben zerlegen lässt, die parallel bearbeitet werden können, oder wenn ein einzelnes Kontextfenster für die Aufgabe nachweislich zu klein ist. Als Faustregel: erst Workflow, dann Einzel-Agent, dann Multi-Agent — und bei jedem Schritt prüfen, ob der Mehrwert den vervielfachten Token-Verbrauch trägt.
Welche Frameworks gibt es für Multi-Agenten-Systeme?
Verbreitet sind LangGraph (LangChain), CrewAI, das Microsoft Agent Framework (Nachfolger von AutoGen) und das OpenAI Agents SDK. Für die Werkzeug-Anbindung ist das Model Context Protocol der herstellerübergreifende Standard, für die Kommunikation zwischen Agenten das A2A-Protokoll. Die Framework-Wahl ist dabei weniger entscheidend als der saubere Zuschnitt der Agenten-Mandate.
Wie teuer ist ein Multi-Agenten-System im Betrieb?
Messungen von Anthropic beziffern den Token-Verbrauch auf rund das Fünfzehnfache einer normalen Chat-Interaktion (Einzel-Agenten: rund das Vierfache). Dazu kommen Kosten für Monitoring, Evaluation und Pflege. Ein Multi-Agenten-System rechnet sich deshalb nur für Aufgaben, deren Erledigung deutlich mehr wert ist als diese Betriebskosten.
Sind Multi-Agenten-Systeme sicherer als einzelne Agenten?
Teils. Die Aufteilung in Worker mit minimalen Rechten begrenzt den Schaden einzelner Fehlläufe — das ist ein echter Sicherheitsgewinn. Gleichzeitig wächst die Angriffsfläche für Prompt Injection mit jedem Agenten, der externe Inhalte liest. Sicherheit entsteht nicht durch das Muster selbst, sondern durch Rechtekonzept, Freigabeprozesse und lückenloses Logging.