Softwarearchitektur & Agentenbasierte KI – Asynchronität ist der Schlüssel! 

Wenn Menschen über agentenbasierte KI nachdenken, beschäftigen sie sich vor allem mit der Frage der Automatisierung von Aufgaben, die eigenständige Entscheidungen erfordern. Sie erarbeiten weitläufige Lösungsideen für verschiedenste Herausforderungen und überlegen, wie ein System aus KI-Agenten die Arbeit effizienter gestalten, menschliche Arbeitskräfte entlasten und die Produktivität steigern könnte. Auf dieser Grundlage beginnen sie anschließend Prototypen zu entwickeln, um ihre Ideen praktisch umzusetzen und verschiedene Modelle zu testen und zu bewerten, so dass letztlich ein Proof of Concept (PoC) erreicht wird.

Die agentenbasierte KI steckt jedoch noch in den Kinderschuhen, und es gibt viele grundlegende Probleme zu lösen – beispielsweise die Tatsache, dass die meisten KI-Projekte kurzfristig scheitern aufgrund unklarer Zielsetzung, überzogener Erwartungen, unzureichender Datenmengen oder unzureichender Datenaufbereitung. Eines der grundlegendsten Probleme ist jedoch, dass die Fehlbarkeit und das nicht deterministische Verhalten von LLMs ignoriert werden. Eine MIT-Studie zeigt, dass es nur 5 % der KI-Systeme für Unternehmen bis zur Produktion schaffen. Als Hauptgründe für das Scheitern werden in dieser Studie fragile Arbeitsabläufe, mangelndes kontextuelles Lernen und eine mangelnde Abstimmung mit dem Tagesgeschäft genannt – was bedeutet, dass nicht genügend Zeit für die ordnungsgemäße Integration der KI in die Betriebsprozesse aufgewendet wird. Sie können solche grundlegenden Probleme durch ein angemessenes Design und die sinnvolle Einbettung Ihrer agentenbasierten KI-Lösung in Ihre Prozesse mindern. Übrigens können wir von der CID Sie in jeder Phase Ihres agentenbasierten KI-Projekts unterstützen.

Stellen wir uns jedoch vor, dass die agentenbasierte KI ausgereift ist und einen soliden, gut funktionierenden und verständlichen Zustand erreicht hat – und Ihr Proof of Concept einwandfrei funktioniert. Der Übergang vom PoC zu einer produktionsreifen Implementierung erfordert nicht nur ein Verständnis der intrinsischen Eigenschaften der KI, sondern auch der Grundlagen der Softwareentwicklung. Andernfalls wird Ihr KI-Projekt langfristig scheitern. Denn Sie werden unweigerlich mit derselben Situation konfrontiert sein wie bei Nicht-KI-Software: Sie müssen sich für die richtige Softwarearchitektur entscheiden.

Ein typischer Ansatz für die Erstellung eines agentenbasierten KI-Prototypen ist es, eine monolithische Architektur zu wählen. Monolithen sind weniger komplex und ermöglichen daher einen schnelleren Fortschritt für die Projektumsetzung. Aktuelle agentenbasierte KI-Frameworks erhöhen zudem die Attraktivität einer monolithischen Implementierung, so dass es verlockend sein kann, sich auch bei der produktiven Umsetzung für einen Monolithen zu entscheiden (– Beispiele für KI-Frameworks folgen später in diesem Artikel). Je nach den Anforderungen an das KI-Projekt kann dies eine sinnvolle Entscheidung sein oder auch eben nicht. Die Wahl der richtigen Softwarearchitektur ist jedoch für eine produktive Version absolut unerlässlich. Wie im oben referenzierten Artikel ausführlich erläutert, können falsche Designentscheidungen zwar zu einem schnellen Erfolg bei PoCs führen, aber oft auch zu nicht wartbaren, kostenineffizienten und funktionsunfähigen Systemen in der Produktion. Dieses Risiko unterstreicht die Bedeutung des Shift-Left-Designs, d. h. der frühzeitigen Berücksichtigung von Skalierbarkeit, Beobachtbarkeit und Modularität in der Entwicklung, anstatt diese später nachzurüsten, wenn die Lösung technischer Probleme unerschwinglich teuer wird.

In diesem Artikel diskutiere ich die wichtigsten Punkte, die bei der Implementierung einer agentenbasierten KI-Software in einer groß angelegten Produktionsumgebung mit vielen Benutzern zu berücksichtigen sind.

Anforderungsanalyse

