Multi-Agent-Systeme richtig planen: Architektur, Kontrolle und Betrieb

Ein einzelner KI-Agent kann einen klar abgegrenzten Prozess beschleunigen. Sobald mehrere Agenten recherchieren, planen, Entscheidungen vorbereiten und Systeme ansteuern, entsteht jedoch kein größerer Chatbot, sondern ein verteiltes Softwaresystem. Genau hier entscheidet die Multi-Agent-Systeme-Architektur darüber, ob aus einem vielversprechenden Prototyp ein kontrollierbarer Unternehmensdienst wird – oder eine schwer nachvollziehbare Kette autonomer Aufrufe.

Für IT-Organisationen ist das keine akademische Detailfrage. Multi-Agent-Systeme verbinden Sprachmodelle mit Datenquellen, Fachanwendungen und Automatisierung. Damit verschieben sie Architekturfragen, die aus klassischen Integrationen bekannt sind: Identitäten, Berechtigungen, Zuständigkeiten, Fehlerbehandlung, Nachvollziehbarkeit und Kosten. Neu ist vor allem, dass ein Teil der Ablaufsteuerung probabilistisch ist. Das verlangt andere Leitplanken als ein deterministischer Workflow.

Was eine Multi-Agent-Systeme-Architektur leisten muss

Ein Agent kombiniert typischerweise ein Modell mit Instruktionen, einem begrenzten Kontext, Werkzeugen und einem Ziel. In einer Multi-Agent-Architektur übernehmen mehrere solcher Einheiten unterschiedliche Rollen. Ein Planungsagent zerlegt etwa einen Auftrag, Spezialagenten bewerten Dokumente oder führen Analysen aus, ein Kontrollagent prüft Ergebnisse gegen Regeln. Das kann sinnvoll sein, wenn Aufgaben mehrere Domänen berühren oder wenn unabhängige Prüfungen die Qualität erhöhen.

Dass sich solche Architekturen zunehmend standardisieren, zeigt unter anderem das Agent2Agent-Protokoll (A2A) für die Kommunikation und Zusammenarbeit zwischen Agenten. Entscheidend ist dabei nicht die Anzahl der Agenten, sondern die saubere Definition ihrer Aufgaben, Schnittstellen und Verantwortlichkeiten.

Die zentrale Erkenntnis lautet: Mehr Agenten sind kein Architekturziel. Sie sind ein Mittel zur Trennung von Verantwortlichkeiten. Wenn ein einzelner, gut eingegrenzter Agent mit festem Toolzugriff dieselbe Aufgabe verlässlich erledigt, schafft ein Agentennetz vor allem zusätzlichen Koordinationsaufwand. Die Grenze verläuft nicht zwischen „ein Agent“ und „viele Agenten“, sondern zwischen einer klaren Prozesslogik und einer Aufgabe, deren Weg sinnvollerweise zur Laufzeit bestimmt wird.

Klassische Workflows bleiben deshalb relevant. Ein Workflow ist dort die bessere Wahl, wo Reihenfolge, Freigaben und Ausnahmebehandlung fachlich vorgegeben sind. Agenten können innerhalb einzelner Schritte arbeiten: Informationen verdichten, Varianten erzeugen, unstrukturierte Inhalte klassifizieren oder einen nächsten Arbeitsschritt begründen. Die Prozesshoheit sollte aber nicht ohne Not an ein Modell delegiert werden.

Die Architektur beginnt mit dem Kontrollpunkt

Die kritischste Komponente ist häufig nicht der einzelne Agent, sondern die Orchestrierung. Sie entscheidet, welcher Agent welchen Auftrag erhält, welche Daten er sehen darf, wann ein Ergebnis als ausreichend gilt und wann ein Vorgang abgebrochen oder an einen Menschen übergeben wird. Diese Funktion kann als zentraler Orchestrator, als zustandsbasierter Graph oder als ereignisgetriebene Koordination umgesetzt sein.

Ein zentraler Orchestrator erleichtert zunächst Observability, Richtlinienprüfung und Kostenkontrolle. Er kann Aufrufe begrenzen, Zeitbudgets setzen und für jeden Vorgang eine eindeutige Ausführungsspur führen. Dafür entsteht ein potenzieller Engpass, und die Logik des Orchestrators kann schnell komplex werden. Dezentralere Muster, etwa Agenten mit Nachrichtenkanälen, passen besser zu langen oder asynchronen Aufgaben. Sie verlangen aber besonders sorgfältige Regeln gegen Schleifen, widersprüchliche Ergebnisse und unklare Besitzverhältnisse.

