Viele Nutzer beschreiben den KI-Agent OpenClaw (ehemals Moltbot) als „always on" oder „autonom" – als hätte er ein Eigenleben. Doch das ist ein Missverständnis. OpenClaw ist kein sentientes Wesen, das kontinuierlich denkt. Wenn der Agent um 3 Uhr nachts aktiv wird, hat ein Timer, Heartbeat oder Webhook ein Event ausgelöst. Was OpenClaw so besonders macht, ist nicht Bewusstsein, sondern hervorragendes Engineering.
In diesem Architektur-Deep-Dive beleuchten wir, wie OpenClaw intern funktioniert – verständlich für CIOs und technische Entscheider, die verstehen wollen, wie moderne Self-Hosted AI-Agents aufgebaut sind.
Was ist OpenClaw (Moltbot)?
OpenClaw – vielen noch unter dem ursprünglichen Namen Moltbot bekannt – ist ein persönlicher AI-Assistent, der auf eigenen Geräten läuft (self-hosted, local-first). Entwickelt wurde er von Peter Steinberger, der am 14. Februar 2026 zu OpenAI wechselte und das Projekt unter dem neuen Namen OpenClaw in ein Stiftungsmodell überführte. Das Projekt ist unter MIT-Lizenz verfügbar und hat bereits über 200.000 GitHub-Stars gesammelt.
Die Kernfunktionen:
- Verbindung zu bestehenden Messaging-Kanälen: WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Google Chat, Microsoft Teams, Matrix, BlueBubbles, Zalo, WebChat und mehr
- Echte Aktionen: Browser steuern, Dateien lesen/schreiben, Shell-Kommandos ausführen, Cron-Jobs, Kamera/Bildschirm-Zugriff
- Self-Hosted: Alle Daten bleiben auf Ihren Geräten – keine Cloud-Abhängigkeit
Was OpenClaw NICHT ist:
- Kein kontinuierlich denkendes System
- Kein sentientes Wesen
- Keine “echte” Autonomie – alle Aktionen werden durch Events getriggert
Autonome KI-Agents: Das Missverständnis
OpenClaw fühlt sich proaktiv an, weil es mehr Input-Typen verarbeitet als nur Chat-Nachrichten – und diese in einer konsistenten Schleife abarbeitet. Im Gegensatz zu klassischen Chatbots, die nur auf direkte Benutzer-Eingaben reagieren, kann OpenClaw auf verschiedene Event-Quellen reagieren:
- Chat-Nachrichten von verschiedenen Plattformen
- Timer & Cron-Jobs für zeitgesteuerte Aufgaben
- Webhooks von externen Systemen
- Heartbeat-Events für Statusprüfungen
- System-Events wie Dateiänderungen oder Netzwerk-Status
Diese Vielfalt an Input-Quellen erzeugt den Eindruck von Autonomie. Technisch gesehen ist OpenClaw jedoch eine event-driven State Machine – hocheffizient, aber nicht „bewusst". Mehr dazu, was KI-Agents überhaupt sind, lesen Sie in unserem Grundlagenartikel KI-Agenten: Was ist das eigentlich?
OpenClaw Architektur: Das Hub-and-Spoke-Modell
OpenClaw folgt einem Hub-and-Spoke-Modell mit dem Gateway im Zentrum:
WhatsApp / Telegram / Slack / Discord / Signal / iMessage / ...
│
▼
┌───────────────────────────────┐
│ Gateway (Daemon) │
│ (Control Plane) │
│ ws://127.0.0.1:18789 │
└──────────────┬────────────────┘
│
├─ Pi Agent Runtime (RPC)
├─ CLI (openclaw …)
├─ WebChat UI
├─ macOS App
└─ iOS / Android NodesDie Komponenten im Detail:
Gateway = Traffic Controller + Source of Truth
- Ein einzelner, langlebiger Daemon
- Besitzt alle Messaging-Oberflächen (WhatsApp via Baileys, Telegram via grammY, etc.)
- Validiert eingehende Frames gegen JSON Schema
- Exponiert eine typisierte WebSocket-API
- Genau ein Gateway pro Host
Agent Runtime = Worker
- Übernimmt das “Denken + Handeln”
- Führt LLM-Anfragen aus
- Orchestriert Tools und Skills
- Kann lokal (Ollama, DeepSeek) oder remote (Claude, GPT) arbeiten
Das OpenClaw Gateway: Zentraler Router und WebSocket-API
Das Gateway ist das Herzstück von OpenClaw. Es fungiert als zentraler Router, der alle eingehenden Events sammelt, validiert und an die richtigen Agents weiterleitet.
Wire Protocol
OpenClaw nutzt ein einfaches, aber mächtiges WebSocket-Protokoll:
| Frame-Typ | Struktur | Richtung | Zweck |
|---|---|---|---|
| Request | {type: "req", id, method, params} | Client → Gateway | Anfrage vom Client |
| Response | {type: "res", id, ok, payload|error} | Gateway → Client | Antwort vom Gateway |
| Event | {type: "event", event, payload, seq?} | Gateway → Client | Server-Push Event |
Wichtige Regeln:
- Der erste Frame MUSS ein
connect-Frame sein – sonst wird die Verbindung hart geschlossen - Token-Auth bei nicht-lokalen Verbindungen
- TypeBox-Schemas als Single Source of Truth → Runtime-Validierung, JSON-Schema-Export, Swift-Model-Codegen
Event-Typen
Das Gateway emittiert verschiedene Event-Typen:
- agent – Agent-Antworten und Status-Updates
- chat – Neue Nachrichten aus Messaging-Kanälen
- presence – Online/Offline-Status von Kontakten
- health – System-Health-Checks
- heartbeat – Periodische Lebenszeichen
- cron – Zeitgesteuerte Events
Diese Event-Vielfalt ermöglicht es OpenClaw, auf verschiedenste Situationen zu reagieren – ohne dass ein Mensch eingreifen muss.
Session-Management: Daten-Isolation im KI-Agent
Ein kritischer Aspekt der OpenClaw-Architektur ist das Session-Management. Sessions verhindern Context-Leaks zwischen verschiedenen Kanälen und Personen.
Session-Konzepte:
Default-Modus (Standard):
- Eine gemeinsame DM-Session (
main) pro Agent – alle DMs landen im selben Context - Separate Sessions für Groups/Channels/Threads
- Persistierung als JSONL auf Disk:
~/.openclaw/agents/<agent-id>/sessions/
Secure DM Mode (opt-in):
- Isoliert DMs pro Sender/Kanal
- Verhindert Context-Sharing zwischen verschiedenen Personen
- Ideal für Multi-User-Setups – muss explizit aktiviert werden
Warum ist das wichtig?
In Unternehmensumgebungen ist Daten-Isolation kritisch. Stellen Sie sich vor, ein Agent beantwortet Fragen von verschiedenen Mitarbeitern:
- Ohne Session-Isolation: Mitarbeiter A könnte versehentlich Informationen von Mitarbeiter B sehen
- Mit Session-Isolation: Jeder Mitarbeiter hat seinen eigenen Context – keine Cross-Contamination
OpenClaw bietet hier eine bewusste Design-Entscheidung: Im Default-Modus teilen sich alle DMs einen Context – das ist bequem für Einzelnutzer. Für Unternehmensumgebungen sollte der Secure DM Mode aktiviert werden, der echte Isolation gewährleistet.
OpenClaw vs. Chatbot: Die Unterschiede
Was unterscheidet OpenClaw von einem einfachen ChatGPT-Wrapper?
| Aspekt | Klassischer Chatbot | OpenClaw |
|---|---|---|
| Input | Nur Chat-Nachrichten | Chat, Timer, Webhooks, System-Events |
| State | Oft stateless oder nur Conversation-History | Persistent Sessions mit vollständigem Context |
| Aktionen | Text-Antworten | Browser, Shell, Dateien, APIs, Cron-Jobs |
| Deployment | Cloud-hosted | Self-hosted, local-first |
| Privacy | Daten gehen zu Drittanbietern | Alle Daten bleiben lokal |
| LLM-Flexibilität | Festgelegt | Wechsel zwischen remote/local mit einem Config-Change |
OpenClaw ist kein Chatbot – es ist eine programmierbare Workflow-Engine mit AI im Kern. Wer den Vergleich zwischen klassischen Workflows und KI-Agents vertiefen möchte, findet hier eine ausführliche Analyse: Digitale Workflows vs. KI-Agents
KI-Agents im Unternehmen: Anwendungsfälle und DSGVO
Aus technischer Sicht ist OpenClaw beeindruckend. Aber was bedeutet das für Ihr Unternehmen?
Anwendungsfälle:
1. Interne Prozessautomatisierung
- Automatisches Monitoring von Systemen
- Benachrichtigungen bei Anomalien
- Ticket-Erstellung bei Problemen
- Zusammenfassung von täglichen Reports
2. Multi-Channel-Kundenservice
- Ein Agent, der auf WhatsApp, Telegram und Slack gleichzeitig antwortet
- Konsistente Antworten über alle Kanäle
- Context-Sharing (wo gewünscht) oder Isolation (wo nötig)
3. Persönliche Assistenten für Führungskräfte
- E-Mail-Triage und -Zusammenfassung
- Kalender-Management
- Meeting-Vorbereitung
- Recherche-Aufgaben
4. Entwickler-Produktivität
- Code-Review-Assistenz
- Dokumentations-Generierung
- Bug-Triage
- Automatisierte Tests
Die Self-Hosted-Philosophie
Ein entscheidender Punkt für deutsche Unternehmen: DSGVO-Konformität. Da OpenClaw self-hosted läuft, bleiben alle Daten im eigenen Rechenzentrum.
Wichtig: Die DSGVO-Konformität gilt nur, solange auch das verwendete LLM lokal betrieben wird (z. B. via Ollama oder DeepSeek). Sobald ein Remote-LLM wie Claude oder GPT-4 konfiguriert wird, fließen Prompt-Daten an den jeweiligen Anbieter – mit allen datenschutzrechtlichen Implikationen. Unternehmen sollten hier bewusst zwischen lokaler und Remote-Verarbeitung abwägen.
Das ist nicht nur ein Compliance-Vorteil – es gibt Ihnen auch volle Kontrolle über:
- Welche Daten verarbeitet werden
- Wie lange Daten gespeichert werden
- Wer Zugriff auf welche Sessions hat
- Welches LLM verwendet wird (lokal vs. remote)
Technische Herausforderungen: Event-Ordering, State und LLM-Integration
OpenClaw löst mehrere nicht-triviale Engineering-Probleme:
1. Multi-Platform-Messaging
Herausforderung: Jede Messaging-Plattform hat ihre eigene API, Authentifizierung und Eigenheiten.
Lösung: Abstraktionsschicht mit modularen Adaptern. Neue Plattformen können als Plugin hinzugefügt werden, ohne Core-Code zu ändern.
2. Event-Ordering und Race Conditions
Herausforderung: Events können aus verschiedenen Quellen gleichzeitig eintreffen.
Lösung: Queue-basierte Serialisierung der Event-Verarbeitung (ein Event wird vollständig abgearbeitet, bevor das nächste beginnt), Single-Writer-Pattern für Sessions, Sequenznummern (seq) zur Nachvollziehbarkeit.
3. State Management
Herausforderung: Wie persistiert man den State zuverlässig, ohne Performance zu opfern?
Lösung: JSONL-Dateien für Sessions (append-only), Memory-Cache für häufig genutzte Sessions, Lazy Loading.
4. LLM-Flexibilität
Herausforderung: Verschiedene LLMs haben unterschiedliche APIs, Token-Limits, Capabilities.
Lösung: Abstraction Layer, der OpenAI, Anthropic, lokale Models (Ollama, DeepSeek) einheitlich anspricht.
OpenClaw Plugin-System: Skills und Erweiterbarkeit
OpenClaw ist extensible by design. Das Plugin-System (“Skills”) ermöglicht:
- Hot-Reload während der Entwicklung
- Wachsender Community-Marketplace
- Typsichere Skill-Definitionen
Beispiele für verfügbare Skills:
- Web-Scraping – Inhalte von Websites extrahieren
- Email – Gmail/Outlook-Integration
- Calendar – Google Calendar, Outlook Calendar
- GitHub – Issues, PRs, Code-Review
Diese Erweiterbarkeit macht OpenClaw zu einer Plattform, nicht nur einem Tool.
Sicherheit bei KI-Agents: Best Practices für Unternehmen
Mit großer Macht kommt große Verantwortung. OpenClaw kann Shell-Kommandos ausführen, Dateien ändern, E-Mails versenden – das birgt Risiken. Eine vertiefte Sicherheitsanalyse finden Sie in unserem Artikel OpenClaw: Wenn KI-Agents vollen Systemzugriff bekommen.
Sicherheitsmaßnahmen in OpenClaw:
- Self-Hosted: Kein Drittanbieter-Zugriff
- Session-Isolation: Verhindert ungewolltes Context-Sharing
- Token-Auth: Nur autorisierte Clients können sich verbinden
- Prompt-Injection-Awareness: Dokumentierte Best Practices und Empfehlungen zur Absicherung
- Skill-Ausführung im Gateway-Prozess: Plugins laufen direkt im Gateway – Zugriffssteuerung über Konfiguration und Policies
- Audit-CLI: Alle Agent-Aktionen werden protokolliert und können nachvollzogen werden
Best Practices für Unternehmen:
- OpenClaw nicht mit Admin-Rechten laufen lassen
- Separate Agents für verschiedene Sensitivitätsstufen
- Regelmäßige Reviews der ausgeführten Aktionen
- Klare Policies, welche Skills aktiviert werden dürfen
- Network-Segmentierung: OpenClaw nur in definierten Netzwerk-Zonen
OpenClaw Foundation: Open Source statt Vendor Lock-in
Peter Steinbergers Wechsel zu OpenAI und die Überführung in ein Stiftungsmodell zeigen: OpenClaw ist mehr als ein Side-Project. Es ist ein Statement, wie AI-Agents gebaut werden sollten:
- Open Source statt Vendor Lock-in
- Privacy-First statt Cloud-Only
- Community-Driven statt Corporate-Controlled
- Extensible statt Monolithisch
OpenClaw demonstriert, dass “autonome” Agents keine Magie sind – es ist gutes Engineering. Die Architektur ist durchdacht, modular und skalierbar.
Fazit: OpenClaw-Architektur – Engineering statt Magie
OpenClaw fühlt sich “lebendig” an, weil es:
- Viele Input-Quellen hat (nicht nur Chat)
- Persistent State über Sessions verwaltet
- Echte Aktionen ausführen kann (nicht nur antworten)
- Event-driven arbeitet (proaktiv statt reaktiv)
- Lokal läuft (immer verfügbar, keine API-Limits)
Technisch gesehen ist es eine hochoptimierte State Machine mit LLM-Integration – aber genau das macht moderne AI-Agents aus.
Für Entscheider lautet die Kernfrage: Wie können wir diese Architektur-Prinzipien in unsere eigenen Systeme integrieren?
OpenClaw zeigt den Weg:
- Event-driven statt request-response
- Multi-Channel statt Single-Channel
- Self-hosted statt Cloud-dependent
- Extensible statt Monolithisch
Die Zukunft der Enterprise-AI liegt nicht in geschlossenen SaaS-Lösungen, sondern in offenen, selbst-gehosteten Plattformen, die sich nahtlos in bestehende Infrastrukturen integrieren.
OpenClaw ist der Proof of Concept. Der nächste Schritt ist Ihrer.
Über den Autor
Tobias Jonas ist Co-CEO der innFactory AI Consulting GmbH und Experte für KI-Architekturen und Cloud-Systeme. Er berät Unternehmen bei der strategischen Integration von AI-Agents in bestehende IT-Landschaften.
Möchten Sie verstehen, wie AI-Agents wie OpenClaw in Ihrem Unternehmen eingesetzt werden können? Kontaktieren Sie uns für eine unverbindliche Beratung – oder erfahren Sie mehr über unsere KI-Strategieberatung und unser DSGVO-konformes Produkt CompanyGPT.