Wie Agentic AI in Camunda 8.8 funktioniert und welchen Mehrwert es bietet

Viele Aufgaben und Entscheidungen in (Teil-)automatisierten Prozessen werden nach wie vor von Menschen durchgeführt. Das hat Vorteile, da Menschen autark und flexibel agieren können. Auf der anderen Seite sind sie jedoch auch fehleranfällig, nicht immer verfügbar und in Zeiten des Fachkräftemangels sind diese Ressourcen begrenzt und somit kostspielig.

Der neue AI Agent Connector in Camunda 8.8 Alpha wurde entwickelt, um einen KI-Agenten systematisch mit Tools und einem Feedback-Loop zu steuern. Wir haben den Agenten so konfiguriert, dass er Routinefälle eigenständig bearbeiten kann – dadurch wird der:die Sachbearbeiter:in spürbar entlastet und kann seine:ihre Zeit für komplexere Fälle nutzen.

In diesem Beitrag erfährst du anhand eines konkreten Anwendungsfalls, wie der KI-Agent in Camunda 8 funktioniert, welche praktischen Vorteile er bietet und wo aktuell noch Limitationen bestehen.

Kurz und knapp

Ein fiktives Beispiel: Im Prozess einer Kfz-Versicherung, der mit der Schadenseinreichung durch eine Werkstatt beginnt, ist eine eindeutige Versicherungsscheinnummer (VSNR) erforderlich, um den Leistungsanspruch zu prüfen. Diese Nummer wird bisher von Sachbearbeiter:innen ermittelt.

Der KI-Agent in unserem Anwendungsfall ermöglicht es, die VSNR zu einer Schadenmeldung automatisiert zu ermitteln, wodurch manuelle Eingriffe reduziert und weniger Ressourcen benötigt werden. Mithilfe von intelligenten Tools kann der Agent Informationen aus hochgeladenen Dokumenten und Kundendaten nutzen, um die VSNR automatisch zu erfassen. Falls keines dieser Tools zum Erfolg führt, eskaliert der Agent schließlich an einen Menschen. Trotz einiger Herausforderungen des derzeitigen Alpha-Features bietet Camunda ein transparentes KI-Agenten-System mit einem kontrollierbaren Grad an Determinismus, das für bestimmte Anwendungsfälle schon einsatzfähig ist.

Was ist der KI-Agent in Camunda 8 ?

Der KI-Agent in Camunda 8.8 kann mit einem Tool-Set, also einer definierten Sammlung ausführbarer Funktionen, autonom ein definiertes Ziel erreichen. Damit kriegt der KI-Agent praktisch seinen eigenen Werkzeugkasten, aus dem er eigenständig das passende Werkzeug nutzen oder wechseln kann, wenn ein einziges nicht ausreicht. Pro Iteration können mehrere Tools ausgeführt werden, und dasselbe Tool kann (über verschiedene Iterationen hinweg) mehrfach verwendet werden.

Der Agent besteht aus drei wesentlichen Komponenten. Wir definieren die Bestandteile zunächst abstrakt und gucken uns dann an, wie das im konkreten Beispiel aussieht.

1. Ad-hoc Subprozess: In einem Multi-Instance Ad-hoc Subprozess definieren wir die Tools, die dem Agenten zur Verfügung stehen. Diese können User-Tasks oder automatisierte Service-Tasks sein. Dabei muss ein Tool jedoch nicht zwingend aus einem einzelnen Task bestehen – es kann sich ebenso um größere Prozessfragmente handeln, die aus mehreren, aufeinander abgestimmten Tasks bestehen. Wichtig ist, dass im Modell für die Tools sinnvolle Dokumentationen hinterlegt sind, da diese textuellen Beschreibungen vom LLM zur Entscheidungsfindung genutzt werden. Für den Subprozess müssen Konfigurationen wie die Input-Collection (welche Tools aufgerufen werden sollen) und Output-Collection (Ergebnisse der Tool-Calls) vorgenommen werden, um über Output Mappings ggf. Prozessvariablen zu aktualisieren. Mithilfe der aktualisierten Prozessvariablen kann das LLM im AI Agent Task anschließend entscheiden, ob noch weitere Tools benötigt werden, oder ob das Ziel schon erreicht wurde. Es liegt also ein iteratives Verhalten vor – der Agent wählt so lange Tools aus, bis das Ziel erreicht ist.

