OpenClaw: Vom Workflow zum digitalen Mitarbeiter

Die ganze Welt dreht gerade durch wegen OpenClaw. Verständlich — und gleichzeitig lohnt es sich, kurz innezuhalten und zu verstehen, was hier eigentlich passiert.

Denn im Kern ist OpenClaw erstaunlich unspektakulär: Ein LLM-Wrapper mit Root-Zugriff auf ein Betriebssystem.

Das war's.

Kein magisches Framework, keine proprietäre Geheimtechnologie. Ein Sprachmodell, das Befehle auf einem Linux-System ausführen kann. Dateien lesen, Software installieren, im Internet recherchieren, Skripte schreiben und ausführen.

Und genau das macht es so interessant — und so gefährlich.

Die Einstiegshürde? Überraschend niedrig.

Wer einen Server aufsetzen kann (oder jemanden kennt, der das kann), hat OpenClaw in unter einer Stunde laufen. Docker-Container starten, API-Key eintragen, fertig.

Keine wochenlangen Integrationen. Kein Enterprise-Vertriebsgespräch. Kein "kontaktieren Sie uns für ein individuelles Angebot".

Das klingt nach einem Vorteil. Ist es auch. Aber es bedeutet eben auch, dass jeder, der will, einem Sprachmodell Root-Zugriff auf ein System geben kann. Dazu gleich mehr.

Drei Stufen der Automatisierung

Um zu verstehen, warum OpenClaw anders ist, hilft ein Blick auf die Evolution der letzten Jahre. Ich unterteile sie in drei Stufen — und ja, ich habe alle drei selbst durchlaufen.

Stufe 1: Deterministische Workflows

Das ist das, was die meisten kennen: n8n, Zapier, Make. Wer Kummer und Schmerzen gewohnt ist, auch Power Automate.

Du definierst jeden Schritt. Jede Verzweigung. Jede Bedingung. Trigger → Aktion → Output. Für jeden Edge Case ein neuer Zweig.

→ Vorteil: Absolut vorhersagbar. Du weißt genau, was passiert. → Nachteil: Absolut starr. Ändert sich ein API-Feld, bricht alles zusammen.

In der Praxis heißt das: Du baust 50 Workflows und machst trotzdem die Hälfte manuell, weil "der Edge Case nicht abgedeckt ist." Kennt jeder. Sagt keiner laut.

Stufe 2: Agenten-Workflows

Auch das lässt sich gut auf n8n oder ähnlichen Plattformen abbilden. Zentral sitzt ein Sprachmodell, dem du eine Handvoll vordefinierter Tools gibst.

Je nach Aufgabe entscheidet die KI: Wird Tool X eingesetzt? Wie oft? Vor oder nach Tool Y? Oder wird Y gar nicht gebraucht?

→ Vorteil: Deutlich flexibler. Die KI kann mit variablen Inputs umgehen. → Nachteil: Immer noch ein Sandkasten. Wenn eine Aufgabe ein bestimmtes Werkzeug erfordert, das nicht verfügbar ist — Pech gehabt. Kein Ausweg.

Das ist die Stufe, die 2025 auf LinkedIn als Allheilmittel vertickt wurde. Und ja, es ist ein Fortschritt. Aber die KI bleibt ein Angestellter, der nur die Werkzeuge benutzen darf, die du ihm in die Hand drückst.

Stufe 3: Autonome Agenten mit Systemzugriff

Hier kommt OpenClaw ins Spiel.

Auch hier sitzt ein Sprachmodell in der Mitte. Der Unterschied: Es hat vollen Zugriff auf das Betriebssystem.

Wenn ein Werkzeug fehlt? Recherchieren, herunterladen, installieren, einrichten. Wenn kein bekanntes Tool hilft? Eigenes Skript schreiben. Workaround entwerfen. Lösung bauen.

Dazu kommt persistenter Speicher über Wochen. Der Agent erinnert sich an deinen Kontext, deine Vorlieben, deine Projekte.

→ Nicht mehr "Tool-User", sondern "Tool-Maker".

Der Shift ist fundamental:

Stufe 1 und 2 fragen: "Welches meiner Tools soll ich nutzen?" Stufe 3 fragt: "Was brauche ich — und wenn es nicht existiert, wie baue ich es?"

Klingt großartig. Ist es auch. Und jetzt die Schattenseite.

Root-Zugriff auf ein Betriebssystem ist kein Spielzeug.

Ein Sprachmodell, das rm -rf / ausführen kann, wird das irgendwann tun — nicht aus Bosheit, sondern weil es den Kontext falsch interpretiert hat. Oder weil jemand einen cleveren Prompt geschrieben hat. Oder weil Dienstagmorgen ist und LLMs manchmal einfach Unsinn machen.

Das ist keine Panikmache. Das ist Realität.

Wer OpenClaw produktiv einsetzt, braucht:

→ Klare Grenzen. Was darf der Agent, was nicht? Und wer kontrolliert das? → Isolierte Umgebungen. Root-Zugriff auf einen dedizierten Container ist etwas anderes als Root-Zugriff auf den Produktivserver. → Monitoring. Was tut der Agent gerade? Welche Befehle hat er ausgeführt? Welche Pakete installiert? → Gesunden Menschenverstand. Nicht alles, was technisch möglich ist, ist auch eine gute Idee.

IBM nennt es treffend: "A loose, open-source layer that can be incredibly powerful with full system access." Powerful. Nicht safe. Nicht controlled. Powerful.

Die eigentliche Frage

Die Diskussion um OpenClaw wird gerade dominiert von "Was kann es alles?" — und das ist verständlich. Es kann eine Menge.

Aber die spannendere Frage ist eine andere:

Wir bewegen uns von deterministischen Systemen, die tun was man ihnen sagt, zu autonomen Systemen, die tun was sie für richtig halten. Und wir geben ihnen dafür Zugriff auf echte Infrastruktur.

Das ist nicht einfach die nächste Iteration von Automatisierung. Das ist ein Paradigmenwechsel.

Und wie bei jedem Paradigmenwechsel entscheidet nicht die Technologie über Erfolg oder Scheitern — sondern wie wir damit umgehen.

Also: Baust du noch Workflows, oder hast du schon einen Mitarbeiter? Und wenn ja — vertraust du ihm?