🤖 AI

A Process Harness for Uplifting Legacy Workflows to Agentic BPM: Design and Realization in CUGA FLO

Dieses Paper führt das „Process Harness“ ein, einen Mechanismus, der eine durch Policies gesteuerte agentische Schicht um bestehende deterministische Workflow-Engines integriert, um Agentic BPM zu ermöglichen, welches durch das Task-Decision-Flow (TDF)-Modell rigoros definiert und im CUGA FLO-System realisiert wird, um ein Gleichgewicht zwischen struktureller Compliance und adaptiver, durch Policies gerahmter Autonomie herzustellen.

Ursprüngliche Autoren: Fabiana Fournier, Lior Limonad

Veröffentlicht 2026-06-26

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Fabiana Fournier, Lior Limonad

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben eine sehr strikte, altmodische Fabrik-Montagelinie. Diese Linie ist darauf ausgelegt, perfekt zu sein: Sie folgt einer festen Karte, jeder Schritt ist vorprogrammiert und sie macht niemals Fehler. Sie ist jedoch auch unglaublich starr. Wenn ein Karton ankommt, der nicht der Standardgröße entspricht, oder wenn plötzlich eine neue Regelung der Regierung erscheint, stoppt die Maschine, geht kaputt oder benötigt einen Menschen, der hineinklettert, um sie manuell zu reparieren.

So funktioniert der Großteil der heutigen Business-Software (genannt BPM). Sie ist großartig für Routineaufgaben, aber schrecklich darin, mit Überraschungen umzugehen.

Stellen Sie sich nun vor, Sie könnten dieser Fabrik einen „intelligenten Aufseher“ geben, der lesen, denken und Urteile fällen kann, der aber nicht in der Lage ist, das Förderband zu berühren oder die Zahnräder der Maschine zu verändern. Dieser Aufseher kann lediglich Anweisungen an die menschlichen Bediener rufen oder kleine Umwege vorschlagen, aber die Maschine selbst führt das Kommando.

Dieses Paper stellt ein neues System namens CUGA FLO vor, das genau das tut. Es bezeichnet dieses System als einen „Process Harness“ (Prozess-Geschirr).

So funktioniert es, aufgeschlüsset in einfache Konzepte:

1. Die Kernidee: Das Geschirr (The Harness)

Denken Sie an ein Pferd. Das Pferd ist der Motor (das alte Workflow-System). Das Geschirr ist das Gestell, das man dem Pferd anlegt, um es zu führen. Man ersetzt nicht das Pferd; man fügt lediglich eine Steuerungsebene darüber hinzu.

Der alte Weg: Um mit einer Überraschung umzugehen, musste man den gesamten Fabrikboden (den Softwarecode) neu gestalten, noch bevor die Überraschung eintrat.
Der neue Weg (CUGA FLO): Sie lassen die Fabrik exakt so, wie sie ist. Sie legen ein „Process Harness“ um sie herum. Dieses Geschirr nutzt KI (speziell Large Language Models), um den Prozess zu beobachten. Wenn der Prozess einen bestimmten Kontrollpunkt erreicht, greift die KI ein, denkt über die Situation basierend auf einem Satz schriftlicher Regeln (Policies) nach und schlägt vor, was als Nächstes zu tun ist.

2. Die drei „intelligenten Assistenten“

Das Paper beschreibt, dass dieses Geschirr drei verschiedene Arten von KI-Assistenten verwendet, von denen jeder eine spezifische Aufgabe hat. Sie sind wie ein Team spezialisierter Manager:

