Agentische KI benötigt Systemsichtweise

Modellierung, Simulation, Planung und Orchestrierung von Multi-Agenten-Systemen

Kurzbeschreibung: Multi-Agenten-KI ist nicht nur eine Sammlung miteinander kommunizierender Sprachmodelle. Sie ist ein verteiltes, zustandsbehaftetes und teilweise stochastisches dynamisches System. Der Beitrag zeigt, wie sich solche Systeme modellieren, simulieren, planen, orchestrieren und auf Systemebene bewerten lassen.

Agentische KI wird derzeit überwiegend als Software- und Integrationsaufgabe behandelt. Ein Sprachmodell erhält Werkzeuge, Speicher und eine Rolle. Mehrere solcher Agenten werden über Nachrichten, Übergaben oder einen zentralen Orchestrator miteinander verbunden. Anschließend wird getestet, ob das System eine vorgegebene Aufgabe erfolgreich bearbeitet.

Für einfache Demonstratoren kann dieser Ansatz ausreichen.

Sobald agentische Systeme jedoch länger laufende, geschäftskritische oder technisch anspruchsvolle Aufgaben übernehmen sollen, verändert sich die Problemklasse. Dann reicht es nicht mehr, einzelne Prompts, Tools oder Agenten isoliert zu optimieren. Das Verhalten des Gesamtsystems entsteht aus den Interaktionen seiner Komponenten.

Ein Multi-Agenten-System ist deshalb nicht lediglich eine Gruppe von Sprachmodellen mit unterschiedlichen Rollen.

Es ist ein verteiltes, zustandsbehaftetes und teilweise stochastisches dynamisches System mit Rückkopplungen, Verzögerungen, Ressourcenbeschränkungen und potenziell emergentem Verhalten.

Diese Perspektive eröffnet einen anderen Zugang zur Entwicklung agentischer KI. Im Mittelpunkt stehen nicht nur Implementierung und Prompt Design, sondern:

Systemarchitektur,
Zustands- und Informationsmodellierung,
Aufgabenplanung,
Ressourcenallokation,
Kommunikationsstrukturen,
Fehlerausbreitung,
Stabilität und Abbruchbedingungen,
Simulation alternativer Architekturen,
Evaluation auf Systemebene.

Damit wird agentische KI zu einer Aufgabe der Systemtechnik.

1. Vom einzelnen Agenten zum gekoppelten System

Ein einzelner KI-Agent kann abstrakt durch einige grundlegende Komponenten beschrieben werden:

einen internen Zustand,
ein Ziel oder eine Bewertungsfunktion,
einen aktuellen Informationsstand,
ein Modell zur Auswahl nächster Aktionen,
Zugriff auf Werkzeuge und externe Systeme,
Speicher,
Regeln für Abbruch, Rückfrage oder Eskalation.

Bereits ein einzelner Agent ist damit mehr als ein einmaliger Modellaufruf. Er durchläuft eine Folge von Zuständen. Jeder Schritt verändert den Informationsstand und beeinflusst spätere Entscheidungen.

Bei mehreren Agenten entsteht zusätzlich eine Interaktionsstruktur. Agenten können:

Aufgaben delegieren,
Zwischenergebnisse austauschen,
sich gegenseitig kontrollieren,
konkurrierende Lösungsvorschläge erzeugen,
gemeinsam planen,
auf gemeinsame Ressourcen zugreifen,
einander widersprechen oder verstärken.

In aktuellen Systemen werden dafür unterschiedliche Muster eingesetzt. OpenAI unterscheidet beispielsweise zwischen einer zentralen Steuerung durch einen Manager-Agenten und dezentraleren Übergaben zwischen spezialisierten Agenten (OpenAI: A Practical Guide to Building Agents). Anthropic beschreibt für sein Research-System eine Architektur, in der ein führender Agent Teilaufgaben plant und parallele Subagenten zur Informationsgewinnung einsetzt (Anthropic: How We Built Our Multi-Agent Research System). Google DeepMinds Co-Scientist verbindet spezialisierte Agenten zur Erzeugung, Kritik und Weiterentwicklung wissenschaftlicher Hypothesen (Google DeepMind: Co-Scientist).

Diese Beispiele zeigen, dass die Interaktionsstruktur selbst zu einem wesentlichen Bestandteil der Leistung wird.