Praktisch bewährt sich ein expliziter Zustandsraum: Auftrag, Zwischenartefakte, verwendete Quellen, Toolaufrufe, Freigaben und Ergebnisstatus liegen nicht nur im flüchtigen Modellkontext. Sie werden strukturiert gespeichert und mit einer Ausführungs-ID verknüpft. So kann ein Vorgang nach einem Fehler fortgesetzt, geprüft oder wiederholt werden, ohne dass ein Agent seine eigene Historie rekonstruieren muss.

Rollen statt allgemeiner Alleskönner

Agenten sollten möglichst eng beschriebene Aufgaben haben. Ein Rechercheagent darf Informationen finden und Quellen bewerten, aber keine Änderung in einem ITSM-System auslösen. Ein Ausführungsagent erhält nur die Werkzeuge, die für seine fachlich definierte Aktion erforderlich sind. Ein Prüfer sollte im Idealfall nicht dieselben Instruktionen, denselben Kontext und dieselben Fehlerquellen wie der erzeugende Agent besitzen.

Diese Rollentrennung verbessert nicht automatisch die inhaltliche Qualität. Mehrere Modelle können denselben Irrtum überzeugend wiederholen. Sie reduziert aber die Reichweite eines Fehlers und macht Prüfregeln sichtbar. Bei sicherheitsrelevanten oder kostenwirksamen Aktionen reicht eine Selbstprüfung durch ein Modell ohnehin nicht aus. Dort gehören deterministische Kontrollen, Richtlinien-Engines und je nach Risiko menschliche Freigaben in den Ablauf.

Kontext, Daten und Tools sind die eigentliche Angriffsfläche

Modelle sind nur ein Teil des Systems. In Unternehmensumgebungen liegt das größere Risiko oft an den Grenzen: beim Abruf von Dokumenten, beim Zugriff auf APIs und beim Übergang in operative Systeme. Manipulierte Inhalte können beispielsweise über indirekte Prompt Injection versuchen, das Verhalten eines Agenten zu verändern. NIST behandelt solche Angriffe ausdrücklich in seiner Taxonomie zu Angriffen und Gegenmaßnahmen bei Machine-Learning- und GenAI-Systemen. Auch OWASP adressiert bei agentischen Systemen unter anderem Tool Misuse sowie Identity & Privilege Abuse.

Darum braucht die Multi-Agent-Systeme-Architektur eine eigene Vermittlungsschicht für Tools. Sie erzwingt erlaubte Parameter, prüft Eingaben, protokolliert Aufrufe und vergibt kurzlebige, aufgabengebundene Zugangsdaten. Der Agent sollte keine breit nutzbaren Service-Credentials kennen. Besonders bei schreibenden Schnittstellen gilt: Lesezugriff und Ausführungsrechte sind getrennte Sicherheitsklassen.

Auch Retrieval braucht Grenzen. Nicht jedes auffindbare Dokument gehört in den Kontext eines Agenten. Die Zugriffsentscheidung muss vor dem Abruf erfolgen und auf der Identität des aufrufenden Nutzers, dem Auftrag sowie der Agentenrolle basieren. Ein nachgelagerter Filter ist keine gleichwertige Alternative, weil vertrauliche Inhalte dann bereits verarbeitet worden sein können.

Für CIOs und CISOs ist ein weiterer Punkt entscheidend: Delegation darf Berechtigungen nicht ausweiten. Wenn ein Nutzer nur Leserechte auf einen Vorgang hat, darf ein Agent im Namen dieses Nutzers daraus keine Änderung ableiten. Das Prinzip wirkt banal, wird aber in frühen Prototypen häufig durch technische Sammelkonten oder zu großzügige Toolrechte unterlaufen.

Governance wird zur Laufzeitaufgabe

Data und AI Governance endet nicht beim freigegebenen Modell oder bei einer dokumentierten Datenklassifikation. In Agentensystemen entsteht Governance auch während der Ausführung. Welche Daten wurden tatsächlich verwendet? Welche Regel hat einen Toolaufruf erlaubt? Welcher Agent hat eine Empfehlung erzeugt, und welche Person hat eine Aktion freigegeben?

Der OWASP Multi-Agentic System Threat Modeling Guide betrachtet genau diese zusätzliche Komplexität von Multi-Agent-Systemen. Inter-Agent-Kommunikation, Autonomie und gemeinsam genutzte beziehungsweise weitergegebene Informationen können zusätzliche Angriffspfade schaffen und müssen deshalb als Bestandteile der Gesamtarchitektur betrachtet werden.

