Aus BPMN entstehen Agenten — wenn das Prozessmodell Rechte, Skills und Rollen bestimmt

Die spannendste Frage bei KI-Agenten im Unternehmen ist selten „welches Modell?”, sondern „was darf der Agent, was kann er, und wofür ist er zuständig?”. Genau darauf gibt es in der ProcessCube® Platform eine ungewöhnlich klare Antwort: Das steht schon in deinem Prozessmodell. Aus einem BPMN-Diagramm entstehen OpenClaw-Agenten — und die fachlichen Anforderungen im Modell (Lanes, Aufgaben, Datenflüsse) bestimmen ihre Rollen, Skills und Rechte.

Warum das gerade jetzt relevant ist

Agentische KI ist 2026 aus der Kür in die Pflicht gerutscht. Gartner erwartet, dass bis 2028 ein Drittel der Enterprise-Software agentische KI enthält (2024: unter 1 %) und 15 % der alltäglichen Arbeitsentscheidungen autonom getroffen werden — bei quasi 0 % im Jahr 2024 (Gartner ). McKinsey berichtet, dass 88 % der Organisationen KI in mindestens einem Bereich einsetzen und Vorreiter vor allem eines tun: sie gestalten ihre Workflows grundlegend neu, statt KI nur oben aufzusetzen (McKinsey, The State of AI).

Die ernüchternde Kehrseite: Gartner rechnet damit, dass über 40 % der agentischen KI-Projekte bis Ende 2027 scheitern — an Kosten, unklarem Nutzen und unzureichenden Kontrollen (Gartner ). Anders gesagt: Wer Agenten ohne klare Zuständigkeiten, Rechte und Nachvollziehbarkeit ins Unternehmen lässt, produziert Wildwuchs. Wer sie an definierten Prozessen entlangführt, bekommt Kontrolle.

Die Idee: Das Prozessmodell ist der Bauplan

In BPMN ist längst modelliert, wer was macht: Lanes stehen für Rollen und Verantwortlichkeiten, Tasks für konkrete Arbeitsschritte, Daten-Objekte für das, was fließt. Die Agent Runtime nimmt genau diese Struktur und leitet daraus Agenten ab — ein Agent pro Lane, zugeschnitten auf die Aufgaben seiner Lane.

Das Prozessmodell bestimmt dabei drei Dinge auf einmal:

• Zuständigkeit — welche Task-Topics ein Agent bedient (die Engine ruft ihn als ExternalTask-Worker genau dort auf, wo er zuständig ist).
• Skills — welche Werkzeuge er aus dem Tool-Inventar braucht, um seine Aufgaben zu erledigen.
• Rechte — mit welchen Scopes er unterwegs ist. Nicht mehr, als die Aufgabe verlangt.

Damit ist die Regel umgedreht: Nicht der Agent sucht sich Aufgaben und Rechte, sondern die fachliche Anforderung — das Modell — teilt sie ihm zu.

Konkret: pc-runtime builder create <bpmn>

Der Generator steckt als Single-Binary in der Agent Runtime. Aus einem BPMN-Diagramm wird in wenigen Schritten ein Satz Lane-Agenten:

pc-runtime builder analyze prozess.bpmn

pc-runtime builder create prozess.bpmn

pc-runtime agents update|reinstall|show prozess.bpmn

Agenten als digitale Mitarbeiter

Wenn ein Agent eine Lane bekommt, wird er faktisch zum Rolleninhaber in einem Prozess — mit klarer Zuständigkeit und begrenzten Rechten. Das ist genau die Sprache, in der große Anbieter gerade den Markt beschreiben: eine „digitale Belegschaft”, in der Menschen und Agenten am selben Ergebnis arbeiten (McKinsey ). Für die Platform heißt das ganz konkret:

• Agenten übernehmen Aufgaben. Ein ServiceTask, der bisher ein Skript oder ein manueller Schritt war, wird an einen zuständigen Agenten delegiert — als ExternalTask, sauber im Prozess verankert.
• Agenten bekommen eigene Rollen. Über die Lane sind Zuständigkeit und Scope definiert. Ein „Prüf”-Agent prüft — er deployt nichts.
• Agenten wickeln UserTasks ab. Wo heute ein Mensch eine Aufgabe aus der Inbox nimmt, kann künftig ein digitaler Mitarbeiter denselben UserTask bearbeiten — mit Human-in-the-Loop für die Schritte, die Freigabe brauchen.
• Agenten nehmen die nervigen Aufgaben. Bei uns im Ticketpilot analysieren Agenten eingehende Bugs, schlagen Fehlerursachen und Umsetzungen für Bugs und Features vor — die repetitive Vorarbeit, die sonst Zeit frisst. (Wie ein spezialisierter Agent — der coding-agent — sogar Pull Requests anlegt, zeigt der Beitrag OpenClaw-Agenten aus LowCode.)