Die Qualität eines Agentensystems lässt sich nicht einfach aus der Qualität seiner einzelnen Modelle ableiten.

2. Warum mehr Agenten nicht automatisch ein besseres System ergeben

Die intuitive Erwartung lautet häufig: Wenn ein Agent nützlich ist, müssen mehrere spezialisierte Agenten noch leistungsfähiger sein.

Das ist nicht zwingend der Fall.

Jeder zusätzliche Agent erzeugt neue Möglichkeiten, aber auch zusätzliche Kosten und Fehlermodi:

weitere Modellaufrufe,
längere Laufzeiten,
mehr Kommunikationsschritte,
potenziellen Informationsverlust bei Übergaben,
widersprüchliche Zwischenergebnisse,
zusätzliche Zustände,
komplexere Fehlersuche,
schwerer reproduzierbares Verhalten.

Ein Multi-Agenten-System kann daher schlechter sein als ein gut entworfener Einzelagent mit geeigneten Werkzeugen.

Die relevante Frage lautet nicht:

Wie viele Agenten können wir einsetzen?

Sondern:

Welche funktionale Zerlegung der Aufgabe rechtfertigt zusätzliche Agenten und Interaktionen?

Mehrere Agenten sind insbesondere dann sinnvoll, wenn:

Aufgaben tatsächlich parallelisierbar sind,
unterschiedliche Kompetenzprofile benötigt werden,
unabhängige Prüfung einen messbaren Nutzen erzeugt,
Kontextgrenzen durch Arbeitsteilung überwunden werden,
verschiedene Perspektiven systematisch verglichen werden sollen,
Zuständigkeiten und Zugriffsrechte getrennt werden müssen.

Dagegen können zusätzliche Agenten schädlich sein, wenn sie nur künstlich Rollen simulieren, dieselben Informationen wiederholt verarbeiten oder unklare Verantwortlichkeiten erzeugen.

Die Zahl der Agenten ist damit eine Architekturvariable, keine Qualitätskennzahl.

3. Typische Fehlermodi agentischer Systeme

Die Fehler eines Agentensystems unterscheiden sich teilweise von den Fehlern eines einzelnen Modells.

Schleifen und fehlende Konvergenz

Agenten können Aufgaben wiederholt weiterreichen, dieselben Informationen erneut prüfen oder immer neue Unteraufgaben erzeugen. Ohne klare Zustands- und Abbruchlogik kann ein System hohe Kosten verursachen, ohne einem Ergebnis näher zu kommen.

Fehlerverstärkung

Ein falsches Zwischenergebnis kann von nachfolgenden Agenten als gesicherte Information übernommen werden. Durch Wiederholung und gegenseitige Bestätigung gewinnt es scheinbare Plausibilität.

Informationsverlust

Bei jeder Übergabe wird entschieden, welcher Kontext weitergegeben wird. Zu starke Kompression kann relevante Randbedingungen entfernen. Zu wenig Kompression erzeugt dagegen überfüllte Kontexte und steigende Kosten.

Widersprüchliche Ziele

Agenten können lokale Ziele verfolgen, die nicht mit dem globalen Systemziel übereinstimmen. Ein Agent optimiert beispielsweise Vollständigkeit, ein anderer Geschwindigkeit und ein dritter Kosten. Ohne übergeordnete Priorisierung können daraus inkonsistente Entscheidungen entstehen.

Doppelte Bearbeitung

Mehrere Agenten können dieselbe Aufgabe unabhängig bearbeiten, obwohl dies keinen zusätzlichen Informationsgewinn erzeugt. Dadurch steigen Laufzeit und Kosten.

Blockaden und Deadlocks

Agenten können auf Informationen oder Aktionen anderer Agenten warten, während keine Komponente den nächsten Schritt ausführt.

Unkontrollierte Werkzeugnutzung

Ein Agent kann ungeeignete Tools auswählen, Aktionen zu häufig wiederholen oder auf veralteten Ergebnissen weiterarbeiten.

Fehlerhafte Eskalation

Ein System kann zu früh einen Menschen einbeziehen und dadurch seinen Automatisierungsnutzen verlieren. Es kann aber auch zu spät eskalieren und kritische Entscheidungen auf unsicherer Grundlage treffen.

Manipulation und Agent Hijacking

