Multi-Agenten-Systeme im Unternehmen: Wann lohnen sie sich und wie verbindet man sie

Ein Produktionsunternehmen baute einen einzigen Agenten, der alles erledigen sollte: Kundenanfragen beantworten, Angebote generieren, Verkaufstermine vereinbaren und wöchentliche Verkaufsberichte erstellen. Nach drei Monaten funktionierte der Agent, aber immer schlechter. Die Angebote waren weniger präzise, weil der Kontext durch Kundenanfragen belegt war. Die Berichte wurden verspätet erstellt, weil die Koordination mit dem CRM mit der Service-Warteschlange kollidierte. Die Kosten pro Anfrage stiegen im Vergleich zum Pilotprojekt um das Dreifache. Die Lösung war nicht ein besseres Modell, sondern die Aufteilung in vier spezialisierte Einheiten mit einem Router-Agenten an der Spitze.

Dies ist ein typisches Szenario für die Überlastung eines einzelnen Agenten. Nicht jedes Szenario erfordert jedoch eine Multi-Agenten-Architektur.

Orchestrierung ist ein Mechanismus, der Aufgaben an Agenten verteilt, deren Ergebnisse sammelt und zu einem kohärenten Ergebnis zusammenführt. Es gibt drei Muster:

Router (Klassifikator + Dispatch). Der Koordinationsagent analysiert die Eingabe und leitet sie an den passenden Spezialagenten weiter. Ein Kunde fragt nach einer Rechnung? Er wird an den Finanzagenten weitergeleitet. Fragt er nach dem Lieferstatus? Er wird an den Logistikagenten weitergeleitet. Der Router führt keine Ergebniszusammenführung durch, sondern leitet nur weiter. Einfach, kostengünstig, leicht zu debuggen.

Pipeline (Sequenz). Die Aufgabe durchläuft aufeinanderfolgende Agenten wie eine Montagelinie: Agent A sammelt Daten, Agent B analysiert, Agent C formatiert den Bericht. Jeder Agent erhält das Ergebnis des vorherigen als Eingabe. Funktioniert gut bei der Dokumentenverarbeitung, der Angebotserstellung und mehrstufiger Recherche.

Netzwerk (Mesh). Agenten können sich gegenseitig in beliebiger Reihenfolge aufrufen, abhängig von den Anforderungen der Aufgabe. Das flexibelste Muster, aber auch am schwierigsten zu überwachen. Das Risiko von Schleifen ist real, wenn es an harten Aufrufgrenzen und einem Human-Handoff-Mechanismus fehlt.

Die meisten geschäftlichen Implementierungen beginnen mit einem Router oder einer Pipeline. Das Netzwerk bleibt einer Phase vorbehalten, in der die beiden einfacheren Muster offensichtlich nicht ausreichen.

Es gibt hier keine klare Grenze. Es gibt jedoch Signale, die darauf hindeuten, dass es Zeit für eine Aufteilung ist:

Der Kontext ist zu klein für alle Rollen. Wenn ein Agent gleichzeitig die Preispolitik, die Kundenhistorie, die Reklamationsregeln und das Berichtsformat im Kontext halten muss, wird das Kontextfenster (context window) zum Engpass. Spezialisierung bedeutet einen kleineren System-Prompt und treffendere Antworten.

Aufgaben können parallel ablaufen. Eine sequentielle Pipeline für zehn unabhängige Kunden dauert zehnmal so lange wie eine einzelne Aufgabe. Parallele Aufrufe spezialisierter Agenten können die Latenz um 60-70% reduzieren, wenn die Aufgaben keine Abhängigkeiten untereinander haben.

Verschiedene Aufgaben erfordern verschiedene Modelle. Die Intent-Klassifizierung ist eine Aufgabe für ein kleines, günstiges Modell (Antwort in 200 ms). Die Synthese eines mehrseitigen Angebots erfordert ein größeres Modell mit längerem Kontext. Ein LLM-Router zwischen den Agenten wählt das Modell passend zur Aufgabe aus, was die Inferenzkosten um 30-50% senkt, ohne die Qualität bei kritischen Schritten zu beeinträchtigen.

Verantwortungsgrenzen haben rechtliche Bedeutung. Wenn ein Teil des Prozesses personenbezogene Daten betrifft (RODO, DPIA), während ein anderer nicht, erleichtert die Isolierung von Agenten mit separaten Guardrails und separaten Logs die Dokumentation der Compliance, die durch den AI Act gefordert wird.

Der Koordinator (Orchestrator) ist das Herzstück des Systems. Seine einzige Verantwortung besteht darin: eine Aufgabe entgegenzunehmen, zu entscheiden, wer sie bearbeitet, das Ergebnis zu sammeln, eine Antwort zurückzugeben oder zu eskalieren. Der Koordinator sollte keine domänenspezifischen Aufgaben selbst ausführen, da er sonst zu demselben überlasteten Agenten wird, vor dem wir geflohen sind.

Praktische Prinzipien der Verbindung:

Verträge zwischen Agenten. Jeder Spezialagent hat ein dokumentiertes Schema für Ein- und Ausgaben (structured output). Der Koordinator geht nicht davon aus, dass er das Format kennt — er liest das Schema und validiert das Ergebnis, bevor er es weiterleitet. Fehlende Validierung ist die Quelle stiller Fehler in der Pipeline.

