Die fehlende Ebene in der agentenbasierten KI

Die meisten gängigen Agentensysteme behandeln Kontext primär als Gesprächsverlauf, abgerufene Dokumente oder Vektorähnlichkeitsergebnisse. Dieser Ansatz funktioniert für Konversationsaufgaben recht gut, operative Systeme erfordern jedoch ein grundlegend anderes Kontextmanagement.

In realen Umgebungen hängen Entscheidungen nicht nur von den gewonnenen Informationen ab, sondern auch von:

• Entitätsbeziehungen,
• Organisationsstruktur
• zeitliche Ereignisse,
• Eigentumsketten, 
• frühere Entscheidungen
• aktive Beschränkungen,
• und sich ständig weiterentwickelnden Betriebszustand [1]. 

Ein Kunde ist mehr als nur ein Dokument. Ein Unternehmen ist mehr als nur ein Textfragment. Ein regulatorisches Ereignis ist mehr als nur ein weiteres Suchergebnis. Operative Systeme benötigen ein sich kontinuierlich weiterentwickelndes Zustandsmodell. Hier wird die Unterscheidung zwischen Speicher und operativem Kontext entscheidend.

Der Speicher speichert Informationen. Der operative Kontext erhält den Systemzustand aufrecht.

In der Praxis bedeutet dies, dass das System Strukturen wie Entitäten, Beziehungen, zeitliche Ereignisketten, Richtlinienbindungen und den Ausführungsverlauf kontinuierlich pflegen und aktualisieren muss. Dies ist einer der Gründe, warum graphenbasierte Ansätze in Agentensystemen zunehmend an Bedeutung gewinnen.

Ein Graph ist nicht nur für den Datenabruf nützlich. Er bietet eine Laufzeitdarstellung des Betriebszustands. Anstatt Kontext als isolierte Textfragmente zu behandeln, kann das System über verbundene Entitäten, sich entwickelnde Beziehungen, zeitliche Abhängigkeiten und kontextuelle Ausbreitungspfade argumentieren. Dies verändert die Rolle des Graphen grundlegend. Der Graph hört auf, eine Speicherschicht zu sein, und wird stattdessen zu:

• Kontextgedächtnis,
• operative staatliche Vertretung,

• und Ausführungskontext für Entscheidungssysteme.

  

  Mit der zunehmenden Entwicklung von Agentensystemen hin zu autonomen Operationen gewinnt diese Unterscheidung immer mehr an Bedeutung. Denn die autonome Ausführung erfordert nicht nur den Abruf von Informationen, sondern auch die kontinuierliche Verwaltung des Kontextzustands[4].

Stellen Sie sich einen Sachbearbeiter für Streitfälle vor, der eine Rückbuchungsanfrage bearbeitet. Der Kunde behauptet, eine Transaktion sei betrügerisch gewesen. Die Transaktion wurde von einem vertrauenswürdigen Gerät aus durchgeführt. Der Händler hat ein niedriges Risikoprofil. Auf den ersten Blick erscheint der Fall einfach. Doch die Transaktion erfolgte kurz nach einer ungewöhnlichen Passwortzurücksetzung, der Kunde hat kürzlich sein Gerät gewechselt, und die Betrugsrichtlinie der Bank sieht eine Eskalation vor, wenn mehrere verdächtige Signale innerhalb kurzer Zeit auftreten.

An diesem Punkt kann die Richtlinie nicht länger nur ein PDF bleiben. Sie muss Teil der Argumentationsgrundlage werden.

In einem operativen Agentensystem sollten Richtlinien nicht erst dann als Text abgerufen werden, wenn das LLM bereits eine Antwort formuliert hat. Sie müssen die Ausführung aktiv einschränken: bestimmte Aktionen blockieren, Eskalationen auslösen, Genehmigungswege ändern, zusätzliche Nachweise anfordern oder eine automatisierte Lösung verhindern. Dieser Ansatz ist eng verwandt mit früheren richtlinienbasierten Planungsansätzen, bei denen die Ausführung kontinuierlich durch Einschränkungen, Ziele und Umgebungsbedingungen und nicht durch isolierte Aufgabenabschlusslogik geprägt wird [6].

