Ereignisgesteuerte KI-Agenten-Architektur

Ereignisgesteuerte KI-Agenten-Architektur

Eine ereignisgesteuerte KI-Agenten-Architektur ermöglicht es KMU, automatisch und intelligent auf Geschäftsereignisse zu reagieren, in Echtzeit und ohne menschliches Eingreifen für Routinevorgänge. Dieser Referenzartikel beschreibt die Architektur, ihre Komponenten und ihre Anwendung im KMU-Kontext.

Was ist eine ereignisgesteuerte Architektur?

In einer ereignisgesteuerten Architektur (Event-Driven Architecture, EDA) lösen Geschäftsereignisse automatisch Aktionen aus. Ein Ereignis kann alles sein: eine neue Bestellung, ein Kundenanruf, eine Lagerbestandsänderung, eine E-Mail oder ein Terminwunsch. Jedes Ereignis wird erfasst, analysiert und, wenn definierte Bedingungen erfüllt sind, löst es eine automatische Reaktion aus.

Der entscheidende Unterschied zu klassischer Automatisierung: In einer EDA muss das auslösende System nichts über die reagierenden Systeme wissen. Ihr Online-Shop "weiss" nicht, dass eine Bestellung gleichzeitig eine Rechnung in der Buchhaltung, ein Versandlabel bei der Post und eine Bestätigungs-E-Mail auslöst. Er publiziert einfach das Ereignis "Neue Bestellung", und die einzelnen Agenten reagieren eigenständig.

Architektur-Komponenten

Die Architektur besteht aus sechs Hauptkomponenten, die wir im Folgenden einzeln beschreiben.

Komponente 1: Ereignisquellen (Event Sources)

Ereignisquellen sind die Systeme, die Geschäftsereignisse erzeugen. In einem typischen KMU sind das: das Online-Shop-System (neue Bestellungen, Retouren, Kundenbewertungen), das E-Mail-System (eingehende Anfragen, Beschwerden, Auftragsbestätigungen), das Kassensystem (Transaktionen, Tagesabschlüsse), das Telefonsystem (Anrufe, Sprachnachrichten), die Website (Formulareinreichungen, Chat-Nachrichten) und der Kalender (neue Termine, Absagen, Änderungen).

Jede dieser Quellen wird über Konnektoren an den Event Bus angebunden, standardisierte Schnittstellen, die Ereignisse in ein einheitliches Format übersetzen.

Komponente 2: Event Bus (Nachrichtenbus)

Der Event Bus ist das zentrale Nervensystem der Architektur. Er empfängt Ereignisse von allen Quellen, normalisiert sie in ein einheitliches Format und verteilt sie an die registrierten Agenten. Für KMU-Implementierungen empfehlen wir leichtgewichtige Lösungen wie Redis Streams oder eine einfache Nachrichtenwarteschlange. Enterprise-Lösungen wie Kafka sind für die meisten KMU überdimensioniert.

Der Event Bus garantiert, dass kein Ereignis verloren geht, auch wenn ein Agent temporär nicht verfügbar ist. Ereignisse werden zwischengespeichert und bei Wiederherstellung des Agenten nachgeliefert.

Komponente 3: KI-Agenten (Event Consumers)

Die KI-Agenten sind die eigentlichen Handlungsträger. Jeder Agent ist auf einen bestimmten Aufgabenbereich spezialisiert. Der Kundenservice-Agent reagiert auf Kundenanfragen per E-Mail, Chat und Telefon. Der Bestell-Agent verarbeitet neue Bestellungen, prüft Verfügbarkeit und erstellt Auftragsbestätigungen. Der Finanz-Agent erstellt Rechnungen, verbucht Zahlungen und erstellt Mahnungen. Der Logistik-Agent plant Versand, erstellt Labels und verfolgt Sendungen.

Jeder Agent hat drei Kernfähigkeiten: Er kann Ereignisse empfangen und verstehen, er kann Entscheidungen auf Basis von Geschäftsregeln und KI-Modellen treffen, und er kann Aktionen in externen Systemen ausführen.

Komponente 4: Kontextspeicher (Context Store)