Aufruflimit und Timeout pro Agent. Jeder Aufruf hat ein hartes Timeout (z. B. 30 Sekunden) und ein Wiederholungslimit (z. B. 2 Retries mit exponentiellem Backoff). Nach Überschreiten des Limits gibt der Agent ein Fehlerergebnis mit Kontext zurück, und der Koordinator entscheidet: Eskalation zum Menschen oder Fallback auf einen einfacheren Pfad.

Gemeinsames Log-Register. Jeder Agent schreibt in ein gemeinsames Log-System mit einer Sitzungs-ID und einer Aufruf-ID. Ohne dies wird das Debugging eines Ereignisses, das durch drei Agenten gegangen ist, zu einer mehrstündigen Untersuchung. Dies ist eine Anforderung an Observability und gleichzeitig die Grundlage für einen Audit-Trail, der mit dem AI Act konform ist.

Human-Gate für nicht umkehrbare Aktionen. Unabhängig davon, welcher Agent eine Aktion ausführt (E-Mail senden, Rechnung erstellen, Status im ERP ändern), wenn die Aktion nicht umkehrbar ist, wird sie angehalten und wartet auf die Bestätigung eines Operators. Dies gilt für jeden Agenten im Netzwerk, nicht nur für den Koordinator.

Mehr über die Architektur von Tools und Schleifen findest du im Artikel über mehrstufige Agenten und in der Beschreibung von Agenten, die Arbeit ausführen.

Die Multi-Agenten-Architektur hat reale Kosten. Es lohnt sich, diese vor der Implementierung zu kennen:

Schleifen und Deadlocks. Agent A ruft Agent B auf, der Agent A mit einem anderen Kontext aufruft. Ohne einen harten Abhängigkeitsgraphen und einen Zähler für die Aufruftiefe kann sich das System in einer schwer zu erkennenden Schleife verfangen. Symptom: Ein starker Anstieg der Inferenzkosten ohne proportionalen Anstieg des Werts.

Höhere Überwachungskosten. Jeder zusätzliche Agent ist ein separater Punkt für Metriken, Alarme und Logs. Die Überwachung eines Systems mit fünf Agenten kostet proportional mehr als die Überwachung eines einzelnen. Bevor du implementierst, beurteile die Gesamtbetriebskosten mit dem Inference-Kalkulator und dem ROI-Kalkulator.

Schwierigeres Debugging. Ein Fehler am Ende der Pipeline muss rückwärts durch jeden Agenten verfolgt werden. Ohne ein gutes Trace-System (Sitzungs-ID, die durch die gesamte Pipeline propagiert wird) dauert die Diagnose um ein Vielfaches länger als in einem Ein-Agenten-System.

Netzwerklatenzen summieren sich. Jeder Aufruf zwischen Agenten (insbesondere in einer Cloud-Architektur) fügt Latenz hinzu. In einer Pipeline mit fünf sequentiellen Agenten kann die Gesamtantwortzeit die für den Benutzer akzeptable Schwelle überschreiten, selbst wenn jeder Agent für sich schnell ist.

Multi-Agenten sind eine Investition, kein Shortcut. Wenn das Problem durch einen besseren Prompt, eine erweiterte RAG-Datenbank oder die Aufteilung in zwei unabhängige Prozesse statt in ein vernetztes System gelöst werden kann, mach das zuerst. Prüfe auch die Kosten für die Wartung eines KI-Agenten und den Artikel über Sicherheit von KI-Agenten, da jeder zusätzliche Agent die Angriffsfläche vergrößert.

Für die meisten Unternehmen sind 2-4 spezialisierte Agenten plus ein Koordinator ein guter Ausgangspunkt. Das reicht aus, um mehrere domänengetrennte Prozesse zu bedienen, und die operative Komplexität bleibt überschaubar. Systeme mit mehr als 8-10 Agenten machen nur in sehr großen Organisationen mit einer umfangreichen DevOps-Infrastruktur für KI Sinn.

Nein. Das ist einer der Hauptvorteile der Multi-Agenten-Architektur. Ein Intent-Klassifikator kann auf einem kleinen, schnellen Modell laufen (7B, lokal), während ein Agent für die Berichtsynthese ein größeres Cloud-Modell nutzt. Die Auswahl des Modells pro Aufgabe senkt die Inferenzkosten um 30-50%, ohne die Qualität bei kritischen Schritten zu beeinträchtigen.

Der Schlüssel ist die Propagierung einer einzigen Sitzungs-ID durch die gesamte Pipeline. Jeder Agent loggt Eingabe, Ausgabe und Verarbeitungszeit mit derselben ID. Bei einem Vorfall filterst du die Logs nach der ID und rekonstruierst die Aufrufsequenz. Ohne dies wird selbst eine einfache Pipeline zur Blackbox.

Das hängt von der Risikoklassifizierung ab. Wenn ein Agent im Netzwerk Entscheidungen trifft, die in die Hochrisikokategorie fallen (z. B. Kreditscoring, Auswahl von Bewerbern), unterliegt das gesamte System den Anforderungen des AI Act als Hochrisikosystem. Die Isolierung von Agenten entbindet nicht von der Pflicht zur Dokumentation und Auditierbarkeit des gesamten Prozesses.

Immer. Ein einzelner Agent ermöglicht einen schnelleren Piloten, einfacheres Debugging und geringere Implementierungskosten. Muster für die Aufteilung und Verträge zwischen Agenten lassen sich am besten auf Basis realer Daten aus einem funktionierenden System entwerfen, nicht aus der Theorie. Nach 4-8 Wochen Pilotphase sieht man, wo ein einzelner Agent tatsächlich versagt und wie man die Verantwortlichkeiten aufteilen sollte.