Der Task Agent (Der Arbeiter):
- Aufgabe: Die eigentliche Arbeit erledigen.
- Analogie: Stellen Sie sich vor, eine Aufgabe lautet: „Prüfen Sie die Kreditwürdigkeit des Antragstellers.“ Im alten System erledigte dies ein Computerskript. Jetzt liest der Task Agent die unordentlichen Finanzdokumente, versteht sie und berechnet den Score.
- Regel: Er hat eine strikte Richtlinie: „Du darfst den Score berechnen, aber es ist dir nicht erlaubt, ‚Genehmigt‘ oder ‚Abgelehnt‘ zu sagen.“ Diese Entscheidung liegt bei jemand anderem.
Der Decision Agent (Der Verkehrspolizist):
- Aufgabe: Zu entscheiden, welchen Weg an einer Weggabelung einzuschlagen ist.
- Analogie: Die Montagelinie teilt sich in zwei Pfade auf: „Genehmigen“ oder „Ablehnen“. Der Decision Agent betrachtet den Score, den der Task Agent gerade erstellt hat. Er prüft die Regeln (z. B. „Wenn der Score über 0,6 liegt, gehe nach links“). Dann sagt er der Maschine, welchen Pfad sie nehmen soll.
- Regel: Er stellt sicher, dass die Entscheidung logisch ist und der schriftlichen Richtlinie folgt.
Der Flow Agent (Der Notfallmanager):
- Aufgabe: Die Karte während des laufenden Prozesses zu ändern.
- Analogie: Dies ist der mächtigste der drei. Stellen Sie sich vor, es gibt eine spezielle „Hook“ (eine Falltür) auf der Montagelinie. Wenn eine bestimmte Situation eintritt (wie ein VIP-Kunde oder ein regulatorischer Notfall), springt der Flow Agent ein. Er kann sagen: „Überspringe die nächsten drei Schritte“, „Stoppe die Linie“ oder „Füge genau hier einen neuen Schritt hinzu“.
- Regel: Er darf nur Dinge tun, die explizit durch eine „Hook Policy“ erlaubt sind. Er kann nicht einfach wahllos die Karte ändern; er muss den Regeln folgen.

3. Das „FRAME“ (Das Regelbuch)

Wie stellen wir sicher, dass die KI nicht durchdreht? Das Paper führt das FRAME ein.

Betrachten Sie das FRAME als ein riesiges, für Menschen lesbares Regelbuch (geschrieben in einfachem Englisch, wie eine Markdown-Datei). Jedes Mal, wenn ein KI-Assistent eine Entscheidung trifft, muss er zuerst dieses Regelbuch prüfen.

Der Task Agent prüft die „Task Rules“.
Der Decision Agent prüft die „Routing Rules“.
Der Flow Agent prüft die „Emergency Rules“.

Wenn die KI versucht, etwas zu tun, das im Regelbuch nicht erlaubt ist, stoppt das System sie. Dies stellt sicher, dass die KI durch menschliche Regeln „gerahmt“ (framed) wird und nicht einfach Dinge erfindet.

4. Das Beispiel der Kreditgenehmigung

Das Paper beweist die Funktionsweise anhand eines Kreditgenehmigungs-Beispiels:

Der Arbeiter (Task Agent) liest einen Kreditantrag und berechnet einen Kredit-Score.
Der Verkehrspolizist (Decision Agent) sieht, dass der Score hoch ist (0,82) und sagt: „Okay, das sieht gut aus, gehen wir auf den Pfad ‚Genehmigen‘.“
Der Notfallmanager (Flow Agent) sieht, dass die ID-Nummer des Antragstellers „4321“ ist. Obwohl der Score hoch ist, besagt das Regelbuch: „ID 4321 ist aufgrund einer neuen Regulierung gesperrt.“
Das Ergebnis: Der Flow Agent überschreibt die Entscheidung des Traffic Cops. Er nutzt eine „Hook“, um den Prozess sofort auf den Pfad „Ablehnen“ zu lenken und überspringt die Genehmigungsschritte komplett.

Warum ist das cool? Im alten System hätten Sie bereits vor Jahren einen speziellen „ID 4321“-Pfad in die Software einbauen müssen. Mit CUGA FLO aktualisieren Sie einfach heute die Textdatei (die Policy), und das System handhabt es sofort, ohne dass der Code umgeschrieben werden muss.

5. Warum das wichtig ist (Das „Beste aus beiden Welten“)