2. AI Agent Task: Hier wird ein LLM-Call getätigt, um die für die Erreichung des Ziels benötigten Tools auszuwählen. Es sind zwei Prompts erforderlich: Der System-Prompt liefert einen allgemeinen Kontext und Regeln, z.B. dass nur die verfügbaren Tools ausgeführt werden dürfen oder dass das LLM vor der Toolauswahl ein Chain-of-Thought-Format einhalten soll. Der User-Prompt kann hingegen genutzt werden, um das Ziel zu definieren und relevante Inputs zu liefern. Dazu können Prozessvariablen als Prompt-Parameter genutzt werden. Zusätzlich sind die API-Credentials für den LLM-Provider (z.B. OpenAI) zu konfigurieren. Wichtig ist zudem, die ID des Ad-hoc Subprozesses zu hinterlegen, der die verfügbaren Tools enthält.

3.  Agenten-Schleife: Eine Schleife sorgt dafür, dass der Agent weitere Tools ausführt, solange das Ziel nicht erreicht ist. Der AI Agent Task trifft eine Toolauswahl, woraufhin ein XOR-Gateway anschließend darüber entscheidet, ob der Sequenzfluss in den Ad-hoc Subprozess geführt wird, wo die Tools dann tatsächlich ausgeführt werden, oder ob die Schleife verlassen werden soll. Falls der Ad-hoc Subprozess gewählt wird, wird der Sequenzfluss anschließend wieder in den AI Agent Task geführt.

In unserem konkreten Beispiel sieht dies wie folgt aus, wobei “VSNR Ermittlungstools auswählen” der AI Agent Task ist.

Use Case: Kfz-Schadenprozess

In unserem Anwendungsfall kann eine Werkstatt über ein Online-Abrechnungssystem Schadenfälle direkt einreichen. Der Prozess beginnt mit der Angabe wichtiger Daten wie Kundeninformationen, Fahrzeugdetails sowie des Schadentyps und der Höhe des Schadens über eine entsprechende Maske. Zusätzlich wird ein PDF-Dokument (Rechnung oder Kostenvoranschlag) hochgeladen.

Falls bekannt, soll zudem die VSNR eingegeben werden, um den Schaden einem Vertrag zuordnen und somit korrekt verarbeiten zu können. Wird diese nicht über die Eingabemaske übermittelt, muss sie über andere Wege ermittelt werden.

Eingabemaske des Online-Abrechnungssystems: Verpflichtende Felder sind durch einen blauen Punkt gekennzeichnet.

Implementierung des KI-Agenten im Use Case

Um die VSNR zu ermitteln, falls diese nicht vorhanden ist, stellen wir dem KI-Agenten drei Tools zur Verfügung.

1. PDF scannen: Dieses Tool ist ein automatisierter Service-Task, implementiert als JobWorker. Aus der hochgeladenen PDF-Datei (Rechnung oder Kostenvoranschlag) wird per LLM-Call mit strukturiertem Output versucht, zwei Aspekte zu extrahieren: die VSNR selbst, und die Rechnungsadresse, also die Anschrift des betroffenen Kunden. Falls Informationen extrahiert wurden, werden die entsprechenden Prozessvariablen aktualisiert.

2. VSNR aus Kundeninformationen ermitteln: Mithilfe von zwei sequentiellen Service-Tasks, die ebenfalls als JobWorker implementiert sind, versuchen wir automatisiert, mithilfe vom Kunden- und Vertragssystem, die VSNR zu ermitteln. Dafür wird zunächst aus der Anschrift (Name und Adresse) die Kundennummer ermittelt. Für eine gegebene Kundennummer können über das Vertragssystem anschließend alle zugehörigen Verträge abgefragt werden. Falls genau ein Vertrag zu dieser Kundennummer vorliegt, können wir als VSNR die VSNR dieses eindeutigen Vertrags verwenden.