Wie bei allen Softwarearchitekturen besteht der erste, wichtigste und fortwährend durchzuführende Schritt darin, die Anforderungen für ein Softwareprojekt zu definieren, zu dokumentieren und zu pflegen. Die funktionalen Anforderungen, die festlegen, was Ihre Software leisten soll, werden in der Regel während der Prototypentwicklung ausführlich ausgearbeitet und entsprechend für eine erste Produktionsversion spezifiziert. Die nicht-funktionalen Anforderungen, die die Qualitäts- und Leistungsaspekte definieren, sind jedoch bei der Entwicklung produktionsreifer Software von größerer und entscheidender Bedeutung. Eine agentenbasierte KI-Software unterscheidet sich in dieser Hinsicht nicht.

Bei der Entwicklung agentenbasierter KI-Systeme besteht ein grundlegendes gemeinsames Merkmal darin, dass mehrere spezialisierte und autonom arbeitende Agenten an der Erfüllung einer größeren Aufgabe beteiligt sind. Dabei trägt jeder Agent eine genau definierte, in der Regel kleine und domänenspezifische Teilaufgabe bei. Wäre dies kein gemeinsames Merkmal, gäbe es überhaupt keinen Grund, ein System mit mehreren Agenten zu entwerfen – tatsächlich kann dies ohnehin die beste Lösung sein: Verwenden Sie KI-Agenten nur, wenn es sinnvoll ist und Ihnen Vorteile bringt!

KI-Anwendungsfälle

Ein typisches Beispiel in Tutorials für agentenbasierte KI-Systeme ist eine Schreibpipeline mit spezialisierten KI-Agenten. Ein zugehöriger Arbeitsablauf könnte folgende Agenten umfassen:

• Ein Web-Recherche-Agent zum Sammeln relevanter Informationen.
• Einen Agenten für Textzusammenfassungen oder Inhaltsangaben, der die wichtigsten Kernaussagen herausarbeitet.
• Einen Agenten, der Vorschläge zur Verbesserung von Klarheit, Tonfall oder Struktur erstellt.
• Einen Agenten, der Texte mit Schlagworten und anderen Metadaten annotiert und somit Inhalte kategorisiert.
• Einen Klassifizierungsagenten, der Texte nach Thema oder Absicht organisiert.
• Einen Sentiment-Analyse-Agenten, der die emotionale Haltung oder Meinung in einem Text erkennt und bewertet.
• Einen Verifizierungs-, Governance- oder Compliance-Agenten zur Sicherstellung von:
  • Relevanz und Originalität des Artikels.
  • Funktionalität eingebetteter Links.
  • Vollständigkeit erforderlicher Elemente (z. B. Kopf- und Fußzeilen, Zitate).

Dieser modulare Ansatz ermöglicht es jedem Agenten, sich auf eine bestimmte Aufgabe zu konzentrieren, wodurch die Effizienz und die Qualität der Ergebnisse verbessert werden.

Ein weiteres Beispiel aus der Praxis ist die agentenbasierte Vermögensverwaltung. Anhand von Echtzeit-Ereignissen aus dem Lebensumfeld der Kunden – beispielsweise eine bevorstehende Hochzeit – können zeitnahe, personalisierte Finanzberatungen durchgeführt werden. Sollte ein potenzieller Kunde eine Änderung seiner Lebensumstände mitteilen (z. B. „Ich heirate nächstes Wochenende!“), wandelt ein KI-System diese Rohdaten in konkrete Handlungsempfehlungen für Berater um und ermöglicht so eine automatisierte Recherche, ohne dass dabei die menschliche Einflussnahme verloren geht.

In diesem Zusammenhang können dedizierte Agenten verschiedene Aufgaben vollständig autonom übernehmen:

• Agenten zur Datenerfassung
  • Kundenprofile werden aus CRM-Datensätzen, behördlichen Unterlagen und Beraternotizen zusammengestellt.
  • Öffentliche Signale, wie Ankündigungen in sozialen Medien oder Erwähnungen in den Nachrichten, werden auf relevante Aktualisierungen überwacht.
• Agenten zum Aufbau einer Wissensinfrastruktur
  • Ein strukturierter Wissensgraph verbindet unterschiedliche Datenpunkte, um ein einheitliches Bild des potenziellen Kunden zu erstellen.
• Agenten für die Ereignisverarbeitungspipeline
  • Zur Erkennung von Ereignissen zu benannten Entitäten werden öffentliche Daten gescannt und die relevantesten Kandidaten von einem LLM herausgefiltert.
  • Das LLM identifiziert Ereignisse mit hoher Priorität, die die Aufmerksamkeit eines Beraters erfordern.
  • Das KI-System generiert auf der Grundlage der erkannten Ereignisse maßgeschneiderte Handlungsempfehlungen.