Agenten, die externe Inhalte verarbeiten und Werkzeuge bedienen, können durch manipulierte Eingaben beeinflusst werden. NIST untersucht deshalb Evaluationsverfahren, die direkt in agentische Workflows integriert werden und als adversariale Prüfinstanzen wirken (NIST: Building Evaluation Probes into Agentic AI).

Diese Fehlermodi betreffen nicht nur einzelne Antworten. Sie betreffen Abläufe, Zustandsübergänge und Systemarchitekturen.

4. Architekturvarianten

Es gibt keine allgemein optimale Multi-Agenten-Architektur. Ihre Eignung hängt von Aufgabenstruktur, Unsicherheit, Kommunikationskosten und Anforderungen an Kontrolle ab.

Zentraler Orchestrator

Ein zentraler Orchestrator zerlegt die Aufgabe, weist Teilaufgaben zu, sammelt Ergebnisse und entscheidet über den weiteren Ablauf.

Vorteile:

klare Verantwortlichkeit,
gute globale Übersicht,
einfache Durchsetzung von Prioritäten,
zentrale Kosten- und Sicherheitskontrolle.

Nachteile:

Single Point of Failure,
möglicher Engpass,
hoher Kontextbedarf beim Orchestrator,
starke Abhängigkeit von dessen Planungsqualität.

Supervisor-Worker-Architektur

Ein Supervisor koordiniert spezialisierte Worker. Im Unterschied zu einem allgemeinen Orchestrator besitzen die Worker häufig klar definierte Fähigkeiten und Schnittstellen.

Diese Architektur eignet sich für Aufgaben, die in wiederkehrende und vergleichsweise stabile Teilprozesse zerlegt werden können.

Hierarchische Agentensysteme

Komplexe Aufgaben werden über mehrere Koordinationsebenen organisiert. Ein übergeordneter Agent plant grob, darunterliegende Agenten strukturieren Teilbereiche weiter.

Hierarchien können Skalierung ermöglichen, erzeugen aber zusätzliche Übergabe- und Informationsverluste.

Dezentrale Peer-to-Peer-Koordination

Agenten kommunizieren direkt miteinander und treffen lokale Entscheidungen.

Vorteile:

hohe Flexibilität,
geringere Abhängigkeit von einer zentralen Instanz,
potenziell gute Parallelisierbarkeit.

Nachteile:

schwierigere globale Kontrolle,
höhere Kommunikationskomplexität,
mögliche Koordinationsprobleme,
schwerer nachvollziehbare Verantwortlichkeiten.

Blackboard-System

Agenten schreiben Zwischenergebnisse in einen gemeinsamen Arbeits- oder Wissensraum. Andere Agenten reagieren auf den dort sichtbaren Zustand.

Diese Architektur reduziert direkte Punkt-zu-Punkt-Kommunikation und kann asynchrone Bearbeitung erleichtern. Gleichzeitig erfordert sie ein robustes Zustands- und Konfliktmanagement.

Markt- und Auktionsmechanismen

Agenten konkurrieren um Aufgaben oder Ressourcen. Preise, Gebote oder Nutzenwerte steuern die Allokation.

Solche Mechanismen können sinnvoll sein, wenn Agenten heterogene Kosten und Kompetenzen besitzen. Sie verlangen jedoch geeignete Bewertungsfunktionen und können strategisches Verhalten erzeugen.

Dynamisch erzeugte Subagenten

Ein Agent erzeugt abhängig von der aktuellen Aufgabe weitere spezialisierte Agenten.

Das erhöht Anpassungsfähigkeit, macht aber Ressourcenverbrauch und Systemstruktur schwerer vorhersehbar.

Die Auswahl einer Architektur sollte deshalb nicht allein durch Framework-Konventionen bestimmt werden. Sie sollte aus einer Analyse der Aufgaben- und Systemstruktur folgen.

5. Eine formale Systemsicht

Ein agentisches System lässt sich als zeitdiskretes dynamisches System beschreiben:

x_{t+1}=F(x_t,a_t,m_t,u_t,\xi_t)

Dabei bezeichnet:

(x_t) den globalen und die lokalen Systemzustände,
(a_t) die Aktionen der Agenten,
(m_t) die ausgetauschten Nachrichten,
(u_t) externe Anforderungen, Ereignisse oder Nutzereingaben,
(\xi_t) stochastische Modellantworten, Toolfehler und Umweltunsicherheit.

Für den Agenten (i) kann zusätzlich eine lokale Dynamik formuliert werden:

