Du schreibst deinem Assistenten bei WhatsApp: „Schau mal nach, ob die Rechnung schon da ist.“ Wenige Sekunden später hat ein Agent auf deinem eigenen Rechner die Nachricht empfangen, den passenden Kontext geladen, ein Sprachmodell befragt, einen Skill aktiviert und dir die Antwort zurückgeschickt.
Genau das ist OpenClaw.
OpenClaw ist kein Chatbot im üblichen Sinn und auch kein weiteres Sprachmodell. Es ist eine Laufzeitumgebung für Agenten – eine Softwareschicht, die Sprachmodelle mit Kanälen, Gedächtnis, Regeln und echten Werkzeugen verbindet. Das Modell, ob Claude, GPT oder ein lokal gehostetes System, ist dabei nur ein Teil. Den Rest liefert OpenClaw selbst. Nicht das Modell ist das System. Die Umgebung ist das System.
OpenClaw ist Ende 2025 als Nebenprojekt des Entwicklers Peter Steinberger entstanden, hat mehrere Namenswechsel hinter sich – Clawdbot, Moltbot, dann OpenClaw – und war im Frühjahr 2026 nach Sternen zeitweise ganz oben auf GitHub. Das ist eine bemerkenswerte Kurve, aber nicht das Eigentliche. Das Eigentliche ist die Architektur dahinter.
Die vier Kernbausteine
1. Das Gateway: die Schaltzentrale des Systems
Alles läuft hier zusammen. Das Gateway ist ein Node.js-basierter WebSocket-Server. Ein WebSocket ist eine dauerhaft offene Verbindung, über die mehrere Seiten laufend Nachrichten austauschen können. Standardmäßig läuft das Gateway auf 127.0.0.1:18789 – also lokal auf dem eigenen Rechner und nicht öffentlich im Netz. Pro Host läuft in der Regel genau ein Gateway.
Es verbindet sich mit Messaging-Plattformen wie WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Google Chat oder Matrix und übersetzt deren sehr unterschiedliche Eingänge in ein gemeinsames internes Format. Parallel dazu verwaltet es Sitzungen, Zugriffsregeln, Health-Checks und die Weiterleitung an den passenden Agenten. Wer aus der klassischen IT kommt, kann das Gateway als Schaltzentrale mit eingebautem Sicherheitsdienst lesen: Es entscheidet, wer schreiben darf, welches Gerät gepairt ist, welche Nachricht zu welcher Sitzung gehört – bevor irgendetwas an den Agenten weitergegeben wird.
2. Die Agent-Runtime: wo Denken zu Handeln wird
Hinter dem Gateway sitzt die Agent-Runtime. Sie übernimmt den eigentlichen Verarbeitungslauf: Kontext aufbauen, Modell anfragen, Werkzeuge ausführen, Zustand sichern.
Zuerst wird die Sitzung aufgelöst: privater Dialog, Gruppenunterhaltung oder dedizierter Workspace? Daran hängen andere Regeln, andere Skills – manchmal sogar andere Modelle. Danach setzt OpenClaw den Kontext zusammen. „Kontext“ heißt hier nicht nur der letzte Chatverlauf, sondern auch Regeln aus Workspace-Dateien, gespeicherte Erinnerungen und die Definitionen verfügbarer Werkzeuge. Erst dann kommt das LLM ins Spiel – als austauschbarer Provider hinter einer einheitlichen Schnittstelle. OpenClaw ist modellagnostisch: Claude, GPT, Gemini, Mistral oder ein lokal betriebenes Modell via Ollama, also eine Laufzeitumgebung für lokale Sprachmodelle sind gleichrangige Optionen.
Falls Text allein nicht genügt, ruft das System ein Werkzeug auf: Browser öffnen, Datei lesen, Shell-Befehl starten. Hier beginnt der qualitative Unterschied zu einem Chatfenster – OpenClaw kann nicht nur sagen „du solltest diese Datei umbenennen“, sondern den Vorgang anstoßen. Am Ende wird der neue Zustand gespeichert und die Antwort über das Gateway zurück an den ursprünglichen Kanal geschickt.
3. Workspace-Dateien: Persönlichkeit, Regeln und Routine als Text
Ein ungewöhnliches Designprinzip von OpenClaw ist, dass wichtige Teile von Persönlichkeit, Regeln und Routinen als editierbare Textdateien in einem lokalen Workspace-Ordner organisiert sind – versionierbar mit Git, lesbar in jedem Texteditor.
SOUL.md prägt Charakter und Verhaltensgrenzen des Agenten. Ihr Inhalt fließt als einer der ersten Bausteine in den Kontext jeder Sitzung ein. Die erste Zeile der offiziellen Vorlage bringt das Designprinzip direkt auf den Punkt: „You’re not a chatbot. You’re becoming someone.“ Das ist keine Marketing-Formulierung, sondern eine technische Anweisung – sie landet als einer der ersten Sätze im Kontext jedes Gesprächs. Die Vorlage beschreibt die Datei außerdem als bewusst veränderbar: „This file is yours to evolve“ und „If you change this file, tell the user.“ In der Theorie kann sich damit auch die Arbeitsweise des Agenten über die Zeit weiterentwickeln – wie genau das in der Praxis passiert, hängt vom jeweiligen Setup ab.
IDENTITY.md beschreibt Auftritt und Ton. USER.md hält Informationen über den Betreiber. TOOLS.mdkonfiguriert Umgebungsdetails. AGENTS.md definiert Betriebsregeln.
HEARTBEAT.md ist die Datei für den Übergang vom reaktiven zum proaktiven System. Die Dokumentation beschreibt den Grundmechanismus klar: Ist die Datei leer, passiert nichts. Ist sie befüllt, aktiviert OpenClaw periodische Aufgaben – der Agent prüft Zustände, überwacht Änderungen und meldet sich bei relevantem Ergebnis über das Gateway. Der Assistent reagiert dann nicht mehr nur auf Zuruf, sondern kann selbstständig aktiv werden. Die genaue Ausgestaltung variiert je nach Setup und aktuellem Dokumentationsstand.
Gesprächsverläufe und Langzeitwissen können in lesbaren lokalen Dateien abgelegt werden – transparenter als viele geschlossene App-Speicher, aber auch entsprechend sensibel: Wer Zugriff auf dieses Verzeichnis hat, kann im Zweifel sehr private Informationen einsehen.
4. Skills und ClawHub: der erweiterbare Fähigkeitsraum
OpenClaw lässt sich über Skills erweitern: strukturierte Verzeichnisse mit einer SKILL.md, die dem Agenten beschreibt, wann und wie eine Fähigkeit einzusetzen ist. Über ClawHub – eine öffentliche Registry, konzeptionell ähnlich wie npm für JavaScript-Pakete – lassen sich Skills suchen, installieren und aktualisieren. Ende Februar 2026 waren dort über 13.000 Skills registriert.
Erst durch dieses Skill-System wird OpenClaw von einem festen Assistenten zu einer offenen Plattform. Das Plugin-System teilt sich in vier Typen: Channels binden Kommunikationswege an, Memory verwaltet Speicher-Backends, Tools liefern Fähigkeiten, Provider koppeln Modelle an. Diese Trennung macht OpenClaw nicht nur zu einer App, sondern zu einer Infrastruktur mit klar definierten Integrationspunkten.
So läuft eine Anfrage durch das System
Was abstrakt nach viel Infrastruktur klingt, lässt sich im Alltag auf einen einfachen Ablauf herunterbrechen.
Jemand schreibt seinem Assistenten über Telegram. Das Gateway empfängt die Nachricht, prüft ob der Absender in der Allowlist steht und welcher Workspace zuständig ist. Die Agent-Runtime lädt SOUL.md, aktuelle Memory-Dateien und Skill-Definitionen. Dieser vollständige Kontext geht ans LLM. Das Modell antwortet – und entscheidet, ob zusätzlich ein Werkzeug benötigt wird. Falls ja, wird das passende Werkzeug ausgeführt, das Ergebnis fließt zurück ins Modell, die finale Antwort wird gespeichert und über das Gateway an den Telegram-Kanal zurückgesendet.
Für den Nutzer: ein Chat. Unter der Haube läuft dabei eine koordinierte Orchestrierungskette.
Was OpenClaw von ChatGPT, Claude, Codex und Antigravity trennt
Der strukturelle Unterschied lässt sich auf einen Blick zeigen:
| System | Hauptzweck | Wer kontrolliert die Umgebung? | Modellbindung |
|---|---|---|---|
| ChatGPT / Claude.ai / Gemini | Gespräch, allgemeine Assistenz | Anbieter | hoch |
| Claude Code / Codex / Antigravity | Softwareentwicklung | Anbieter / Produkt | hoch |
| Claude Cowork | Desktop-Wissensarbeit | Anbieter | hoch |
| OpenClaw | Allgemeine Agenten-Umgebung | Betreiber | gering |
Entscheidend ist dabei weniger die Qualität der Modelle als die Frage, wem die Umgebung gehört.
Reine LLM-Chatdienste wie ChatGPT, Claude.ai und Gemini sind reaktive Gesprächsschnittstellen. Die Plattform kontrolliert Ablauf, Speicherlogik und Sicherheitsgrenzen. Der Nutzer ist Gast in einer fremden Umgebung – nützlich, aber strukturell gebunden.
Coding Agents wie Claude Code, OpenAI Codex und Google Antigravity sind echte Verwandte von OpenClaw, aber mit klar begrenztem Fokus: Codebasen lesen, editieren, testen und refaktorieren. Claude Cowork geht in Richtung Desktop-Wissensarbeit für Nicht-Entwickler – bequemer und enger geführt, ebenfalls an Anthropics Infrastruktur gebunden.
OpenClaw ist keines davon. Es ist kanalübergreifend, selbst hostbar und modellagnostisch: Coding, Büroautomatisierung oder Smart-Home-Steuerung können in OpenClaw nebeneinander Teil derselben Umgebung sein – je nachdem, welche Skills installiert sind. Und wer es mit lokalen Modellen via Ollama betreibt, verlässt die eigene Hardware nicht.
Wo die Risiken liegen
Genau dieselben Eigenschaften, die OpenClaw spannend machen, machen es auch riskant. Es kann Nachrichten empfangen, Dateien lesen, Browser steuern und Befehle ausführen. OpenClaw selbst dokumentiert das offen: Es gibt kein „perfectly secure setup.“
Die Risiken sind klar benennbar – und ernst:
- Prompt Injection: Manipulierte Eingaben – über Nachrichten oder präparierte Dokumente – können versuchen, dem Agenten verbotene Anweisungen unterzuschieben. Weil OpenClaw Werkzeuge ausführen kann, ist das keine abstrakte Gefahr.
- Zu offene Messaging-Eingänge: Pairing und Allowlists nicht konsequent konfiguriert bedeutet, dass Unbefugte den Agenten ansprechen können.
- Zu weitreichende Tool-Rechte: Shell-Zugriff ist die leistungsfähigste und riskanteste Stufe. Die Dokumentation empfiehlt, Rechte schrittweise zu vergeben – erst lesende Fähigkeiten, dann schreibende, zuletzt Shell.
- Riskante Skill-Installation: Über 13.000 Community-Skills bedeuten 13.000 potenzielle Angriffsvektoren. ClawHub bietet mit VirusTotal eine erste Sicherheitsschicht – ein Ersatz für eigene Prüfung ist das nicht.
- Öffentlich erreichbares Gateway: Das Gateway ist bewusst auf
127.0.0.1lokalisiert. Für Remote-Zugriff empfiehlt die Dokumentation bevorzugt Tailscale/VPN oder einen SSH-Tunnel – offenes Port-Forwarding ist keine Option.
Für wen sich OpenClaw heute lohnt
OpenClaw ist derzeit kein Produkt für die breite Masse. Es ist ein Werkzeug für technisch souveräne Nutzer, die Kontrolle höher bewerten als Bequemlichkeit – und die bereit sind, mit Terminal, Konfigurationsdateien und Zugriffsrechten umzugehen.
Wer eine eigene, modellunabhängige Automatisierungsumgebung aufbauen möchte, Datensouveränität als echte Anforderung hat oder KI nicht nur zum Schreiben, sondern zum strukturierten Handeln einsetzen will – für den ist OpenClaw ernsthaft interessant.
Wer eine sorgenfreie Consumer-App sucht, findet bei Claude.ai, ChatGPT oder Cowork bessere Ausgangspunkte. Das ist keine Kritik, sondern eine ehrliche Einordnung.
Was OpenClaw eigentlich zeigt
Ein Einzelentwickler hat mit einer gezielten Architekturentscheidung – Gateway, Runtime, Workspace-Dateien, Skill-System – in wenigen Monaten eine Infrastruktur gebaut, die Muster aus Enterprise-Systemen auf den eigenen Rechner bringt: Routing, Rollen, Berechtigungen, periodische Jobs, persistente Kontexte, Plugin-Logik. MIT-lizenziert. Durch eine Textdatei konfigurierbar.
Genau darin liegt die eigentliche Neuerung: Nicht die WhatsApp-Nachricht ist der entscheidende Punkt, sondern die Infrastruktur dahinter. Der Sprung liegt nicht im besseren Chatfenster, sondern in der eigenen Agenten-Umgebung: in der Fähigkeit, selbst festzulegen, wie ein System arbeitet, worauf es zugreifen darf und in welchem Rahmen es denkt.