Während die Agenten die Analyse automatisieren, bleibt der endgültige Berater ein Mensch, der für nuancierte, vertrauensvolle Kundeninteraktionen sorgt.

Agentische Vergleichbarkeit

Wenn man ein solches System aus individuell arbeitenden Softwarekomponenten betrachtet, von denen jede Komponente einen bestimmten Teil zum Gesamtbild beiträgt, drängt sich der Gedanke auf, dass ein agentenbasiertes KI-System einem Microservice-System sehr ähnlich ist.

Und wenn man dieser Überlegung folgt, gelten viele der gleichen nicht-funktionalen Anforderungen auch für ein agentenbasiertes KI-System – Skalierbarkeit, Zuverlässigkeit, Verfügbarkeit, Wartbarkeit, Kosteneffizienz usw. – sowie bestimmte Leistungsaspekte. Zum Beispiel wollen Sie je nach Anwendungsfall sicherstellen, dass das System eine bestimmte Last bewältigen und einen bestimmten Durchsatz ermöglichen kann. Und wie werden solche nicht-funktionalen Anforderungen an ein Microservice-System erreicht? Genau – durch die Entkopplung seiner Dienste.

Entkoppeln Sie Ihre Agenten!

Agenten zu entkoppeln bedeutet, sie so unabhängig wie möglich voneinander arbeiten zu lassen. Dies erreicht man, indem man ihre Kohäsion maximiert, d. h. jeder Agent erfüllt einen klaren, einzigen Zweck und enthält nur die Logik und Daten, die zur Erfüllung dieses Zwecks erforderlich sind.

Es entstehen derzeit zahlreiche allgemeine und spezialisierte Agenten-Frameworks, z. B. SmolAgents, LangChain, HayStack, SemanticKernel, Agent Framework und viele andere. Sie eignen sich hervorragend für eine schnelle Prototypen-Erstellung, das Ausprobieren von Ideen und PoCs. Allerdings sind sie noch nicht für alle Arten von Produktionsszenarien geeignet. Das liegt nicht nur daran, dass viele von den angebotenen, aber notwendigen Funktionen die Produktionsreife noch nicht erreicht haben. Sondern es liegt auch daran, dass den Frameworks eine synchrone, direkte, prozessinterne oder auf HTTP basierende Kommunikation zwischen den Agenten zugrunde liegt. Das trifft insbesondere in Bezug auf die Agentenorchestrierung und das Design von KI-Workflows zu.

Selbst wenn man das Model Context Protocol (MCP) und Googles Agent-to-Agent Protocol (A2A) berücksichtigt, erfolgt die Kommunikation über HTTP (unter Verwendung von JSON-RPC, gRPC, SSE), wodurch aktiv auf spezifische Agentenantworten für eine gegebene Anfrage gewartet wird. Selbst wenn eine übergeordnete Agentenregistrierung genutzt wird, um geeignete Agenten und deren Kommunikationsschnittstellen zu finden, bleibt der eigentliche Kommunikationsmechanismus in bestehenden Frameworks in der Regel derselbe: Es wird eine direkte Kontaktadresse des Agenten benötigt. Und das bedeutet, dass sich die Agenten gegenseitig kennen müssen.

Es besteht insofern aufgrund ihrer Kommunikationsweise immer eine gewisse Kopplung zwischen den Agenten. Am Beispiel des modernen Microservice-Designs haben wir gelernt, dass durch eine enge Kopplung zentrale, nicht-funktionale Anforderungen beeinträchtigt werden. Zu den wichtigsten Herausforderungen gehören:

• Skalierbarkeit: Dienste lassen sich schwieriger unabhängig voneinander hoch- oder herunterskalieren, da gegenseitige Abhängigkeiten eine sorgfältige und koordinierte Abstimmung erfordern.
• Zuverlässigkeit: Fehlerbehandlungs- und Wiederholungsmechanismen werden komplexer, wodurch das Risiko von kaskadierenden Ausfällen steigt.
• Wartbarkeit: Schnelle Fehlerbehebungen oder die Bereitstellung neuer Dienste werden durch Abhängigkeiten behindert, weil koordinierte Aktualisierungen erforderlich sind.
• Durchsatz: Das Blockieren von Aufrufen und das Warten darauf, dass nachgelagerte Dienste Anfragen annehmen, führt zu Latenzzeiten und verringert die Gesamteffizienz des Systems.