3. VSNR manuell ermitteln: Als letztes Mittel wird dem Agenten ein User-Task als Tool zur Verfügung gestellt, bei dem an eine:n Sachbearbeiter:in eskaliert wird, um die VSNR manuell zu ermitteln.

Um dem LLM eine Entscheidungsgrundlage zu geben, ob weitere Tools benötigt werden, und falls ja, welche, konfigurieren wir den User Prompt im AI Agent Task. Wir definieren das Ziel, nämlich die VSNR zu ermitteln, und übergeben gleichzeitig den aktuellen Status der VSNR und der Kundendaten als Prozessvariablen. Zudem beschreiben wir hier mögliche Lösungswege, wie eine VSNR ermittelt werden kann. Der Prompt sieht folgendermaßen aus:

Wenn die VSNR leer ist (also nicht existiert oder ein leerer String ist), dann wähle ein Tool aus, um diese zu ermitteln. Die VSNR kann ermittelt werden, indem diese direkt aus der PDF ausgelesen wird (falls vorhanden), oder aus Kundeninformationen (Name und Anschrift) hergeleitet werden, falls diese vollständig sind. Falls diese zwei Ansätze nicht zum Erfolg führen, muss ein Mensch die VSNR manuell ermitteln. Es liegen aktuell folgende Kundeninformationen vor: {kunde}  . Aktuelle VSNR: {vsnr}

Um zu steuern, welche Tools im Subprozess ausgeführt werden, legt der Agent im AI Agent Task eine Liste der auszuführenden Tools als Prozessvariable toolCalls an, welche später als Input-Collection für den Ad-hoc Subprozess fungiert. Anschließend wird am XOR-Gateway bestimmt, ob der Ad-hoc Subprozess mit den Tools auch ausgeführt werden soll. Dafür überprüfen wir, ob die VSNR bereits vorliegt und ob wir schon zu häufig durch die Schleife gelaufen sind. Falls eine der beiden Bedingungen erfüllt ist, verlassen wir die Schleife und fahren mit dem Prozess fort.

Auswertung mit verschiedenen Testfällen

Mit einigen Testfällen konnten wir leicht überprüfen, dass der KI-Agent tatsächlich die vorhandenen Tools, ggf. auch mehrfach, nutzt, um das Ziel zu erreichen. Alle Testfälle sind so gestaltet, dass das Feld „Versicherungsscheinnummer“ im Formular des Schadensmeldungssystems leer geblieben ist. Für einen Schadenfall, bei dem die vollständige Kundenanschrift im Formular eingetragen wurde und bei dem der:die betroffene Kund:in genau einen Vertrag bei der Versicherung hat, führt der einmalige Aufruf des Tools “VSNR aus Kundeninfos ermitteln” zum Erfolg. Falls im Formular keine vollständige Adresse, sondern beispielsweise nur der Name vorliegt, die hochgeladene Rechnung jedoch die VSNR enthält, wählt der Agent das PDF-Scan-Tool aus und erreicht so ebenfalls mit nur einem Toolaufruf das Ziel. Liegt die VSNR auf der Rechnung nicht vor, kann das PDF-Scan-Tool trotzdem hilfreich sein, indem die Kundenanschrift extrahiert wird und anschließend aus den Kundeninformationen die VSNR ermittelt wird (Annahme: Kund:in hat nur einen Vertrag). Dieser Testfall insbesondere demonstriert das agentische Verhalten, da mehrere Tools in einer bestimmten Reihenfolge genutzt werden, um das Ziel zu erreichen. Trotzdem gibt es auch Fälle, in denen schließlich ein Mensch benötigt wird, beispielsweise wenn auf der Rechnung keine VSNR spezifiziert ist und der:die betroffene Kund:in mehr als einen Vertrag hat. In diesem Fall werden zunächst die automatisierten Tool-Optionen „ausprobiert”, bevor in der dritten Iteration der User-Task ausgewählt wird.

In den o.g. Testfällen zeigt sich der Mehrwert des KI-Agenten hinsichtlich Prozessautomatisierung. Es gibt viele Szenarien, in denen menschliches Eingreifen nicht nötig ist, und stattdessen ausschließlich automatisierte Tools die Aufgabe erledigen können. Trotzdem gibt es, falls notwendig, immer noch einen Human-in-the-Loop, der einschreiten kann.

