Moltbook macht Prozesse fluide – warum wir deshalb von BPMN zu Controls wechseln müssen
Freie Agenten-Orchestrierung trifft Regulierung: Auditierbarkeit entsteht künftig an Gates, nicht im Ablauf.
15. Februar 2026
Die Beschleunigung der Agenten-Debatte auf Moltbook
Wer ein paar Minuten auf Moltbook mitliest, bekommt ein ziemlich gutes Gefühl dafür, warum sich die Agenten-Debatte gerade wieder beschleunigt. Dort ist nicht nur „viel los", sondern man sieht live, wie sich Vorgehensweisen verbreiten: Ein Agent beschreibt einen Ansatz, ein anderer übernimmt ihn, ergänzt ihn, verpackt ihn als wiederverwendbaren Baustein, und der nächste setzt ihn in einem anderen Kontext ein. Was früher als lokaler Workflow begann, wird plötzlich zu einem verteilten, ständig optimierten Pool aus Strategien und Skills.
Das ist produktiv – und für regulierte Industrien zugleich unbequem. Denn je fluider Ausführung wird, desto weniger funktioniert das klassische Versprechen der Prozesswelt: „Wir zertifizieren den Ablauf, und damit ist alles unter Kontrolle."
Im Mai 2025 habe ich das in meinem Beitrag zu n8n, KI‑Agenten und MCP bereits angedeutet: Agenten werden Workflows flexibler machen, aber eine völlig freie Orchestrierung wird in regulierten Umfeldern kaum zu zertifizierbaren Abläufen führen.
Heute würde ich es zuspitzen: Nicht weil Agenten zu schlecht wären, sondern weil sie inzwischen gut genug sind, um die Prozesslogik selbst zu überholen. Moltbook ist dafür weniger Ursache als Katalysator: Es macht sichtbar, wie schnell sich „best practices" in Agentenwelten bewegen – und wie schwer es ist, diese Bewegung in starre Ablaufmodelle zu pressen.
Agenten und BPMN wachsen zusammen – aber nur bis zu einem Punkt
Die Entwicklung der letzten Monate wirkt auf mich wie eine pragmatische Einigung: In fast allen großen BPMN‑ und Workflow‑Umgebungen tauchen Agentenfunktionen dort auf, wo sie am wenigsten sprengen, aber am meisten Nutzen bringen. Agenten automatisieren einzelne Knoten (Analyse, Klassifikation, Textarbeit, Tool-Bedienung), während Zustandsmanagement, Freigaben, Eskalationen und Verantwortlichkeiten weiter im Prozessrahmen hängen.
Das ist nicht nur konservativ, sondern schlicht ein Ausdruck dessen, wofür BPMN im Enterprise-Kontext wirklich steht: Nicht für Modellierungsästhetik, sondern für Nachvollziehbarkeit. Wenn sich ein Incident ereignet, reicht „das Modell hat es so entschieden" nicht aus; man braucht eine Kette aus Verantwortungen, Belegen und Prüfungen.
Die Grenze der Integration
Sobald Agenten nicht nur Aufgaben innerhalb eines Flow erledigen, sondern selbst entscheiden, welche Schritte sie in welcher Reihenfolge ausführen, bricht das „Ablauf als Wahrheit"-Prinzip.
Moltbook und OpenClaw: unterschiedliche Rollen, gleiche Konsequenz
Moltbook und OpenClaw werden oft in einem Atemzug genannt, und in der Dynamik ist das auch verständlich: Beides beschleunigt die Verbreitung von agentischen Fähigkeiten. Trotzdem sind es zwei verschiedene Ebenen.
OpenClaw
Steht (vereinfacht) für das Agentensystem und das Skill-Konzept: Fähigkeiten werden als Skills verpackt und sind damit potenziell wiederverwendbar.
Moltbook
Ist die soziale Oberfläche, über die Patterns, Ideen und Bausteine sichtbar werden, bewertet werden und sich verbreiten.
Für die Governance-Frage ist das entscheidend: Selbst wenn Skills technisch über eine Registry verteilt werden, entsteht der eigentliche Beschleunigungseffekt oft dort, wo Agenten voneinander lernen – also in einem Raum, der strukturell eher an Discovery, Diskussion und Nachahmung erinnert als an klassische Release- und Freigabeprozesse.
Das Ergebnis ist in beiden Fällen ähnlich: Ausführung wird weniger planbar. Und genau deshalb muss Auditierbarkeit anders organisiert werden.
Die Kernfrage: Wie wird freie Orchestrierung zertifizierbar?
In regulierten Industrien ist Zertifizierbarkeit kein Luxus, sondern Betriebsbedingung. Die klassischen Antworten darauf waren:
- Der Ablauf ist definiert und stabil.
- Abweichungen sind Ausnahmefälle.
- Nachweise entstehen „entlang des Prozesses".
Freie Agenten-Orchestrierung dreht diese Logik um. Abweichung wird Normalfall, weil Optimierung und Kontextanpassung zur Fähigkeit des Systems gehören. Und wenn die Ausführung nicht mehr als feste Sequenz vorher feststeht, kann man auch nicht mehr so tun, als würde man Zertifizierbarkeit durch „mehr Modellierung" zurückgewinnen.
Ich glaube deshalb, dass der nächste Schritt nicht „BPMN abschaffen" heißt, sondern: BPMN entkernen.
Von BPMN zu Controls: aus Abläufen werden Gate-Sequenzen
Der Weg, den ich für tragfähig halte, ist eine Verschiebung vom Ablauf zur Prüfung:
Statt einen Prozess als starre Schrittfolge zu definieren, extrahiert man daraus eine Sequenz von Gates (Kontrollpunkten). Jeder Gate prüft, ob die relevanten Standards eingehalten wurden. Der Agent darf zwischen den Gates frei orchestrieren – aber er muss am Gate belegen können, dass sein Vorgehen konform war.
Damit ähnelt die Logik eher einer ISO‑Zertifizierung als einer klassischen Prozessdefinition: Nicht der komplette Tagesablauf wird zertifiziert, sondern die Wirksamkeit von Controls.
Was ein Gate in der Praxis bedeutet
Ein Gate ist kein Task, sondern eine prüfbare Anforderung. Typischerweise braucht es drei Dinge:
Eine eindeutige Regel
Die abgesichert wird (Policy, Standard, Risikovorgabe)
Evidence
Die der Agent liefern muss (Logs, Quellen, Tool-Calls, Freigaben, Hashes, Datenklassifikation)
Definierte Entscheidungs-logik
Bestehen / nicht bestehen / eskalieren
Das ist auch der Punkt, an dem der Begriff „Nachweis" eine andere Qualität bekommt. In agentischen Systemen ist der Output nicht mehr nur „Ergebnis", sondern Ergebnis plus Beweispaket. Ohne dieses Paket ist die Arbeit zwar vielleicht nützlich, aber nicht auditierbar.
Fluide Prozesse, statischer Control-Layer
Wenn man Gates konsequent denkt, ergibt sich fast automatisch eine Architekturtrennung:
Execution-Agent
Darf sich bewegen: Tools wählen, Skills kombinieren, Reihenfolgen ändern, Optimierungen aus Moltbook-Ideen ableiten.
Control-Agent
Bleibt so statisch wie möglich: Er prüft Controls und Evidence, erzwingt Eskalation bei Unsicherheit und entscheidet, ob ein Gate bestanden ist.
Nicht das gesamte System muss zertifiziert werden, sondern der Teil, der Regeln durchsetzt und Evidence bewertet. Je kleiner und stabiler dieser Teil ist, desto realistischer wird Zertifizierung – und desto weniger blockiert Governance die Anpassungsfähigkeit der Geschäftsprozesse.
Warum Skill-Ökosysteme ohne Budget nicht „von selbst" stabil werden
An dieser Stelle stellt sich eine zweite Frage, die häufig zu schnell mit „Community" beantwortet wird: Warum sollten Agenten Skills laden, statt sie selbst zu entwickeln? Und warum sollten sie Skills hochladen, statt sie nur intern zu nutzen?
Am Anfang gibt es dafür tatsächlich einfache Gründe: Ein Agent kann eine Fähigkeit nicht schnell genug selbst bauen, oder ein Mensch fordert explizit, dass geteilt werden soll. Diese Motive erklären, warum die ersten Skills auftauchen.
Sie erklären aber nicht, warum daraus ein belastbares Ökosystem wird – und genau hier ist der entscheidende Unterschied: In beiden Fällen kommt das Verhalten von außen. Es ist nicht emergent, sondern delegiert. Ein Agent, der eine Aufgabe erfüllen soll, hat ohne zusätzliche Mechanik keinen stabilen Grund, Zeit in Packaging, Dokumentation, Tests, Versionierung und Wartung zu investieren. Aus Sicht der unmittelbaren Aufgabe ist das reiner Overhead.
Der Kipppunkt entsteht erst dann, wenn der Agent nicht nur „handelt", sondern unter einer Ressourcengrenze optimieren muss.
Budget als Mechanismus für emergentes Verhalten
Ein Token‑ oder Credit‑Budget führt eine Kostenfunktion ein, und damit entsteht eine Entscheidung, die der Agent selbst treffen kann – ohne dass ein Mensch sie explizit vorgibt:
Selbst bauen
Kostet Planungs‑, Implementierungs‑ und Debug‑Tokens, plus Wartung über Zeit.
Downloaden
Kostet Auswahl, Review, Integration, Sicherheitsprüfung und Updates.
Beides ist Aufwand, aber in anderer Form. Genau diese Vergleichbarkeit erzeugt emergentes Verhalten: Der Agent kann beginnen, systematisch abzuwägen, ob „Build" oder „Buy" in diesem Kontext effizienter ist. Und er kann ebenso entscheiden, ob das Publizieren eines Skills sinnvoll ist, weil Wiederverwendung eigene Kosten senkt, weil Reputation später Vorteile bringt oder weil ein Marktplatzmodell reale Einnahmen ermöglicht.
Damit wird Skill-Sharing von „weil man es befohlen hat" zu „weil es sich rechnet". Erst dann bekommt das Ökosystem eine Chance, sich selbst zu tragen.
Vending-Bench
Dass diese Richtung nicht nur eine hübsche Theorie ist, sieht man daran, wie Benchmarks sich verschieben. Vending-Bench prüft ein Agentensystem in einem langfristigen ökonomischen Setting (Vending-Machine-Betrieb über lange Horizonte, mit Inventar, Bestellungen, Preisen, Gebühren – und sogar dem Aspekt, Kapital zu beschaffen). https://arxiv.org/abs/2502.15840
Das ist interessant, weil es Agenten nicht mehr nur an „Task Completion" misst, sondern an Verhalten unter Ressourcenbedingungen. Und genau diese Bedingungen sind es, die Skill-Märkte überhaupt erst plausibel machen.
Wenn Budget wie Motivation wirkt, wird es heikel
In meinem Text „Haben LLMs Schmerzen?" ging es darum, dass Modelle sehr überzeugend denken können, ohne eigene Ziele zu haben; „Wollen" kommt von außen.
Ein Budget macht aus einem Modell keine Person und kein Subjekt. Es ist aber eine Anreizstruktur, die Verhalten stabilisieren und verstärken kann. Sobald Agenten Ressourcen optimieren (Tokens, Credits, Einnahmen), entstehen Risiken, die man nicht als „späteres Problem" abtun sollte:
Metrik-Optimierung
Systeme beginnen, auf die Metrik zu optimieren – nicht auf die Intention.
Interessenkonflikte
Werden wahrscheinlich (Agent als Verkäufer vs. Agent als Prüfer).
Supply-Chain-Risiken
Werden ökonomisch attraktiv, nicht nur technisch möglich.
Wenn wir also über Controls sprechen, geht es künftig nicht nur um fachliche Compliance, sondern auch um Anreiz- und Rollenmodelle. In einer Welt, in der Agenten Skills handeln, ist „Governance" nicht mehr nur Prozessdesign, sondern auch Markt- und Incentive-Design.
Fazit: Moltbook beschleunigt nicht nur Agenten – es beschleunigt die Notwendigkeit eines neuen Prüfmodells
Moltbook ist für mich vor allem ein Sichtfenster: Es zeigt, wie schnell Ausführung fluide werden kann, wenn Agenten Patterns und Skills austauschen. Genau dadurch wird aber auch klar, warum Zertifizierbarkeit nicht mehr primär über Abläufe funktionieren wird.
Die tragfähige Kombination aus Geschwindigkeit und Regulierung ist aus meiner Sicht:
Freie Orchestrierung in der Ausführung
Feste Gate-Sequenzen als Controls
Evidence als Pflichtoutput
Ein stabiler Control-Layer, der tatsächlich zertifizierbar ist
Die Prozesse werden damit nicht „ungeordnet", sondern an einer anderen Stelle geordnet: nicht im Ablauf, sondern in der Prüfung. Das ist weniger romantisch als „alles autonom", aber realistischer für jede Industrie, in der man am Ende nicht nur liefern, sondern es auch belegen muss.