x_{i,t+1}=f_i(x_{i,t},o_{i,t},m_{i,t},a_{i,t},\xi_{i,t})

mit der lokalen Beobachtung (o_{i,t}).

Die Menge der Agenten und ihre Kommunikationsstruktur lassen sich als zeitabhängiger Graph darstellen:

G_t=(V_t,E_t)

Die Knoten (V_t) entsprechen Agenten oder funktionalen Komponenten. Die Kanten (E_t) beschreiben mögliche Informations- oder Kontrollflüsse.

Diese Darstellung erlaubt es, Fragen systematisch zu formulieren:

Erreicht das System einen zulässigen Endzustand?
Unter welchen Bedingungen konvergiert der Ablauf?
Welche Zustände sind unerwünscht oder kritisch?
Welche Informationen sind für eine Entscheidung erforderlich?
Wie sensitiv reagiert das System auf Fehler einzelner Agenten?
Welche Kommunikationskanten sind notwendig?
Welche Architektur minimiert Kosten bei vorgegebener Erfolgswahrscheinlichkeit?

Die formale Beschreibung muss nicht vollständig analytisch lösbar sein. Ihr Wert liegt bereits darin, Zustände, Übergänge, Abhängigkeiten und Zielgrößen explizit zu machen.

6. Agentische Systeme als ereignisdiskrete Systeme

Viele Agentensysteme entwickeln sich nicht in kontinuierlicher Zeit, sondern durch diskrete Ereignisse:

eine Aufgabe wird erzeugt,
ein Agent wird aktiviert,
ein Tool liefert ein Ergebnis,
eine Nachricht trifft ein,
eine Frist wird überschritten,
ein Prüfschritt schlägt fehl,
eine Eskalation wird ausgelöst.

Damit bieten sich Methoden der ereignisdiskreten Simulation an.

Eine Simulation kann unter anderem abbilden:

Bearbeitungs- und Wartezeiten,
Warteschlangen,
parallele Aufgaben,
begrenzte Modell- oder Toolkapazitäten,
Prioritäten,
Wiederholungen,
Ausfälle,
Abbruchbedingungen.

Dies ermöglicht die Untersuchung von Leistungsgrößen wie:

Durchsatz,
mittlere Bearbeitungszeit,
Tail Latency,
Auslastung,
Kosten pro Vorgang,
Schleifenhäufigkeit,
Eskalationsquote,
Ressourcenkonflikte.

Gerade vor einem produktiven Einsatz kann eine solche Simulation klären, ob eine Architektur unter realistischen Last- und Fehlerannahmen tragfähig ist.

7. Stochastische Modellierung und Unsicherheit

Agentische Systeme sind inhärent stochastisch.

Selbst bei identischen Eingaben können Sprachmodelle unterschiedliche Antworten erzeugen. Tools können variable Laufzeiten besitzen. Datenquellen können unvollständig sein. Externe Umgebungen können sich verändern.

Eine realistische Bewertung muss daher Verteilungen und nicht nur einzelne Testläufe betrachten.

Relevante Größen sind beispielsweise:

Erfolgswahrscheinlichkeit,
Verteilung der Bearbeitungsdauer,
Kostenverteilung,
Wahrscheinlichkeit von Wiederholungsschleifen,
Ausfallwahrscheinlichkeit,
bedingte Fehlerwahrscheinlichkeit nach einem bestimmten Zwischenschritt,
Robustheit gegenüber veränderten Eingaben.

Monte-Carlo-Simulationen können unterschiedliche Realisierungen des Agentenverhaltens erzeugen. Sensitivitätsanalysen zeigen, welche Parameter die Systemleistung dominieren. Seltene, aber kritische Fehlerszenarien können durch gezielte Importance-Sampling- oder Stress-Test-Ansätze untersucht werden.

Die Aussage „Das System hat in einem Test funktioniert“ ist für ein stochastisches System kaum ausreichend.

Benötigt wird eine Aussage der Form:

Mit welcher Wahrscheinlichkeit erreicht das System unter definierten Bedingungen innerhalb vorgegebener Kosten- und Zeitgrenzen ein akzeptables Ergebnis?

8. Planung als eigenes Teilproblem

Ein agentisches System muss entscheiden, welche Teilaufgaben in welcher Reihenfolge bearbeitet werden.

Diese Planung umfasst:

Zerlegung eines Ziels in Teilaufgaben,
Bestimmung von Abhängigkeiten,
Auswahl geeigneter Agenten und Tools,
Reihenfolge und Parallelisierung,
Erkennung fehlender Informationen,
Re-Planung nach unerwarteten Ereignissen,
Definition von Abbruch- und Eskalationsbedingungen.

Viele aktuelle Systeme überlassen diese Entscheidungen vollständig einem Sprachmodell. Das kann bei kleinen Aufgaben funktionieren, führt aber bei längeren Abläufen zu schwer kontrollierbaren Plänen.

Eine Alternative besteht in hybriden Planungsarchitekturen:

LLMs erzeugen oder interpretieren Aufgaben,
formale Planer prüfen Abhängigkeiten,
Scheduling-Verfahren verteilen Ressourcen,
regelbasierte Komponenten erzwingen Sicherheitsbedingungen,
ein Laufzeitsystem überwacht die Ausführung.

Methoden können aus unterschiedlichen Disziplinen stammen:

klassische KI-Planung,
Operations Research,
Scheduling,
Constraint Programming,
Markov-Entscheidungsprozesse,
Reinforcement Learning,
Graphenalgorithmen,
Petri-Netze,
ereignisdiskrete Systeme.

Die Stärke hybrider Systeme liegt darin, flexible generative Komponenten mit überprüfbaren Entscheidungsstrukturen zu verbinden.

9. Ressourcenallokation und Scheduling

Agenten konkurrieren um begrenzte Ressourcen:

Modellkapazität,
Tokenbudgets,
Toolzugriffe,
Rechenzeit,
Datenbankabfragen,
menschliche Aufmerksamkeit,
Zeitfenster und Fristen.

Damit entsteht ein Ressourcenallokationsproblem.

Mögliche Entscheidungen sind:

Welcher Agent soll eine Aufgabe bearbeiten?
Sollen mehrere Agenten parallel arbeiten?
Wann lohnt sich eine zusätzliche unabhängige Prüfung?
Welches Modell ist für welchen Teilschritt wirtschaftlich?
Wann wird eine Aufgabe abgebrochen?
Welche Vorgänge erhalten Priorität?
Wie viel Budget darf ein unsicherer Pfad verbrauchen?

Eine Zielfunktion könnte Qualität, Kosten und Zeit gemeinsam berücksichtigen:

J = \alpha\,Q – \beta\,C – \gamma\,T – \delta\,R

mit:

(Q): Ergebnisqualität,
(C): Kosten,
(T): Bearbeitungszeit,
(R): Risiko oder Fehlerschwere,
(\alpha,\beta,\gamma,\delta): anwendungsspezifische Gewichte.

In sicherheitskritischen Anwendungen ist diese einfache gewichtete Form möglicherweise ungeeignet. Dort können harte Nebenbedingungen sinnvoller sein:

P(\text{kritischer Fehler}) \leq \varepsilon

oder:

T \leq T_{\max}, \qquad C \leq C_{\max}

Agentenorchestrierung wird damit zu einem Optimierungsproblem unter Unsicherheit.

10. Orchestrierung als Regelungsproblem

Ein Orchestrator beobachtet den tatsächlichen Systemzustand nur unvollständig. Er sieht Nachrichten, Toolergebnisse, Laufzeiten und möglicherweise Selbstbewertungen der Agenten. Er kennt jedoch nicht zuverlässig die interne Qualität eines Gedankengangs oder die tatsächliche Korrektheit eines Zwischenergebnisses.

Trotzdem muss er Entscheidungen treffen:

welcher Agent als Nächstes aktiv wird,
welche Information weitergegeben wird,
ob ein Ergebnis überprüft werden muss,
ob neu geplant wird,
wann ein Vorgang beendet wird,
wann ein Mensch eingreifen soll.

Damit ähnelt die Orchestrierung einem partiell beobachtbaren Steuerungsproblem.

Der Orchestrator benötigt:

beobachtbare Zustandsgrößen,
Schätzungen nicht direkt beobachtbarer Größen,
Entscheidungsregeln,
Rückmeldungen über Wirkungen früherer Aktionen,
Grenz- und Sicherheitsbedingungen.