Herausforderungen und Limitationen

Bei der Implementierung unseres Anwendungsfalls sind einige Herausforderungen aufgetreten, die die Anwendbarkeit beeinträchtigen könnten. Es ist wichtig zu betonen, dass es sich um ein Alpha-Feature handelt, das von Camunda aktiv weiterentwickelt wird.

Eine der Herausforderungen war, dass der Ad-hoc Subprozess Stand jetzt eine Multi-Instance sein muss. In manchen Anwendungsfällen kann es sinnvoll sein, dass pro Iteration nur ein Tool ausgeführt werden kann, um beispielsweise Kosten durch unnötige Funktionsaufrufe zu vermeiden.

Da der Ad-hoc Subprozess nun aber als Multi-Instance konfiguriert sein muss, muss über den Prompt gesteuert werden, dass der Agent bzw. das LLM pro Iteration immer nur genau ein Tool auswählt. Bei Testläufen ist uns jedoch aufgefallen, dass der Agent in einer Iteration gelegentlich auch zwei Tools auswählt. Das hat er getan, obwohl wir im System Prompt unmissverständlich klar gemacht haben, dass immer genau ein Tool ausgewählt werden soll. Das Konfigurieren einer sehr niedrigen LLM-Temperatur (ein Parameter, der die Kreativität und den Grad an Determinismus eines LLMs bestimmt) konnte dies ebenfalls nicht zuverlässig verhindern.

Außerdem haben wir Fälle beobachtet, in denen der Agent kein Tool auswählt, obwohl das Ziel noch nicht erreicht ist. Durch Inspizieren der Variablen in Operate konnten wir hier die Ursache des unerwarteten Verhaltens weiter eingrenzen. Normalerweise schreibt das LLM die ausgewählten Tools via strukturierten Output in die Liste agent.toolCalls. Es ist jedoch aufgefallen, dass in den angesprochenen Fällen die Liste agent.toolCalls leer bleibt, obwohl in der Variable agent.responseText sehr wohl beschrieben wird, welches Tool eingesetzt werden sollte.

Beispiel:

"toolCalls":[],"responseText":"[…] The next step is to attempt to identify the VSNR using the available customer information through the serviceTaskVsnrAusKundeninfosErmittlen tool […]”

Dieses Verhalten macht es aktuell recht umständlich, festzustellen, ob der Agent der Meinung ist, dass er seine Aufgabe erledigt hat und keine weiteren Tool-Calls benötigt, oder aber ob besagter technischer Fehler aufgetreten ist und der Agent eigentlich noch weitere Tool-Calls für notwendig erachtet.

Da im besagten Fall die Input-Collection für den Ad-hoc Subprozess leer ist, kommt es hin und wieder zu Iterationen ohne Toolaufruf und somit zu verschwendeten LLM-Calls im AI Agent Task. Eine Endlosschleife ist dadurch jedoch nicht zu befürchten, da sich die maximale Anzahl an LLM-Calls im AI Agent Task beschränken lässt. Da das Erreichen dieser maximalen Anzahl allerdings zu einem unschönen Incident am AI Agent Task führt, überprüfen wir zusätzlich einfach am XOR-Gateway, ob wir die von uns gewünschte Anzahl Durchläufe schon überschritten haben, verlassen in diesem Fall die AI-Agent-Schleifen und leiten zu einer manuellen Ermittlung weiter.

Transparenz und Prozessmonitoring

Ein großer Vorteil der Agentenorchestrierung in Camunda ist, dass wir durch Operate (Introduction | Camunda 8 Docs) die Möglichkeit haben, Prozessinstanzen zu inspizieren und somit auch das Verhalten des Agenten zu überwachen. Nachfolgend sieht man beispielsweise die Prozessmodell-Ansicht einer Prozessinstanz mit Execution Counts für den Testfall, bei dem schließlich an einen Menschen eskaliert wird. Es ist zu erkennen, dass es insgesamt drei Iterationen gab und jedes Tool einmal ausgeführt wurde.