Je enger die Kopplung, desto komplexer und schlimmer ist die Situation. In den Anfängen der Microservices ähnelten die Designs eher einem (schlechten) monolithischen Design, nur mit zusätzlicher Kommunikation zwischen den Diensten. Für einen solchen Designfehler wurde sogar ein Begriff geprägt: monolithischer Microservice.

Bei der Entwicklung eines agentenbasierten KI-Systems sollten wir diese Fehler der Vergangenheit vermeiden und KI-Agenten aus eben diesen Gründen entkoppeln!

Manche mögen argumentieren, dass agentenbasierte Anwendungsfälle und Workflows von Natur aus sequenziell und (stark?) gekoppelt sind, d. h. absichtlich so konzipiert wurden. Beispielsweise können Agenten oft wie ein Stern angeordnet sein, mit einem Orchestrator in der Mitte, der den nächsten zu kontaktierenden Agenten auswählt (obwohl es keine Einschränkungen hinsichtlich irgendeiner Gestaltung sequenzieller Pfade gibt). Ein solches Design ist im Übrigen auch für Microservice-Systeme möglich (z. B. Service A muss Daten von Service B anfordern, bevor er mit C kommunizieren kann). Das ist jedoch nur die Sicht aus der Geschäftslogik. Denn dieses Argument vernachlässigt, dass ein solcher Anwendungsfall oder Workflow potenziell von vielen Benutzern verwendet wird (– ist dies nicht so, fehlt Ihrem Geschäftsmodell die Grundlage). Daher gelten viele der nicht-funktionalen Anforderungen weiterhin und müssen erfüllt werden.

Beispielsweise möchten Sie weiterhin in der Lage sein, einen einzelnen, langlaufenden Agenten innerhalb eines sequenziellen Workflows je nach Auslastungsszenario und Bedarf hoch- oder runterzuskalieren. Ein agentenbasierter Workflow sollte Anfragen gleichzeitig bearbeiten können, um Szenarien mit mehreren Benutzern zu unterstützen. Agentenfehler (aufgrund von Netzwerkfehlern oder anderen Gründen) sollten so behandelt werden können, dass sie möglichst wenig Einfluss auf das Gesamtsystem haben. Es sollte im Fehlerfall nicht erforderlich sein, dass der gesamte Workflow von vorne begonnen werden muss. Natürlich könnten Sie einen Workflow von vorne beginnen oder Workflows als Ganzes skalieren, anstatt nur einzelne Agenten. Das wäre jedoch so, als würde man in einem Microservice-Szenario ganze virtuelle Maschinen skalieren, anstatt nur Container. Das bedeutet jedoch auch, dass es einfach nicht kosteneffizient ist. Und das gilt umso mehr für Aufgaben, die von der KI übernommen werden!

Wenn Sie KI-Aufgaben wiederholen müssen, kann dies sehr kostspielig sein, da Sie ggf. für jedes an ein LLM gesendete und von diesem empfangene Token bezahlen müssen. Das Cachen von Agenten-Antworten und das Speichern von Zwischenergebnissen, das Verwalten von Historien usw. können solche Kosten mindern. Die Umsetzung einer solchen Lösung kann aber auch komplex und aufwändig sein. Das Gute daran: Je nach verwendetem KI-Framework erhalten Sie eine mehr oder weniger gute Unterstützung für den Neustart eines Workflows an Zwischenkontrollpunkten.

Was ist also die empfohlene Lösung? Entkoppeln Sie Ihre Agenten! Entkoppeln Sie sie so weit wie möglich und wählen Sie eine asynchrone Kommunikation, z. B. mittels Message Broker. Wenn ein Agent nicht verfügbar ist, bleibt die Nachricht in der Warteschlange und wird gelesen, sobald der Agent wieder arbeitsfähig ist. Müssen Sie einen Agenten hochskalieren? Erzeugen Sie einfach neue Agenten, die aus derselben Warteschlange lesen können. Tritt bei einem Zwischenschritt des Workflows ein Fehler auf? Der Status wird als Nachricht in einer Warteschlange gespeichert und die Verarbeitung fortgesetzt, sobald der fehlgeschlagene Schritt erfolgreich ist. Was, wenn ein fehlgeschlagener Schritt nie erfolgreich ist? Der Status kann automatisch zur weiteren (ggf. manuellen) Überprüfung in eine Dead-Letter-Queue verschoben werden.

Stellen Sie Ihre Anforderungen in Frage!