Aus regelungstechnischer Sicht sind insbesondere Rückkopplungen relevant. Ein Prüfer-Agent kann Fehler reduzieren, aber auch zusätzliche Schleifen erzeugen. Ein Planer kann Abläufe strukturieren, aber durch häufiges Re-Planning Instabilität verursachen. Eine Kostenbegrenzung kann Endlosschleifen verhindern, aber Aufgaben zu früh abbrechen.

Das Ziel ist daher nicht maximale Autonomie, sondern kontrolliertes Systemverhalten.

11. Simulation vor dem produktiven Einsatz

Viele Architekturentscheidungen werden derzeit direkt im laufenden System getestet. Das ist bei geringen Risiken akzeptabel. Bei hohen Kosten oder kritischen Prozessen ist es problematisch.

Ein simulationsgestützter Entwicklungsansatz trennt drei Ebenen:

1. Strukturmodell

Es beschreibt:

Agentenrollen,
Zuständigkeiten,
Kommunikationswege,
Werkzeuge,
Ressourcen,
Kontroll- und Eskalationsregeln.

2. Verhaltensmodell

Es beschreibt Wahrscheinlichkeiten und Verteilungen:

Bearbeitungszeiten,
Antwortqualität,
Toolausfälle,
Kommunikationsfehler,
Wiederholungsneigung,
Unsicherheit.

3. Szenariomodell

Es erzeugt unterschiedliche Betriebsbedingungen:

hohe Last,
unvollständige Daten,
widersprüchliche Quellen,
Ausfall einzelner Tools,
veränderte Prioritäten,
adversariale Eingaben,
ungewöhnliche Aufgaben,
menschliche Verzögerungen.

Damit lassen sich Architekturen vergleichen, bevor sie vollständig implementiert oder in kritische Prozesse integriert werden.

Simulation ersetzt reale Evaluation nicht. Sie ermöglicht jedoch, den Raum möglicher Systemzustände gezielter zu untersuchen und risikoreiche Varianten früh auszusortieren.

12. Evaluation auf Systemebene

Die Bewertung eines Multi-Agenten-Systems darf nicht auf die Qualität der finalen Antwort reduziert werden.

Ein System kann eine richtige Antwort erzeugen und dennoch ungeeignet sein, weil es:

zu teuer ist,
zu lange benötigt,
nicht reproduzierbar arbeitet,
kritische Zwischenschritte nicht dokumentiert,
unnötig häufig eskaliert,
sensible Informationen falsch verteilt,
nur unter idealisierten Testbedingungen funktioniert.

Relevante Kennzahlen sind daher:

Ergebnisbezogene Kennzahlen

Erfolgswahrscheinlichkeit,
fachliche Korrektheit,
Vollständigkeit,
Konsistenz,
nachgelagerte Fehlerkosten.

Prozessbezogene Kennzahlen

Zeit bis zum Abschluss,
Zahl der Agenteninteraktionen,
Zahl der Toolaufrufe,
Wiederholungs- und Schleifenquote,
Re-Planning-Häufigkeit,
Anteil abgebrochener Vorgänge.

Ressourcenbezogene Kennzahlen

Tokenverbrauch,
Compute-Kosten,
Toolkosten,
menschlicher Kontrollaufwand,
Kosten pro erfolgreichem Vorgang.

Zuverlässigkeitskennzahlen

Robustheit bei Toolausfällen,
Fehlerentdeckungsrate,
Wahrscheinlichkeit kritischer Fehlentscheidungen,
Recovery-Zeit,
Reproduzierbarkeit.

NIST weist bei agentischen Evaluationen darauf hin, dass explizite Budgets und Abbruchbedingungen erforderlich sind, weil Agenten prinzipiell über lange oder sogar unbegrenzte Zeit weiterarbeiten können (NIST AI 800-2: Practices for Automated Benchmark Evaluations).

Evaluation wird damit zu einer Systemidentifikations- und Messaufgabe.

13. Human-in-the-loop als Architekturkomponente

Der Mensch ist in vielen agentischen Systemen kein externer Nutzer, sondern Bestandteil der Kontrollstruktur.

Mögliche Rollen sind:

Freigabe kritischer Aktionen,
Bewertung unsicherer Ergebnisse,
Bereitstellung fehlender Kontextinformationen,
Entscheidung zwischen konkurrierenden Vorschlägen,
Bearbeitung von Ausnahmen,
Rücksetzung oder Beendigung eines Ablaufs.