Operate: Prozessmodell-Ansicht zu einer spezifischen Prozessinstanz mit Execution Counts. Beachte: Aufgrund eines zwischendurch mit einer der Alpha-Versionen hinzugekommenen Bugs haben wir hinter dem ad-hoc Subprozess einen Script-Task eingebaut, um die relevanten Prozessvariablen zu aktualisieren.

Ein weiterer bedeutender Vorteil ergibt sich durch die Nutzung von Optimize (What is Optimize? | Camunda 8 Docs) , das speziell zur Analyse und kontinuierlichen Verbesserung von Prozessen entwickelt wurde und eine tiefgehende Auswertung von Prozesskennzahlen wie Durchlaufzeiten, Ausführungsfrequenzen und Engpässen ermöglicht. Konkret können wir damit z. B. beobachten, wie viele Ressourcen unser KI-Agent einspart, wie oft sich das zugrunde liegende LLM möglicherweise nicht an die Prompt-Anweisungen hält, oder wie oft „leere” Iterationen ohne Toolaufruf vorkommen. Dafür haben wir eigene Berichte in Optimize konfiguriert und diese in ein Dashboard eingebettet, um relevante Informationen auf einen Blick abrufen und potenzielle Schwachstellen frühzeitig identifizieren zu können.

Optimize: Bericht mit einer Heatmap-Visualisierung

Optimize: Selbst definierte Berichte für das Agenten-Monitoring

Fazit und Ausblick

Trotz der identifizierten Herausforderungen überwiegen die potenziellen Vorteile des KI-Agenten in unserem Anwendungsfall zur Ermittlung der VSNR. Die Probleme, wie die Unzuverlässigkeit des strukturierten Outputs, sind zwar relevant, jedoch lösbar, beispielsweise durch eine angepasste Konfiguration des XOR-Gateways.

Die Automatisierung von Aufgaben durch den Agenten reduziert die Abhängigkeit von manuellen Eingriffen, ermöglicht signifikante Effizienzgewinne und erlaubt es so, Sachbearbeiter:innen-Ressourcen auf komplexe, nicht einfach automatisiert lösbare Fälle zu fokussieren. Zudem ermöglichen Operate und Optimize eine hohe Transparenz und Überwachbarkeit des Agenten – Eigenschaften, die für moderne Agentenorchestrierungssysteme unerlässlich sind.

Der KI-Agent stellt bereits jetzt eine innovative Lösung für die Prozessoptimierung dar und wird voraussichtlich durch weitere Verbesserungen in stabilen Versionen noch einsatzfähiger. Gleichzeitig können wir guten Gewissens keine universelle Empfehlung aussprechen, den Agenten sofort in seine Prozesse zu integrieren, da die Verwendbarkeit stark vom jeweiligen Anwendungsfall abhängt. Insbesondere die Tatsache, dass Prompt-Anweisungen bzgl. der Toolauswahl nicht zuverlässig befolgt werden, kann darüber hinaus aktuell noch zu Problemen führen.

Haben wir dein Interesse geweckt?

In diesem Beitrag haben wir gezeigt, wie man den KI-Agenten in Camunda 8.8 einsetzen kann. Vielleicht hast du einen anderen Anwendungsfall, in dem ein KI-Agent ressourcenintensive Aufgaben übernehmen und die Durchlaufzeit deines Prozesses verbessern kann.

Wenn du mehr darüber erfahren möchtest, wie du diese Lösungen implementieren kannst, zögere nicht, uns zu kontaktieren. Bei der viadee stehen unsere Expert:innen bereit, um dich bei der Entwicklung maßgeschneiderter Lösungen zu unterstützen.

Autoren

Dr. Christoph Schönnenbeck ist seit 2019 Berater bei der viadee. Sein Schwerpunkt liegt im Business Process Management und der Prozessautomatisierung insbesondere im Cloud-Umfeld.

Julian Kofferath ist seit 2024 als Werkstudent Teil der viadee Unternehmensberatung. Seine Tätigkeitsfelder umfassen Projekte in den Bereichen BPM und Data Science.