Hier wird der graphenbasierte operative Kontext entscheidend.

Der Graph stellt den Konfliktstatus dar: Kunde, Konto, Transaktion, Händler, Gerät, Passwortzurücksetzungsereignis, Betrugsindikatoren, vorherige Entscheidungen, Richtlinienregeln und Ausführungshistorie. Richtlinien werden dann als ausführbare Einschränkungen und nicht als isolierte Dokumente mit diesem Graphen verknüpft. Dies ähnelt in vielerlei Hinsicht der Entwicklung von Multiagenten-Ausführungsumgebungen, in denen intelligente Entitäten über einen kontinuierlich geteilten Betriebszustand anstatt über isolierte Nachrichtenaustausche koordinieren [4].

Eine Argumentationsschicht kann diesen Graphen mithilfe regel- oder logikbasierter Mechanismen verarbeiten, die von früheren logischen Programmier- und deduktiven Datenbanksystemen abgeleitet wurden [8]. Beispielsweise kann eine Datalog-ähnliche Regel ausdrücken, dass ein Konflikt eskaliert werden muss, wenn eine strittige Transaktion auf eine Passwortzurücksetzung folgt, ein neues Gerät betrifft und einen Risikoschwellenwert überschreitet – ein Ansatz, der konzeptionell mit klassischen deduktiven Argumentationssystemen und Datenbanklogik-Engines übereinstimmt [9].

Das LLM kann den Fall interpretieren, die Entscheidung erläutern und mit Benutzern interagieren, aber die politische Bedingung selbst wird deterministisch über den Graphen ausgewertet.

In dieser Architektur bildet die Graph-Engine die operative Grundlage, während die Reasoning-Schicht Einschränkungen, Verpflichtungen, Berechtigungen und Abhängigkeiten des aktuellen Zustands auswertet. Diese Trennung zwischen probabilistischem Schließen und eingeschränkter Ausführung erinnert an frühere BDI-basierte Agentenmodelle, in denen intelligentes Verhalten nicht nur aus Zielen, sondern auch aus kontinuierlich gepflegten Überzeugungen, Absichten, Verpflichtungen und Ausführungseinschränkungen entsteht (Rao & Georgeff, 1995).

Der entscheidende Wandel 

Dies ermöglicht es einem autonomen Streitbeilegungsbeauftragten, nicht nur über das Geschehene zu argumentieren, sondern auch darüber, was bei jedem Ausführungsschritt erlaubt, erforderlich, blockiert oder eskaliert wird.

Sobald der Kontext zu einem sich ständig weiterentwickelnden operativen Zustand wird und Richtlinien zu ausführbaren Einschränkungen werden, besteht die nächste Herausforderung in der Umsetzung der Entscheidung selbst.

In dieser Phase geht es nicht mehr um den Abruf von Informationen, sondern um die Entscheidungssteuerung zur Laufzeit. Die meisten aktuellen Agentensysteme arbeiten noch immer als Aktionsgenerierungssysteme: Kontext abrufen, darüber nachdenken, eine Aktion generieren und das Ergebnis ausführen. Operative Systeme benötigen jedoch eine zusätzliche Schicht zwischen Denken und Ausführen: eine eingeschränkte Entscheidungspipeline.

Diese Unterscheidung ist entscheidend, da operative Umgebungen selten nur eine einzige gültige Aktion enthalten. Stattdessen enthalten sie:

• durchführbare Maßnahmen
• verbotene Handlungen
• eskalierte Maßnahmen
• verzögerte Handlungen
• und bedingt zulässige Aktionen.

Die Rolle des Systems besteht daher nicht nur darin, Aktionen zu generieren, sondern diese unter Berücksichtigung von Laufzeitbeschränkungen kontinuierlich zu filtern und zu validieren. Eine vereinfachte Pipeline sieht zunehmend wie folgt aus: 