Ein typisches Gegenargument, das diskutiert werden kann, lautet: Warum nicht einfach „modularisieren“, indem man KI-Tools aus derselben Codebasis aufruft und Tools als wiederverwendbare Bibliotheken implementiert? Dieser Ansatz hat zwar seine Vorzüge, aber die Entscheidung hängt von Ihren spezifischen Anforderungen ab (wie im Abschnitt „Anforderungsanalyse“ erläutert). Es ist nur sinnvoll, ein agentenbasiertes oder ein vollständig asynchrones agentenbasiertes System zu verwenden, wenn es Ihnen auch Vorteile bringt oder zur Erfüllung der Anforderungen notwendig ist. Auch hier gibt es wieder eine Analogie zur Implementierung eines verteilten Systems mit Microservices: Tun Sie dies nur, wenn Ihr Anwendungsfall davon profitiert und Ihre nicht-funktionalen Anforderungen dies nahelegen.

Bei der Frage „Tooling vs. Agenten“ geht es also darum, was Sie erreichen wollen. Im Kern könnte ein „dummer Agent“ als bloßes Werkzeug betrachtet werden. Was einen Agenten jedoch wirklich zu einem Agenten macht, ist seine eigenständige Handlungsfähigkeit, d. h. seine Fähigkeit, Schlussfolgerungen zu ziehen, Entscheidungen zu treffen und autonom zu handeln, anstatt lediglich vordefinierte Funktionen auszuführen. Tools und Bibliotheken haben also ihre Daseinsberechtigung (z. B. als Teil eines Agenten!), erfüllen aber einen ganz anderen Zweck.

Zu den wichtigsten Vorteilen einer vollständig entkoppelten, asynchronen, agentenbasierten Architektur gehören:

• Echte Entkopplung: Einzelne Agenten können unabhängig voneinander skaliert werden. Im Gegensatz zu Bibliotheken in einem Monolithen, wo die Skalierung einer Komponente oft die Skalierung des gesamten Systems erzwingt. Die Modularisierung durch Bibliotheken kann auch versteckte Abhängigkeiten mit sich bringen (z. B. gemeinsame Konfigurationen wie Endpunkt-URLs oder aufgrund von Versionsproblemen) und somit unerwünschte Kopplungen verursachen.
• Klare Trennung der Aufgabenbereiche: Agenten arbeiten als eigenständige Einheiten in einem dedizierten Bereich, wodurch unbeabsichtigte Nebenwirkungen reduziert werden. Im Gegensatz dazu können bibliotheksbasierte Tools auf derselben Zustandsverwaltung basieren, gemeinsame Abhängigkeiten teilen oder gleiche Ausführungskontexte nutzen, wodurch die Grenzen zwischen den Verantwortungsbereichen verschwimmen.
• Operative Flexibilität: Entkoppelte Agenten können bereitgestellt, aktualisiert oder ersetzt werden, ohne das gesamte System zu stören. Das ist ein Grad an Isolation, den eine bibliotheksbasierte Modularität nicht erreichen kann.

Wie im vorigen Abschnitt ausführlich erläutert, lässt sich eine Entkopplung am besten durch vollständig asynchrone Kommunikationsmethoden erreichen.

Die Quintessenz

Asynchronität ist der Schlüssel für ein agentenbasiertes KI-System in einer groß angelegten Produktionsumgebung mit vielen Benutzern. Wiederholen Sie nicht die Fehler der Vergangenheit und halten Sie nicht an einem schwer skalierbaren oder wartungsintensiven monolithischen Design fest.

Das Entwerfen von Software und die Auswahl der richtigen Architektur sind keine trivialen Aufgaben. Das Gleiche gilt (oder gilt sogar noch mehr) für die Entwicklung von KI- und agentenbasierter KI-Software. Wir bei der CID verfügen über mehr als 17 Jahre Erfahrung im Bereich KI und fast 30 Jahre Erfahrung in der Softwarearchitektur. Wir können Sie und Ihr Unternehmen unterstützen, indem wir Ihre KI-Anwendungsfälle und agentenbasierte KI-Ideen diskutieren und mit Ihnen erörtern, wie diese Ihrem Unternehmen zugutekommen können. Wir können Ihnen dabei helfen, die geeigneten funktionalen und nicht-funktionalen Anforderungen zu bestimmen. Wir können Sie auf dem Weg begleiten, der Sie zu einer produktionssicheren Implementierung eines agentenbasierten KI-Systems führt, das – um den Kreis zu schließen – langfristig funktioniert und auch kurzfristig nicht ausfällt.

Bitte setzen Sie sich mit uns in Verbindung, damit wir besprechen können, wie wir Ihre KI-Agenten zu Ihrem Vorteil einsetzen können.