Dafür braucht es Telemetrie, die fachliche und technische Sicht zusammenführt. Ein hilfreicher Trace enthält mindestens Auftrag und Identität, beteiligte Agenten, Modell- und Prompt-Versionen, Kontextquellen, Toolaufrufe, Entscheidungen des Orchestrators, Latenzen, Kosten und Ergebnisstatus. Sensible Inhalte gehören dabei nicht unkontrolliert in Logs. Protokollierung muss Datenminimierung, Aufbewahrungsfristen und Zugriffsrechte berücksichtigen.

Die Messung der Qualität ist ebenfalls mehrdimensional. Fachliche Korrektheit allein reicht nicht. Prüfe zusätzlich, ob der richtige Datenraum genutzt wurde, ob der Agent seine Toolgrenzen eingehalten hat, ob er unnötige Schleifen ausgelöst hat und ob Entscheidungen reproduzierbar begründet werden können. Offline-Evaluierungen mit kuratierten Fällen sind der Startpunkt. Vor dem produktiven Einsatz brauchen Teams zudem Tests für Fehlereingaben, manipulierte Inhalte, nicht verfügbare Tools und widersprüchliche Agentenergebnisse.

Betrieb: Nicht nur Modelle, sondern Systeme verändern sich

Im Betrieb verändert sich mehr als die Modellversion. APIs werden angepasst, Dokumentenbestände wachsen, Berechtigungen ändern sich, und fachliche Regeln entwickeln sich weiter. Deshalb sollten Prompts, Toolbeschreibungen, Richtlinien und Orchestrierungsgraphen wie Anwendungscode versioniert, getestet und kontrolliert ausgerollt werden.

Auch die technische Infrastruktur rund um Agenten entwickelt sich schnell. Ein Beispiel ist das Model Context Protocol (MCP). Die aktuelle MCP-Spezifikation definiert eine standardisierte Schnittstelle, über die Anwendungen Kontext und Werkzeuge für Sprachmodelle bereitstellen können. Solche Entwicklungen zeigen, warum Unternehmen nicht nur Modelle, sondern auch Protokolle, Tool-Schnittstellen und Berechtigungskonzepte als versionierte Bestandteile ihrer Agentenarchitektur behandeln sollten.

Ein sinnvoller Einführungsweg beginnt mit einem Prozess, dessen Nutzen messbar und dessen Schadenspotenzial begrenzt ist. Zunächst kann das System Empfehlungen oder Entwürfe liefern, während Menschen entscheiden und die Ergebnisse markieren. Erst wenn Qualitätskriterien, Fehlermuster und Kontrollmechanismen belastbar sind, kommen begrenzte schreibende Aktionen in Betracht. Die Reihenfolge ist kein Zeichen mangelnden Muts, sondern eine Voraussetzung für verantwortbaren Betrieb.

Wichtig sind auch technische Abbruchbedingungen. Jeder Auftrag braucht Obergrenzen für Dauer, Anzahl der Agentenschritte, Toolaufrufe und Kosten. Ein Agentennetz ohne solche Budgets kann durch Missverständnisse, fehlerhafte Zustände oder externe Antworten unnötig lange weiterarbeiten. Ebenso braucht es einen definierten Fallback: Was geschieht bei einem Modellfehler, einer nicht erreichbaren Datenquelle oder einem Ergebnis mit zu geringer Sicherheit?

Architekturentscheidungen an Geschäftsrisiko koppeln

Nicht jeder Anwendungsfall benötigt dieselbe Tiefe. Ein internes System zur Vorbereitung technischer Wissensartikel stellt andere Anforderungen als ein Agent, der Konfigurationsänderungen in einer produktiven Plattform vornimmt. Mit wachsender Autonomie und Wirkung steigen die Anforderungen an Identitätsmanagement, Freigaben, Tests, Auditierbarkeit und Wiederherstellbarkeit.

Diese Einordnung sollte früh gemeinsam mit Fachverantwortlichen, Security, Datenschutz, Architektur und Betrieb erfolgen. Nicht als spätes Gate, sondern als Teil des Systemdesigns. So wird sichtbar, wo Agenten tatsächlich Entscheidungen vorbereiten dürfen, wo sie nur Informationen verdichten sollen und wo ein konventioneller Workflow die bessere Lösung bleibt.

Der sinnvollste erste Entwurf einer Multi-Agent-Systeme-Architektur beginnt daher nicht mit der Frage, welches Modell den besten Agenten baut. Beginne mit einem konkreten Auftrag, einer klaren Schadensgrenze und einem überprüfbaren Kontrollpunkt. Wenn diese drei Dinge präzise sind, kann aus Agentic AI ein gestaltbarer Bestandteil deiner Unternehmens-IT werden.