Warum BPMN nicht Agentensprache sein sollte – aber die beste Orchestrierung bleibt

Was passiert, wenn Maschinen nicht mehr nur isolierte Aufgaben erledigen, sondern ganze Prozesse untereinander abstimmen müssen? Genau hier setzen neue Agent-to-Agent-(A2A)-Protokolle wie MCP (Model Context Protocol) an. In modernen Multi-Agenten-Systemen kommunizieren KI-Module zunehmend direkt miteinander – häufig über JSON-Nachrichten oder spezialisierte Standards. Doch wo bleiben in dieser schönen neuen Agentenwelt unsere bewährten Prozesse und Modelle?

In diesem Beitrag schauen wir uns an, was BPMN überhaupt ist (keine Sorge, wir erklären es verständlich und kurz – inklusive Events, Tasks, Gateways und Swimlanes). Anschließend vergleichen wir BPMN mit typischen Agenten-Protokollen wie JSON oder dem neuen MCP-Standard. Wir zeigen, warum BPMN als „Agentensprache“ eher unflexibel ist (Spoiler: vordefiniert, wenig dynamisch, nicht gerade maschinenoptimiert, aber trotzdem seinen entscheidenden Wert behält – nämlich als Human-Machine-Interface. Dort, wo Menschen und KI-Agenten einen Prozess gemeinsam gestalten und nachvollziehen müssen, spielt BPMN seine Stärke als gemeinsame Sprache aus. Zum Schluss ordnen wir noch den Begriff BPMN Agent in diesen Kontext ein: als eine Art Orchestrator, der nicht die Agenten direkt miteinander plaudern lässt, sondern sie so steuert, dass ein klarer, für Menschen verständlicher Prozess entsteht. Und keine Sorge – ein bisschen Humor gibt’s auch, zum Beispiel in Form einer Vergleichstabelle, in der BPMN augenzwinkernd neben JSON, YAML, MCP & Co. steht.

Was ist BPMN? Eine kurze Übersicht

BPMN steht für Business Process Model and Notation – ein offener Standard, um Geschäftsprozesse grafisch darzustellen. Stellen Sie sich ein Flussdiagramm vor, das genau festgelegte Symbole verwendet, damit jeder es gleich versteht. BPMN wird von der Object Management Group (OMG) gepflegt und hat sich zum führenden Modellierungsstandard für Prozesse entwickelt. Aber was bedeuten die wichtigsten Elemente?

Events (Ereignisse): Sie markieren Start, Zwischenfälle oder Ende eines Prozesses. Zum Beispiel ein Start-Event (oft als grüner Kreis dargestellt) löst den Prozess aus, Intermediate-Events passieren mittendrin (z.B. ein Zeitereignis oder eine eingehende Nachricht), und End-Events beenden den Prozess. Man kann sich Events wie Auslöser vorstellen – etwas passiert, und der Prozess reagiert darauf.

Tasks bzw. Activities (Aktivitäten): Das sind die Aufgaben oder Aktivitäten im Prozess – dargestellt als abgerundete Rechtecke. Eine Task könnte z.B. „Rechnung prüfen“ oder „Daten verarbeiten“ sein. In BPMN unterscheiden wir verschiedene Task-Typen (manuelle Tasks, Service-Tasks, User-Tasks etc.), aber fürs Grundverständnis: Eine Task ist ein Schritt, in dem etwas erledigt wird.

Gateways (Entscheidungspunkte): Gateways steuern den Verlauf des Prozesses, indem sie Pfade verzweigen oder zusammenführen. Sie erscheinen als Rauten. Ein Exclusive Gateway (XOR, mit einem „X“ gekennzeichnet) steht für eine entweder-oder-Entscheidung – der Prozess nimmt einen von mehreren Pfaden. Ein Parallel Gateway (AND, mit Plus-Zeichen) bedeutet, dass mehrere Pfade gleichzeitig eingeschlagen werden. Gateways sind also wie Verkehrsknotenpunkte: Sie regeln, ob wir links, rechts oder in beide Richtungen gleichzeitig weiterfahren.

Swimlanes (Bahnen) & Pools: Diese sorgen für Übersicht, wer im Prozess was tut. Man zeichnet meist Pools (z.B. ganze Organisationen oder Systeme) und darin Lanes (Bahnen für einzelne Rollen, Abteilungen oder Teilnehmer). Jede Lane enthält die Tasks/Events, für die diese Rolle zuständig ist. So erkennt man auf einen Blick, welcher Beteiligte welche Schritte ausführt. Beispiel: Ein Pool „Online-Shop“ mit Lanes für „Kunde“, „Vertrieb“ und „Versand“ – man sieht sofort, welche Aufgaben beim Kunden liegen und welche intern passieren.

Zusammen ermöglichen diese BPMN-Elemente die grafische Modellierung von Prozessen, die für Menschen lesbar und verständlich sind. Eine BPMN-Diagramm dient oft als gemeinsame Sprache zwischen Fachexperten und IT: Alle sehen denselben Prozessablauf vor sich, ohne in Programmierdetails abzutauchen.

JSON, MCP & Co: Wie Agenten miteinander sprechen

In der Welt der KI-Agenten und modernen Automatisierung laufen viele Dinge nicht mehr nur in starren, vorab modellierten Bahnen ab. Stattdessen kommunizieren Software-Agenten dynamisch miteinander, tauschen Daten aus oder koordinieren Aktionen – oft ohne dass jeder Schritt von Menschen vorgegeben wurde. Dafür brauchen sie Sprachen oder Protokolle, die maschinengerecht und flexibel sind. Zwei Beispiele, die derzeit viel Aufmerksamkeit bekommen, sind JSON-basierte Agentenkommunikation und das neue Model Context Protocol (MCP).

JSON (JavaScript Object Notation) ist streng genommen kein Protokoll, sondern ein Datenformat. Es hat sich aber quasi zum Esperanto der IT-Systeme entwickelt – leichtgewichtig, von Menschen mit etwas Übung lesbar und vor allem von Maschinen einfach zu verarbeiten. In modernen Agenten-Frameworks „sprechen“ Agenten oft JSON miteinander, z.B. indem sie Nachrichten in Form von JSON-Objekten über HTTP austauschen. Denken Sie an eine Agenten-Nachricht wie:

{  "sender": "Agent A",  "receiver": "Agent B",  "intent": "query_data",  "payload": {"item_id": 12345} } 

Solche JSON-Nachrichten sind strukturiert und für Software einfach zu parsen. Im Gegensatz zu einem BPMN-Diagramm, das als ganzes Prozessmodell vorliegt, kann JSON ad-hoc Informationen und Befehle übertragen – ideal für Echtzeit-Kommunikation zwischen Agents. Google hat sogar ein offizielles A2A (Agent-to-Agent) Protokoll vorgestellt, das auf JSON aufbaut: Dabei agieren Agenten als Webservices, die über JSON-RPC 2.0 und HTTP(S) miteinander interagieren. Jedes Agenten-Service hat dort eine Art Visitenkarte (eine „Agent Card“) in JSON, die seine Fähigkeiten und Endpunkte beschreibt. Das zeigt: JSON ist quasi der Draht, über den Agenten heute Infos austauschen – einfach, standardisiert, webtauglich.

Neben JSON gibt es auch das allseits bekannte YAML (Yet Another Markup Language, oder rekursiv „YAML Ain’t Markup Language“). YAML wird oft für Konfigurationen genutzt und ist menschlich etwas besser lesbar als JSON (weniger { und }, dafür Einrückungen). In Agenten-Systemen spielt YAML weniger für Laufzeit-Kommunikation eine Rolle, aber taucht z.B. in Einstellungsdateien oder beim Definieren von Agenten-Verhalten auf. Man könnte sagen: YAML ist der gemütliche Cousin von JSON – lesbarer, aber manchmal zickig, wenn ein Einrückungs-Leerzeichen nicht passt (wer damit gearbeitet hat, weiß ein Lied davon zu singen).

Und dann haben wir MCP (Model Context Protocol), einen brandneuen Vorschlag von Anthropic, der viel Buzz erzeugt. Worum geht’s? MCP definiert eine standardisierte Schnittstelle, um strukturierte Kontext-Informationen in Echtzeit an KI-Modelle bereitzustellen. Man kann es sich wie einen einheitlichen „Zuliefer-Mechanismus“ vorstellen: Anstatt jeder AI-Anwendung individuell beizubringen, wie sie an Daten aus internen Systemen kommt, soll MCP als offener Standard dienen. Anthropic selbst beschreibt MCP als eine Art USB-C für KI – ein universeller Port, über den ein KI-Assistent alles Mögliche anstöpseln kann, von Datenbanken über Content-Repositories bis zu externen Tools.

Konkret bietet MCP ein Protokoll (meist über HTTPS und JSON) mit dem KI-Agents Kontextdaten abrufen oder Funktionen ausführen können. Zum Beispiel könnte ein Agent über MCP eine Kundendatenbank abfragen, eine Websuche durchführen oder ein Rechentool nutzen – alles auf standardisierte Weise, ohne für jedes Tool ein eigenes Integrationsverfahren zu bauen. Das Ziel: KI-Agenten bekommen zur Laufzeit genau die Infos, die sie brauchen, in strukturierter Form geliefert. Große Player wie OpenAI, AWS und IBM unterstützen MCP bereits, sodass es dabei ist, sich als neuer De-facto-Standard für Kontextdaten in Agentensystemen zu etablieren.

Zusammengefasst: Während BPMN ein vorgezeichneter Plan für Abläufe ist, ermöglichen Formate wie JSON (bzw. JSON-RPC im A2A-Kontext) und Protokolle wie MCP eine flexible, direkte Kommunikation zwischen Agents. Jeder Agent kann dem anderen schnell sagen „Tu X“ oder „Hier sind Daten Y“. Soweit, so gut – aber was bedeutet das nun für BPMN? Schauen wir uns an, wo BPMN im Vergleich glänzt oder auch mal alt aussieht.

Warum BPMN keine ideale Agentensprache ist

Angesichts dieser agilen Agenten-Kommunikation wirkt BPMN ein bisschen wie der Hofetikette-gewohnte Butler auf einer Tech-Party voller Discord-Chats. 😉 Als Sprache, in der Agenten miteinander frei reden, ist BPMN eher ungeeignet – und das hat mehrere Gründe:

Keine echte Ad-hoc-Serialisierung: Eine BPMN-Prozessdefinition liegt typischerweise als kompletter Diagramm-Entwurf (inklusive XML-Datei im Hintergrund) vor, nicht als leichtgewichtige Nachricht. Man kann nicht mal eben „einen BPMN-Prozess senden“, um damit einen Agenten etwas ad-hoc mitteilen zu lassen – zumindest nicht, ohne einen BPMN-Engine-Apparat dahinter. JSON-Nachrichten hingegen sind für genau sowas gemacht: ein JSON ist klein, portabel, an eine HTTP-Request heftbar, von jedem Microservice sofort interpretierbar. BPMN ist eher ein Bauplan, JSON das Chatfenster. Wenn zwei KI-Agenten sich in Echtzeit abstimmen wollen, würden sie kaum erst einen BPMN-Plan austauschen und einen Prozess-Designer bemühen.

Statische Struktur statt dynamischer Anpassung: BPMN-Modelle sind vordefiniert. Alle möglichen Flüsse, Entscheidungen und Tasks müssen vorab im Diagramm modelliert sein. Das macht sie vorhersehbar, aber eben auch unflexibel, wenn etwas Ungeplantes passiert. Multi-Agenten-Systeme hingegen leben von Dynamik: Agenten können neue Ziele formulieren, Rollen wechseln, spontan Unterhaltungen starten. In BPMN lässt sich während der Ausführung aber nicht mal eben ein neuer Pfad einziehen oder eine Task hinzufügen – die Struktur ist fix. Ein wissenschaftliches Paper brachte es auf den Punkt: „die Struktur von Agenten, die in BPMN repräsentiert sind, ist statisch; daher ist es schwierig, Änderungen der Struktur im Modell darzustellen, z.B. neue Aktivitäten hinzuzufügen, während das Modell läuft“. Kurz gesagt: BPMN kennt kein Improvisationstheater – das Skript steht fest.

Nicht maschinenoptimiert: BPMN ist von Menschen für Menschen (und BPMN-Engines) gemacht, nicht für schnelle Parser in Mikro-Agents. Die BPMN-Notation muss umfassend interpretiert werden; eine Engine muss das Diagramm einlesen, Instanzen verwalten, Token durch das Netz von Flows schicken usw. Das ist super für komplexe langfristige Workflows – aber ein Overhead, wenn zwei schlanke Agents einfach nur kurz Infos tauschen wollen. JSON dagegen ist maschinenlesbar im Wortsinn: Schlüssel-Wert-Paare, fertig. Kein Wunder also, dass Agenten sich lieber mit JSON zuprosten als mit BPMN-Schaubildern.

Heißt das nun, BPMN ist obsolet in Zeiten von Agenten und KI? Keineswegs! Es bedeutet nur, dass BPMN einen anderen Zweck erfüllt. Als direkte „Gesprächssprache“ zwischen vollautonomen Agenten mag BPMN ungeeignet sein – ähnlich wie ein Förmlicher Geschäftsbrief unpraktisch ist, um zwei selbstfahrende Autos über die Vorfahrt verhandeln zu lassen. Doch BPMN hat Stärken, wo spontane Agenten-Kommunikation an Grenzen stößt: vor allem dort, wo Menschen mit im Boot sind.

BPMN als Human-Machine-Interface: Prozesse zum Mitreden

Während JSON, MCP & Co. den Maschinen schnelle Absprachen ermöglichen, sorgt BPMN dafür, dass wir Menschen noch verstehen, was da passiert. Es fungiert als Mensch-Maschine-Schnittstelle – eine gemeinsame Bühne, auf der Mensch und Agent die Abläufe anschauen, diskutieren und gestalten können.

Stellen Sie sich ein Unternehmen vor, das einen Teil seiner Kundenbetreuung mit KI-Agenten automatisiert hat. Zwei Agenten könnten theoretisch vollautomatisch Kundenanfragen analysieren, untereinander aufteilen, verschiedene Datenquellen abklappern und dann eine Antwort formulieren – alles per A2A-Kommunikation. Technisch klasse, aber aus Management-Sicht ein Albtraum: Kein Prozessdiagramm, keine klare Kontrolle, kein Nachvollziehen, wer was warum getan hat. Spätestens wenn etwas schiefgeht („Warum erhielt Kunde X nie eine Antwort?“) möchte man doch wieder einen prozessualen Fahrplan sehen.

Hier glänzt BPMN als Orchestrierungsebene. Wir nutzen BPMN, um einen überschaubaren Workflow vorzugeben, in dem die KI-Agenten ihre Aufgaben verrichten. BPMN wird zur gemeinsamen Sprache, in der Fachanwender, Entwickler und die KI-Komponenten sich treffen. Der Mensch kann z.B. festlegen: „Nachdem Agent A dem Kunden ein Angebot geschickt hat, wartet der Prozess 24 Stunden. Wenn keine Antwort kommt, soll Agent B nachfassen.“ Das wird als BPMN modelliert – für alle verständlich – und dann von der Workflow-Engine strikt eingehalten.

Für den KI-Agenten ist das BPMN-Modell quasi eine Service-Vereinbarung: Er fügt sich in den vorgegebenen Ablauf ein. Für den Menschen ist es ein Transparenz-Tool: Man sieht, wann welcher Agent aktiv wird, wo vielleicht auch ein manueller Schritt eingebaut ist (z.B. ein menschliches Okay per User Task), und wie alles zusammenspielt. BPMN zwingt die Agenten, die Spielregeln offen zu legen.

Wichtig ist: BPMN ersetzt nicht die Intelligenz oder Flexibilität der Agenten – es rahmt sie ein. Innerhalb eines Tasks kann ein KI-Modul immer noch flexibel agieren (z.B. dank MCP die nötigen Infos ziehen, über JSON APIs mit Services reden usw.), aber der übergeordnete Ablauf bleibt kontrolliert. Das ist besonders relevant in Umgebungen mit Compliance- oder Audit-Anforderungen: Man will vielleicht genau definieren und prüfen können, welche Schritte ein automatisierter Prozess durchläuft. Ein selbstlernender Agent allein gibt solche Garantien nicht, ein BPMN-Prozessmodell schon eher.

BPMN Agent: Der Dirigent im Orchester der Agenten

Man hört in diesem Zusammenhang öfter den Begriff „BPMN Agent“. Was ist damit gemeint? Im Grunde kein einzelner Agent, der BPMN spricht, sondern ein Konzept: Ein System, das BPMN als Orchestrator in einer Agentenlandschaft einsetzt. Stellen wir uns ein Orchester vor: Die einzelnen Musiker sind unsere KI-Agenten – hoch spezialisiert, virtuos auf ihren Instrumenten (Textanalyse, Websuche, Datenbankabfrage, etc.). Wenn jeder nur für sich spielt, haben wir viel Lärm und wenig Musik. BPMN übernimmt die Rolle des Dirigenten, der dafür sorgt, dass alle zur rechten Zeit im richtigen Takt einsetzen.

Ein BPMN Agent System steuert also die Abfolge der Agenten-Aktionen gemäß einem Prozessmodell. Es lässt die Agenten nicht einfach direkt durcheinander reden, sondern leitet ihre Kommunikation gezielt über Prozessschritte. Zum Beispiel: Agent A extrahiert Infos → dann übergibt BPMN an Agent B zur Auswertung → dann Entscheidungsgateway: Wenn Ergebnis positiv, lässt BPMN Agent C weitermachen, sonst Agent D, etc. Die Agenten selbst müssen gar nicht „wissen“, wie der ganze Ablauf aussieht – sie konzentrieren sich auf ihre jeweilige Aufgabe. Die BPMN-Engine (also der BPMN Agent) kümmert sich um das Big Picture.

Der Charme dieses Ansatzes: Menschen können an diesem Big Picture mitzeichnen. BPMN dient als Blaupause, die sowohl von Menschen verstanden als auch von Maschinen (der Engine und den Agents) ausgeführt wird. Man könnte sagen, BPMN baut die Brücke zwischen deterministischer Prozesswelt und probabilistischer KI-Welt.

Natürlich hat auch dieser Ansatz seine Herausforderung: Man muss die richtige Balance finden zwischen starrem Modell und dynamischem Agentenverhalten. Zu viel BPMN-Orchestrierung, und die Agenten verlieren ihre Flexibilität. Zu wenig, und der Mensch verliert die Kontrolle. Hier kommen agile Ansätze ins Spiel: Prozesse modular gestalten, Agenten mit gewissen Freiheitsgraden in Tasks ausstatten, Ausnahmen handhaben etc. Doch das Grundprinzip steht: Ein BPMN Agent-System gibt den Takt vor, in dem die KI-Komponenten miteinander agieren.

Übrigens: Das Konzept ähnelt dem bekannten Unterschied von Orchestration vs. Choreography in der Prozesswelt. Bei einer Choreographie würden alle Beteiligten selbstorganisiert interagieren (wie Agenten in freier Wildbahn). Bei der Orchestration gibt es einen zentralen Ablauf (den Dirigenten). BPMN ist von Natur aus auf Orchestration ausgelegt – was in vielen Business-Kontexten auch gewünscht ist, um eben nicht alles dem Selbstlauf zu überlassen.

BPMN vs. JSON vs. YAML vs. MCP – ein humorvoller Vergleich

Abschließend lockern wir das Thema mit einem kleinen Augenzwinkern auf. Was wäre, wenn BPMN, JSON, YAML und MCP auf einer Party wären? Wer würde sich wie benehmen? Eine Vergleichstabelle der etwas anderen Art:

BPMN

Der Prozess-Dompteur im Anzug. Mag es formal und ordentlich: Jeder Schritt an seinem Platz, nichts Ungeplantes. Redet in Diagrammen – wunderbar verständlich für alle im Meeting, aber auf der Party etwas steif. Holt aber am Ende alle zum gemeinsamen Walzer auf die Tanzfläche (sprich: sorgt für den geordneten Ablauf).

JSON

Der Pragmatiker und Informatiker der Runde. Spricht in klaren Strukturen, kurz und präzise (geschweifte Klammern sind seine Satzzeichen). Für Menschen okay zu lesen, für Computer perfekt. Er ist der Typ, der auf der Party in 140 Zeichen das Wichtigste sagt. Smalltalk in JSON? „{„party“: „great“}“ – reicht doch!

YAML

Die lockere Cousine von JSON, kommt casual im Hoodie. Tut so, als wäre sie natürlicher in der Sprache (keine Klammern!), aber ist insgeheim zickig: Ein falsch gesetztes Leerzeichen, und sie ist beleidigt. Sie erzählt gerne ausführlich (Multiline), was ihr durch den Kopf geht. Entwickler mögen sie – bis sie mal wieder ein Einrückungs-Drama verursacht.

MCP

Der Newcomer mit futuristischer Brille. Bringt Ordnung ins Chaos der KI-Gespräche: „Leute, wir brauchen Standard-Schnittstellen!“ Sammelt Datenquellen und Tools an der Bar und verbindet sie geschickt mit den KI-Modellen auf der Tanzfläche. MCP spricht JSON-Dialekt, aber mit strengen Benimmregeln (Standardisierung ist alles). Der Visionär, der USB-C unter den Protokollen – universell einsetzbar und alle sagen: „Warum hatten wir dich nicht schon früher!“

Fazit

BPMN und moderne Agentenprotokolle stehen nicht im Widerspruch – sie ergänzen sich. Während JSON, MCP & Co. die Maschinenwelt effizient vernetzen und unseren KI-Agenten die Freiheit geben, dynamisch zu agieren, sorgt BPMN dafür, dass darüber ein Masterplan existiert, den auch wir Menschen verstehen und steuern können. BPMN mag als direkte Agenten-Kommunikationssprache unflexibel sein, doch genau diese Verlässlichkeit und Klarheit macht es zum perfekten Human-Machine-Interface in komplexen Automatisierungsvorhaben.

Für IT-Leiter:innen, Prozessautomatisierer:innen und Entwickelnde, die mit Multi-Agenten-Architekturen arbeiten, heißt das: Nutzt die Stärken beider Welten! Setzt BPMN dort ein, wo Nachvollziehbarkeit, Abstimmung mit Fachexperten und Orchestrierung gefragt sind. Und setzt Agentenprotokolle dort ein, wo Adaptive Intelligenz, Kontextintegration und maschinelle Effizienz zählen. Ein BPMN Agent-basierter Ansatz kann helfen, diese Welten zu verbinden – der Dirigent, der das Konzert der AI-Agenten spielbar für alle macht.

Die Zukunft gehört wahrscheinlich hybriden Lösungen: Strukturierte Prozesse mit eingebetteten intelligenten Agenten. A2A-Protokolle wie MCP sind ein wichtiges Puzzleteil dieser Zukunft – sie machen die KI anschlussfähig, während BPMN ihr einen sinnvollen Handlungsrahmen gibt. In diesem Sinne: Auf eine erfolgreiche Zusammenarbeit von Diagramm und Datenstrom, von BPMN und AI-Agent – zum Wohle sowohl der Maschinen als auch ihrer menschlichen Kollegen!