Warum das ein Plädoyer für gute Prozessmodelle ist

Hier schließt sich der Kreis. Ein Agent ist nur so gut wie die Zuständigkeit, die man ihm gibt. Und die kommt aus dem Modell. Damit wird ein sauber und ausführlich dokumentierter BPMN-Prozess vom „nice to have” zur Voraussetzung für sinnvolle Automatisierung:

• Klare Lanes → klare Agenten-Rollen.
• Klare Tasks → klare Zuständigkeiten und Skills.
• Klare Datenflüsse → klare, minimale Rechte.

Das deckt sich mit dem Konsens in der BPM-Welt: BPMN entwickelt sich zur Governance-Schicht für autonome Agenten. „Orchestrierung ist das, was dir erlaubt, KI echte Autorität über deine Abläufe zu geben” — mit deterministischen Leitplanken, versionierter Ausführungshistorie und strukturell eingebautem menschlichem Eingriff, formuliert es Camunda  (siehe auch diginomica: BPMN is getting an agentic AI refresh). Der Prozess macht jede Aktion nachvollziehbar — wer hat wann was und warum getan — und verhindert, dass Automatisierung zur Blackbox wird.

Das ist zugleich die Antwort auf das Sicherheitsthema. Die OWASP-Leitlinien für Agenten-Sicherheit  nennen Tool-Missbrauch und Rechte-Eskalation unter den größten Risiken und empfehlen das Prinzip least privilege: Ein Agent soll nur die Werkzeuge und Rechte für seine Aufgabe haben — zeitlich und im Umfang begrenzt. Genau das fällt hier als Nebenprodukt ab: Weil die Lane den Scope bestimmt, bekommt jeder Agent per Konstruktion nur, was seine Rolle braucht.

Der Beitrag zur digitalen Transformation

„KI einführen” scheitert selten an Modellen und fast immer an der Frage, wo genau KI andocken soll — verantwortlich, kontrolliert, nachvollziehbar. Prozessbewusstsein wird damit zum eigentlichen Hebel: Wer seine Abläufe kennt (oder sie im Zuge dessen bewusst modelliert), kann Agenten gezielt an den richtigen Stellen einsetzen, statt einen Chatbot über alles zu stülpen. Die Vorreiter aus der McKinsey-Erhebung machen genau das — sie redesignen Workflows, statt KI danebenzustellen.

Aus BPMN entstehende Agenten sind damit kein Selbstzweck, sondern ein Vehikel der digitalen Transformation: Das Prozessmodell wird zum gemeinsamen Vertrag zwischen Fachbereich (was soll passieren?), IT (was darf passieren?) und KI (wer macht es?).

Was als Nächstes kommt

Zwei Bausteine machen aus dem Bauplan echte, sorgenfreie Helfer:

• Wissen im Kontext der Prozesse. Mit dem Knowledge-SDK bekommen Agenten Zugriff auf das Unternehmenswissen — und zwar nicht als loser Dokumentenberg, sondern entlang der Prozesse, an denen sie arbeiten. Das ist genau der Ansatz, mit dem RAG/Grounding die Verlässlichkeit hebt: Antworten werden in verifiziertem, kuratiertem Wissen verankert statt frei halluziniert — mit belegbarer Herkunft für Compliance (Grounding & RAG ).
• Helfer ohne Sorgen und Sicherheitsrisiken. Least-privilege-Scopes aus der Lane, Human-in-the-Loop an den kritischen Stellen, ein vollständiger Audit-Trail im Prozess — die Bausteine, die aus einem „autonomen Agenten” einen verantwortbaren digitalen Mitarbeiter machen. Genau die Kontrollen, deren Fehlen laut Gartner die meisten Agenten-Projekte scheitern lässt.

Kurz: Erst der Prozess, dann der Agent — und dann das Wissen, im Kontext genau dieses Prozesses. Wir zeigen die nächsten Schritte hier im Blog. Stay tuned.

Weiterführend

• Agent Runtime — BPMN-zu-OpenClaw-Generator — die CLI pc-runtime builder
• Agent Runtime in 15 Minuten — Runtime aufsetzen und Agent main ansprechen
• OpenClaw-Agenten aus LowCode — spezialisierte Agenten (u. a. coding-agent) aus Flows auslösen
• Knowledge-SDK — Unternehmenswissen als Hybrid-Suche für Agenten
• Camunda: Why BPMN (Still) Matters in the Age of AI — BPMN als Governance-Schicht
• OWASP: AI Agent Security Cheat Sheet — least privilege, Tool-Kontrolle, Human-Oversight
• Gartner-Prognosen zu agentischer KI  & McKinsey: The State of AI