Human-in-the-loop sollte nicht nur als Sicherheitsreserve betrachtet werden. Menschliche Eingriffe verursachen Kosten, Latenz und organisatorische Abhängigkeiten. Sie müssen deshalb geplant und gemessen werden.

Relevante Fragen sind:

Welche Unsicherheit löst eine Eskalation aus?
Welche Informationen benötigt der Mensch für eine schnelle Entscheidung?
Wie wird verhindert, dass zu viele Fälle eskalieren?
Wie werden Entscheidungen dokumentiert und zurückgespielt?
Wann ist vollständige Automatisierung tatsächlich sinnvoll?

Ein gutes System optimiert nicht die Zahl autonomer Schritte, sondern die Verteilung von Entscheidungen zwischen Mensch und Maschine.

14. Ein systematischer Entwicklungsprozess

Ein belastbarer Entwicklungsprozess für Multi-Agenten-Systeme kann in mehreren Schritten erfolgen.

Schritt 1: Aufgaben- und Prozessanalyse

Was ist das eigentliche Systemziel?
Welche Teilaufgaben existieren?
Welche Abhängigkeiten und Rückkopplungen bestehen?
Welche Risiken sind relevant?
Welche Entscheidungen müssen überprüfbar sein?

Schritt 2: Zustands- und Informationsmodell

Welche Zustände müssen gespeichert werden?
Welche Informationen besitzt welcher Agent?
Welche Daten sind global, lokal oder vertraulich?
Welche Ereignisse verändern den Systemzustand?

Schritt 3: Architekturentwurf

Einzelagent oder Multi-Agenten-System?
zentral, hierarchisch oder dezentral?
synchrone oder asynchrone Kommunikation?
feste oder dynamische Rollen?
welche Tools und Modelle?

Schritt 4: Metriken und Nebenbedingungen

Welche Qualität ist erforderlich?
Welche Kosten- und Zeitgrenzen gelten?
Welche Fehler sind tolerierbar?
Welche Vorgänge benötigen menschliche Freigabe?

Schritt 5: Simulationsmodell

Welche Verhaltensunsicherheiten werden abgebildet?
Welche Last- und Fehlerszenarien müssen untersucht werden?
Welche Architekturvarianten werden verglichen?

Schritt 6: Prototyping und instrumentierte Tests

vollständige Protokollierung,
reproduzierbare Testfälle,
kontrollierte Variation von Modellen und Prompts,
Messung von Kosten und Laufzeiten,
Analyse von Fehlerketten.

Schritt 7: Laufzeitüberwachung

Zustands- und Trace-Monitoring,
Anomalieerkennung,
Budgetkontrolle,
automatische Prüfagenten,
Eskalationsregeln,
regelmäßige Re-Evaluation.

Dieser Prozess behandelt Multi-Agenten-KI nicht als einmalige Implementierung, sondern als iterativ zu identifizierendes und zu steuerndes System.

15. Der RCS-Ansatz

Renner Complex Systems betrachtet agentische KI-Systeme als komplexe dynamische Systeme.

Der Schwerpunkt liegt nicht allein auf der Implementierung einzelner Agenten. Entscheidend ist die Frage, wie Rollen, Informationen, Werkzeuge, Ressourcen und Kontrollmechanismen zu einem belastbaren Gesamtsystem verbunden werden.

Ein systematischer RCS-Ansatz umfasst:

System- und Prozessanalyse

Strukturierung des Anwendungsfalls,
Identifikation von Akteuren, Zuständen und Entscheidungen,
Analyse von Abhängigkeiten und Rückkopplungen,
Bestimmung kritischer Systemgrenzen.

Formale Modellierung

Zustands- und Übergangsmodelle,
Kommunikationsgraphen,
Ressourcen- und Kapazitätsmodelle,
Definition von Zielgrößen und Nebenbedingungen.

Simulation

ereignisdiskrete Multi-Agenten-Simulation,
Monte-Carlo-Analyse,
Last- und Fehlerszenarien,
Vergleich alternativer Architekturen.

Planung und Orchestrierung

Aufgabenzerlegung,
Scheduling und Ressourcenallokation,
Auswahl zentraler, hierarchischer oder dezentraler Steuerungsmechanismen,
Human-in-the-loop- und Eskalationskonzepte.

Evaluation und Reliability Engineering

Definition systemischer Metriken,
Failure-Mode-Analyse,
Robustheits- und Sensitivitätstests,
Kosten-, Latenz- und Qualitätsmodellierung,
Monitoring- und Kontrollkonzepte.