Dies verändert die Rolle mehrerer Komponenten im Stack. Der Graph dient nicht mehr nur dem Abruf von Daten, sondern repräsentiert den Betriebszustand des Systems zur Laufzeit. 

Richtlinien sind keine statische Dokumentation mehr. Sie werden zu ausführbaren Laufzeitbeschränkungen, die bei der Entscheidungsfindung ausgewertet werden. Der Planer ordnet nicht länger nur Aufgaben an, sondern ist nun dafür verantwortlich, unter Berücksichtigung der aktiven Beschränkungen operativ realisierbare Aktionen zu generieren.

Diese Unterscheidung ist wichtig, da viele operative Fehler nicht auf fehlende Informationen zurückzuführen sind. Sie entstehen vielmehr durch die Auswahl ungeeigneter Maßnahmen unter sich ändernden Bedingungen.

Beispielsweise:

• Eine Handlung kann eine Befugnisgrenze verletzen.
• Konflikt mit einer aktiven Compliance-Regel,
• eine ungültige Prozesssequenz auslösen,
• oder die Entstehung nachgelagerter operationeller Risiken.

In diesen Fällen liegt das Problem nicht in einem Intelligenzversagen, sondern in einem Versagen der Systembeschränkungen. Deshalb gewinnt die Planung unter Berücksichtigung von Beschränkungen in autonomen Systemen zunehmend an Bedeutung.

Anstatt generierte Aktionen direkt auszuführen, muss das System Folgendes tun:

• Machbarkeit prüfen,
• Ungültige Pfade entfernen,
• Laufzeitbeschränkungen anwenden,
• Konflikte erkennen,
• und gegebenenfalls alternative Ausführungspfade generieren.

Konzeptionell gesehen rückt dies moderne Agentensysteme näher an klassische Planungssysteme heran als an traditionelle dialogbasierte KI-Architekturen.

Ansätze wie:

• GraphPlan,
• Constraint-Satisfaction-Systeme,
• heuristische Suche,
• A*-Varianten,
• und dynamische Umplanungsalgorithmen

werden wieder relevant, sobald Systeme unter sich ständig ändernden Laufzeitbedingungen arbeiten.

Im Gegensatz zu klassischen Planern beinhalten moderne operative Systeme jedoch auch eine probabilistische semantische Interpretation, unstrukturierte Eingaben, einen sich entwickelnden Graphkontext und dynamisch veränderliche Richtlinien.

Folglich ist die entstehende Architektur weder rein symbolisch noch rein probabilistisch. Sie entwickelt sich zu einem hybriden Ausführungsmodell, in dem LLMs interpretieren, Graphen den Betriebszustand verwalten, Einschränkungen die Ausführungsgrenzen definieren und Planer innerhalb dieser Grenzen realisierbare Aktionen generieren.

Diese Trennung ist wichtig, da sie es autonomen Systemen ermöglicht, flexibel zu bleiben, ohne die operative Kontrolle zu verlieren. Ziel ist es nicht, probabilistische Intelligenz zu eliminieren.

Ziel ist es, zu verhindern, dass probabilistisches Denken die operative Ausführung direkt steuert, ohne dass deterministische Validierungsschichten dazwischen liegen.

Sobald der operative Kontext, die Ausführungsbeschränkungen und die eingeschränkte Planung Teil der Laufzeitumgebung selbst werden, ist die autonome Ausführung kein einfaches Orchestrierungsproblem mehr. Das System operiert kontinuierlich in einem sich verändernden Betriebszustand: Entitäten entwickeln sich weiter, Beziehungen ändern sich, Beschränkungen werden aktiviert oder laufen ab, und die Ausführungsmöglichkeit verschiebt sich im Laufe der Zeit.

Unter diesen Bedingungen kann die Ausführung nicht mehr allein von den generierten Ergebnissen abhängen. Das System muss den Kontext kontinuierlich neu bewerten, Einschränkungen validieren, Pläne anpassen und die operative Konsistenz unter sich ändernden Bedingungen aufrechterhalten.