Das Paper argumentiert, dass dies ein großes Problem löst:

Alte Systeme sind sicher und strukturiert, können aber nicht auf Neues reagieren.
Reine KI kann sich an alles anpassen, ist aber riskant, unvorhersehbar und schwer zu auditieren.

CUGA FLO kombiniert diese. Das „Engine“ (die alte Software) garantiert, dass die Struktur sicher ist und der Karte folgt. Das „Harness“ (die KI) fügt die Fähigkeit hinzu, sich anzupassen, zu schlussfolgern und mit Überraschungen umzugehen, aber nur innerhalb der strengen Grenzen des Regelbuchs.

Zusammenfassung

Das Paper präsentiert CUGA FLO als einen Weg, alte, starre Business-Software in ein intelligentes, anpassungsfähiges System aufzuwerten, ohne die alte Software wegzuwerfen. Dies geschieht, indem das alte System in ein „Process Harness“ eingehüllt wird, das drei Arten von KI-Agenten (Arbeiter, Verkehrspolizisten und Notfallmanager) nutzt, die streng durch ein von Menschen geschriebenes Regelbuch (das FRAME) reglementiert werden. Dies ermöglicht es Unternehmen, unerwartete Situationen automatisch zu bewältigen und gleichzeitig eine strikte, prüfbare Aufzeichnung jeder Entscheidung zu führen.

Technisches Resümee: Ein Prozess-Harness zur Aufwertung von Legacy-Workflows zu Agentic BPM

1. Problemstellung

Konventionelle Business Process Management (BPM)-Systeme bieten zwar rigorose strukturelle Garantien, leiden jedoch unter zwei fundamentalen Einschränkungen in dynamischen Umgebungen:

Closed-World-Regime: Jede Abweichung vom Nominalpfad muss zur Designzeit antizipiert und explizit modelliert werden. Unvorhergesehene Situationen (z. B. regulatorische Änderungen, neuartige Bewerberprofile) führen das System in Fehlerzustände oder erfordern menschliche Interventionen, was häufig zu „Workarounds“ führt, die den formalen Prozessen umgehen.
Rigide Aufgabenausführung: Service-Tasks verlassen sich auf feste Skripte, die nicht in der Lage sind, auf unstrukturierte Eingaben zu reagieren, während User-Tasks Durchsatzbeschränkungen einführen. Die Engine selbst besitzt nicht die Kapazität für offenes Denken oder kontextuelle Anpassung.

Während Large Language Models (LLMs) über offenes Denken verfügen, sind aktuelle Integrationsparadigmen unzurereichend. Das „KI-augmentierte“ Paradigma (LLMs innerhalb spezifischer Aufgaben) lässt den gesamten Kontrollfluss starr. Umgekehrt fehlt dem „LLM-as-Planner“-Paradigma (LLMs, die Ausführungspläne außerhalb der Engine generieren) der Mechanismus, um strukturelle Konformität, Auditierbarkeit oder die Einhaltung von Compliance-Richtlinien zu garantieren. Es besteht ein Bedarf an einem System, das die strukturelle Rigidität deterministischer Workflow-Ausführung mit der kontextuellen Anpassungsfähigkeit von Richtlinien-gesteuerten Agenten versöhnt, ohne bestehende Workflow-Engines zu ersetzen.

2. Methodik: Der Process Harness und das TDF-Modell

Das Paper führt den Process Harness ein, einen Mechanismus, der eine Richtlinien-gesteuerte Agenten-Schicht über eine bestehende deterministische Workflow-Engine legt. Diese Schicht unterbricht definierte Kontrollpunkte, um Reasoning, Anpassung und Aufsicht beizutragen, während die Engine die strukturelle Autorität behält.

Die konzeptionelle Grundlage ist das Task–Decision–Flow (TDF) Modell, welches das LLM-Reasoning über drei distinkte, richtlinien-gebundene Agententypen zerlegt:

TaskAgent: Verantwortlich für die wissensintensive Aufgabenausführung. Er ersetzt hartcodierte Skripte durch richtlinien-gesteuerte LLM-Ausführung, die innerhalb einer spezifischen Aufgaben-Richtlinie ( $C_T$ ) operiert, um Domänen-Outputs zu erzeugen.
DecisionAgent: Verantwortlich für das Routing an Gateways pro Fall. Er ersetzt die statische Bedingungsprüfung durch LLM-Reasoning, das durch eine Entscheidungs-Richtlinie ( $C_D$ ) begrenzt ist. Entscheidend ist, dass er einen deterministischen Schritt zur Bedingungsbewertung vorschreibt, um sicherzustellen, dass die Gateway-Bedingung explizit geprüft wird.
FlowAgent: Verantwortlich für die Laufzeit-Anpassung des Flows via eines prinzipisierten Hook-Mechanismus. Er unterbricht designierte Sequenzflüsse (Hooks) und führt Reasoning unter Hook-Richtlinien ( $C_F$ ) durch, um strukturelle Interventionen (z. B. Überspringen, Vertauschen, Terminieren oder Topologie-Modifikation) zu empfehlen.

Governance-Framework (FRAME):
Das gesamte Agenten-Reasoning wird durch das FRAME ( $F$ ) begrenzt, einen aggregierten Satz menschlich lesbarer Richtliniendokumente. Dies gewährleistet „framed autonomy“, bei der Agenten innerhalb expliziter, auditierbarer Beschränkungen agieren. Eine sekundäre Governance-Schicht, action_permissions ( $\phi$ ), enumeriert explizit, welche Arten von strukturellen Interventionen ein FlowAgent instruieren darf, wodurch das LLM-Reasoning von den Ausführungsfähigkeiten der Engine getrennt wird.

Architektur (CUGA FLO):
Das Paper präsentiert CUGA FLO als erste Realisierung des TDF-Modells.

Entkopplung: Die Reasoning-Schicht (FlowAgent und seine Sub-Agenten) ist über einen Model Context Protocol (MCP) Bridge (implementiert als FastMCP-Server) vollständig von der Ausführungsschicht (WorkflowEngine) entkoppelt.
Interaktion: Die Workflow-Engine steuert die Ausführung und hält an Kontrollpunkten (Tasks, Gateways, Hooks) an, um Callbacks (execute_task, route_gateway, evaluate_hook) aufzurufen. Der FlowAgent verarbeitet diese Aufrufe unter Verwendung von ControlPointFlowKnowledge (Prozessmodell, Zustand, Historie) und liefert strukturierte Empfehlungen zurück.
Ausführung: Die Workflow-Engine erzwingt die strukturelle Konformität, indem sie die Empfehlungen des FlowAgents anwendet (z. B. Umverdrahtung von Flows für skip_to oder remove_node), ohne bereits ausgeführte Knoten erneut abzuspielen.

3. Zentrale Beiträge

Das Paper leistet fünf spezifische Beiträge:

Process Harness Paradigma: Einführung eines Mechanismus zur Aufwertung konventioneller Workflow-Systeme zu Agentic BPM, charakterisiert durch strukturelle Konformität, Richtlinien-Verantwortlichkeit und Laufzeit-Anpassungsfähigkeit.
Task–Decision–Flow (TDF) Modell: Eine formale konzeptionelle Dekomposition des LLM-Reasonings in drei Agententypen (Task, Decision, Flow), jeweils mit distinkten Rollen und Richtlinien-Beschränkungen.
FRAME Instanziierung: Formalisierung des aggregierten Richtliniensatzes ( $F$ ), der TDF-Prozesse steuert, und Demonstration, wie die Partitionierung von Richtlinien über Agententypen hinweg die Trennung der Zuständigkeiten auf LLM-Ebene erzwingt.
CUGA FLO Realisierung: Präsentation der ersten Implementierung des Process Harness, inklusive eines Hook-Mechanismus für Laufzeit-Anpassung und eines MCP-Bridges, der das Reasoning von der austauschbaren Workflow-Engine entkoppelt.
Empirische Demonstration: Validierung des Modells mittels eines Kreditgenehmigungs-Workflows, der alle drei Agententypen sowie einen regulatorischen Override-Hook nutzt, um zu zeigen, wie ein Hook eine Gateway-Entscheidung basierend auf einem anderen Kriterium (z. B. Antragsteller-ID) überschreiben kann, ohne die Gateway-Policy zu modifizieren.