Prototyping und Roadmap

Aufbau instrumentierter Demonstratoren,
Vergleich technischer Frameworks,
Übergang vom Prototyp zum produktionsfähigen System,
Priorisierung weiterer Entwicklungsstufen.

Der Ansatz verbindet Methoden aus:

Complex Systems,
Multi-Agenten-Simulation,
Operations Research,
Statistik,
stochastischer Modellierung,
Regelungs- und Entscheidungstheorie,
Data Science und Machine Learning.

Das Ziel ist nicht, Agentensysteme unnötig zu formalisieren. Es geht darum, Architektur, Risiken und Leistungsgrenzen sichtbar zu machen, bevor Komplexität und Betriebskosten unkontrolliert wachsen.

16. Wo dieser Ansatz besonders relevant wird

Eine systemtechnische Perspektive ist besonders wertvoll, wenn Agentensysteme:

viele Schritte autonom bearbeiten,
mehrere spezialisierte Agenten koordinieren,
teure oder knappe Ressourcen nutzen,
in technische oder operative Prozesse eingreifen,
unter Zeitdruck arbeiten,
unvollständige Informationen verarbeiten,
sicherheits- oder geschäftskritische Entscheidungen vorbereiten,
nachvollziehbar und auditierbar sein müssen.

Mögliche Anwendungsfelder sind:

wissenschaftliche Recherche und Hypothesengenerierung,
technische Diagnose und Wartungsplanung,
Energie- und Infrastrukturmanagement,
Produktions- und Logistikplanung,
Softwareentwicklung,
komplexe Analyse- und Berichtsprozesse,
Risiko- und Compliance-Prüfung,
Entscheidungsunterstützung in Organisationen.

Je höher Kosten, Laufzeit und Kritikalität eines Prozesses sind, desto weniger genügt ein rein experimentelles Agentendesign.

17. Vom Demonstrator zum belastbaren Agentensystem

Die gegenwärtige Agentenentwicklung befindet sich in einer Übergangsphase.

Frameworks vereinfachen Tool-Nutzung, Übergaben, Speicher und Orchestrierung. OpenAI, Anthropic und andere Anbieter veröffentlichen inzwischen eigene Architekturmuster und Laufzeitinfrastrukturen. Gleichzeitig zeigen aktuelle Arbeiten von NIST, dass Evaluation, Abbruchbedingungen, Traceability und Schutz gegen manipulierte Eingaben noch eigenständige offene Engineeringaufgaben darstellen.

Die zentrale Herausforderung verschiebt sich daher.

Am Anfang stand die Frage:

Kann ein Sprachmodell ein Werkzeug benutzen?

Danach folgte:

Können mehrere Agenten eine komplexe Aufgabe gemeinsam lösen?

Die nächste Frage lautet:

Wie entwerfen und betreiben wir agentische Systeme so, dass ihr Verhalten unter realen Bedingungen planbar, messbar, wirtschaftlich und kontrollierbar bleibt?

Diese Frage lässt sich nicht allein durch bessere Prompts beantworten.

Sie verlangt Systemanalyse, Modellierung, Simulation, Planung, Optimierung und kontinuierliche Evaluation.

Agentische KI braucht Systemtechnik.

Kernaussagen

Multi-Agenten-Systeme sind verteilte, zustandsbehaftete und stochastische dynamische Systeme.
Mehr Agenten erhöhen nicht automatisch die Leistung; sie erzeugen zusätzliche Kosten und Fehlermodi.
Architektur, Kommunikationsstruktur und Zustandsführung bestimmen die Qualität des Gesamtsystems.
Planung und Orchestrierung sind Optimierungs- und Steuerungsprobleme unter partieller Beobachtbarkeit.
Ereignisdiskrete und stochastische Simulation ermöglichen Architekturvergleiche vor dem produktiven Einsatz.
Evaluation muss Ergebnisqualität, Prozess, Ressourcenverbrauch und Zuverlässigkeit gemeinsam erfassen.
Human-in-the-loop ist eine planbare Systemkomponente und keine bloße Notlösung.
Der Übergang vom Demonstrator zum produktiven Agentensystem erfordert einen systematischen Engineeringprozess.
RCS kann diese Entwicklung mit Methoden aus komplexen Systemen, Simulation, Operations Research und Data Science unterstützen.