Dies gewinnt zunehmend an Bedeutung, wenn Agentensysteme von kurzlebigen Arbeitsabläufen hin zu langfristigen, zielorientierten Operationen übergehen. In diesen Umgebungen bleiben Ziele bestehen, mehrere Agenten interagieren, Organisationsgrenzen spielen eine Rolle und Ausführungspfade entwickeln sich dynamisch zur Laufzeit.

Folglich wird die Planung nicht länger eine einmalige Aufgabe, sondern ein kontinuierlicher operativer Prozess. Hier beginnen graphenbasierte Betriebszustände, ausführbare Richtlinien und bedingungsbewusste Planung in einer neuen Laufzeitarchitektur für autonome Systeme zusammenzufließen.

Und im Laufe der Zeit wird diese Architektur wahrscheinlich eine neue Generation von Betriebsartefakten hervorbringen:

• persistente Ziele, die von zielorientierten Ansätzen des Anforderungsmanagements wie KAOS [10] inspiriert sind,
• ausführbare organisatorische Rollen und Verantwortlichkeiten, ähnlich dem rollenorientierten Organisationsmodell von Gaia für Multiagentensysteme [11],
• adaptive Koordinationsstrukturen, die organisatorischen MAS-Ansätzen wie MOISE+ [12] ähneln,
•  und Laufzeit-Organisationsmuster für Multiagentensysteme mit langem Zeithorizont, die in der Forschung zu Organisationslogik und adaptiven multiorganisatorischen Systemen untersucht wurden [13][14].

Die nächste Generation von KI-Systemen für Unternehmen wird sich daher möglicherweise nicht dadurch definieren, wie viele Aktionen sie generieren können, sondern dadurch, wie zuverlässig sie ein koordiniertes, zielorientiertes Verhalten unter sich ständig ändernden Rahmenbedingungen aufrechterhalten können.

1. Hogan, A., Blomqvist, E., Cochez, M., et al. Wissensgraphen. ACM Computing Surveys, 2021.

2. Edge, D., et al. Vom Lokalen zum Globalen: Ein GraphRAG-Ansatz zur abfrageorientierten Zusammenfassung. arXiv, 2024.

3. Nii, HP: Das Blackboard-Modell der Problemlösung und die Entwicklung von Blackboard-Architekturen. AI Magazine, 1986.

4. Wooldridge, M. Einführung in Multiagentensysteme. Wiley, 2009.

5. Ferber, J. Multiagentensysteme: Eine Einführung in die verteilte künstliche Intelligenz. Addison-Wesley, 1999.

6. Myers, KL. Auf dem Weg zu einem Rahmenwerk für kontinuierliche Planung und Ausführung. AAAI, 1999.

7. Rao, AS, Georgeff, MP BDI Agents: From Theory to Practice. ICMAS, 1995.

8. Ceri, S., Gottlob, G., Tanca, L. Logikprogrammierung und Datenbanken. Springer, 1990.

9. Abiteboul, S., Hull, R., Vianu, V. Grundlagen der Datenbanken. Addison-Wesley, 1995.

[10]. van Lamsweerde, A. (2001). Zielorientiertes Requirements Engineering: Ein geführter Überblick.

[11] Wooldridge, M., Jennings, NR, & Kinny, D. (2000). Die Gaia-Methodik für agentenorientierte Analyse und Gestaltung.

[12] Hannoun, M., Sichman, JS, Boissier, O. & Sayettat, C. (2000). MOISE: Ein Organisationsmodell für Multi-Agent-Systeme.

[14] Dignum, V., & Dignum, F. (2018). Die Rolle von Organisationsmodellen in Agentensystemen.

[15] Tamersoy, M., Ekinci, EE, Erdur, RC, & Dikenelli, O. (2017). Ein Anforderungsmodell für adaptive multiorganisationale Systeme. SASO 2017.