4. Ergebnisse und Evaluierung

Das Paper demonstriert das System anhand einer Fallstudie eines Kreditgenehmigungs-Workflows:

Nominalfall: Eine Standard-Bonitätsprüfung (TaskAgent) generiert einen Score; ein DecisionAgent routet basierend auf einem Schwellenwert; ein FlowAgent-Hook bestätigt die Fortsetzung.
Regulatorischer Override-Fall: Ein Antragsteller mit hohem Score (ID 4321) wird durch den DecisionAgent basierend auf dem Score zur Genehmigung geroutet. Jedoch unterbricht ein FlowAgent-Hook den „Yes“-Fluss, wendet eine regulatorische Richtlinie (basierend auf der ID) an und instruiert eine skip_to-Intervention zum Ablehnungszweig.
Ergebnis: Das System bewältigt erfolgreich die „Long Tail“-Varianten seltener, kontextspezifischer Fälle (regulatorische Overrides), ohne das zugrunde liegende BPMN-Modell ändern zu müssen. Der DecisionAgent und der FlowAgent operieren unter separaten Richtlinien, was sicherstellt, dass die Routing-Logik und die regulatorische Override-Logik unabhängig voneinander auditierbar sind.

Die Ergebnisse bestätigen, dass der Process Harness die imperativen Anforderungen (erzwungen durch die Engine) mit den normativen Anforderungen (erzwungen durch Richtlinien-gerahmte Agenten) versöhnen kann, was eine „Open-World“-Anpassung bei gleichzeitiger Wahrung der strukturellen Integrität ermöglicht.

5. Bedeutung und Ansprüche

Das Paper behauptt, dass der Process Harness eine neue Form der Instrumentierung für Enterprise-KI-Systeme darstellt. Seine Bedeutung liegt in:

Versöhnung von Spannungsverhältnissen: Er löst den Trade-off zwischen struktureller Rigidität und offener Flexibilität, indem er die Prozess-Topologie (fest, durch die Engine erzwungen) von der Prozess-Adaption (dynamisch, durch Richtlinien gesteuert) trennt.
Inkrementelle Modernisierung: Organisationen können ihre bestehenden Workflow-Systeme inkrementell und reversibel in voll-agentische Systeme transformieren, ohne die zugrunde liegende Engine zu ersetzen.
Rechenschaftspflicht (Accountability): Im Gegensatz zu „LLM-as-Planner“-Ansätzen, bei denen Ausführungstraces nicht deterministisch oder nicht mit einem Modell verknüpft sein können, bietet CUGA FLO ein konkretes Substrat für die Rechenschaftspflicht. Jeder LLM-Aufruf ist mit einem Steuerungsdokument verknüpft, und jede Intervention wird im Prozess-Wissen gespeichert, das an spezifische Prozesselemente gebunden ist, was Auditierbarkeit und Diagnose von Non-Compliance ermöglicht.
Open-World-Adaption: Es verschiebt das Exception-Handling von einer Design-Zeit-Aktivität in einer Closed-World (Modellierung jedes möglichen Fehlerpfads) hin zu einer Laufzeit-Fähigkeit in einer Open-World, in der die Menge der handhabbaren Situationen durch die Reasoning-Kapazität der Richtliniendokumente definiert wird.

Die Autoren positionieren CUGA FLO als die erste Realisierung des „Agentic BPM Manifesto“ und bieten einen pragmatischen Rahmen für Organisationen, um sich von agenten-augmentiertem BPM zu vollem Agentic BPM zu entwickeln, bei dem Agenten den Prozess end-to-end steuern.