Der Kontextspeicher enthält das Wissen, das die Agenten für ihre Entscheidungen brauchen: Kundenhistorie (frühere Bestellungen, Präferenzen, Kommunikationshistorie), Produktinformationen (Preise, Verfügbarkeit, Spezifikationen), Geschäftsregeln (Rabattrichtlinien, Eskalationsregeln, SLAs) und den laufenden Kontext (aktuelle Konversationen, offene Aufträge, Status von Prozessen).

Der Kontextspeicher ermöglicht es den Agenten, kontextbezogene Entscheidungen zu treffen, nicht nur auf Basis des aktuellen Ereignisses, sondern unter Berücksichtigung der gesamten Kundenbeziehung und Geschäftssituation.

Komponente 5: Aktionsausführung (Action Executor)

Der Action Executor ist die Schnittstelle zu Ihren bestehenden Systemen. Wenn ein Agent eine Entscheidung getroffen hat, wird die Aktion über den Action Executor ausgeführt: Rechnung in Bexio erstellen, Versandlabel bei Swiss Post generieren, Bestätigungs-E-Mail versenden, Lagerbestand aktualisieren.

Wichtig: Jede Aktion hat ein Fallback. Wenn die Bexio-API nicht erreichbar ist, wird die Rechnung in eine Warteschlange gestellt und automatisch erstellt, sobald das System wieder verfügbar ist.

Komponente 6: Monitoring und Alerting

Das Monitoring überwacht alle Komponenten in Echtzeit: Wie viele Ereignisse werden verarbeitet? Wie lang ist die Verarbeitungszeit? Wie hoch ist die Fehlerrate? Welche Agenten haben Probleme?

Bei Anomalien, zum Beispiel einer plötzlich steigenden Fehlerrate oder einer ungewöhnlich langen Verarbeitungszeit, werden automatisch Warnmeldungen an das verantwortliche Team gesendet.

Datenfluss: Ein konkretes Beispiel

Betrachten wir den Datenfluss für eine typische Bestellung. Ein Kunde bestellt um 14:23 Uhr über den Online-Shop. Das Shop-System erzeugt das Ereignis "Neue Bestellung" mit den Bestelldaten und sendet es an den Event Bus. Der Event Bus verteilt das Ereignis an drei registrierte Agenten. Der Bestell-Agent prüft die Bestelldaten, validiert die Lieferadresse über den Kontextspeicher, bestätigt die Verfügbarkeit und sendet eine Auftragsbestätigung an den Kunden. Der Finanz-Agent erstellt die Rechnung in Bexio basierend auf den Bestellpositionen und den Kundendaten aus dem Kontextspeicher. Der Logistik-Agent erstellt das Versandlabel bei Swiss Post und plant den Versand für den nächsten Werktag. Das Monitoring protokolliert den gesamten Vorgang: Bestellung empfangen (14:23:01), Bestellung validiert (14:23:03), Auftragsbestätigung gesendet (14:23:05), Rechnung erstellt (14:23:08), Versandlabel generiert (14:23:12). Gesamtdauer: 11 Sekunden. Manuell hätte dieser Vorgang 8-12 Minuten gedauert.

Wann ist diese Architektur die richtige Wahl?

Die ereignisgesteuerte KI-Agenten-Architektur eignet sich besonders, wenn mehrere Systeme auf dasselbe Geschäftsereignis reagieren müssen, Echtzeitverarbeitung wichtig ist, die Lösung schrittweise erweitert werden soll (neue Agenten können jederzeit hinzugefügt werden) und verschiedene Geschäftsbereiche voneinander entkoppelt werden sollen.

Sie ist weniger geeignet für einfache Punkt-zu-Punkt-Integrationen (z.B. nur WooCommerce mit Bexio verbinden) oder für Batch-Verarbeitung (z.B. monatliche Auswertungen).

Implementierungsempfehlung für KMU

Für ein typisches KMU empfehlen wir einen schrittweisen Aufbau: Monat 1-2 deckt Grundinfrastruktur ab mit Event Bus, einem Agenten, Monitoring. Monat 3-4 dient der Erweiterung mit zwei bis drei weiteren Agenten und Kontextspeicher. Monat 5-6 widmet sich der Optimierung durch Feintuning, erweiterte Geschäftsregeln, Analytics.

Die geschätzten Kosten für eine KMU-Implementierung liegen bei CHF 20'000-35'000 für die Erstimplementierung und CHF 500-1'000 pro Monat für den laufenden Betrieb. Der typische ROI wird nach 4-6 Monaten erreicht.