--- title: Vier Wochen mit OpenClaw im Unternehmen: Was funktioniert und was noch nicht author: Lars Decker date: 2026-09-08 updated: 2026-09-08 description: Vier Wochen OpenClaw im Unternehmen: Skills und Self-Hosting funktionieren schon gut, Betrieb und Nachvollziehbarkeit bei Agenten noch nicht. tags: ki, ki-agenten, multi-agenten-systeme, automatisierung, produktmanagement canonical: https://lars-decker.eu/blog/vier-wochen-openclaw-im-unternehmen --- # Vier Wochen mit OpenClaw im Unternehmen: Was funktioniert und was noch nicht _Ein KI-Agent, der dauerhaft auf einem eigenen Server läuft, Aufgaben entgegennimmt, sich Dinge merkt und Skills ausführt, klingt schnell nach digitalem Mitarbeiter. Nach vier Wochen im echten Einsatz sieht die Bilanz differenzierter aus._ Wir beschäftigen uns seit einigen Wochen intensiver mit OpenClaw, einem selbst gehosteten Gateway für dauerhaft verfügbare KI-Agenten. Unser interner Agent heißt Watson. Er läuft nicht auf meinem Notebook, sondern auf einem eigenen Server und soll langfristig mehr sein als ein weiterer Chatbot: ein zentraler Ansprechpartner, der Aufgaben entgegennimmt und selbst entscheidet, welche Fähigkeiten oder spezialisierten Agenten er dafür braucht. Nach rund vier Wochen ist mein Eindruck ziemlich eindeutig. OpenClaw zeigt gut, wohin sich KI-Agenten entwickeln können. Im produktiven Einsatz merkt man aber schnell, dass zwischen „der Agent kann das" und „wir können uns im Unternehmen darauf verlassen" noch ein deutlicher Unterschied liegt. --- ## Warum wir Watson dauerhaft auf einem Server laufen lassen Claude Code oder Codex sind sehr gute Agenten für Softwareentwicklung, arbeiten dabei aber meist innerhalb einer einzelnen Session: Aufgabe rein, Agent arbeitet, Ergebnis raus, Session vorbei. OpenClaw verfolgt eine andere Idee. Agenten lassen sich über verschiedene Kanäle ansprechen, besitzen eigene Workspaces, Sessions, Memory und Skills und können mit anderen Agenten zusammenarbeiten. Aus „Hilf mir bei dieser einen Aufgabe" wird damit eher „Hier ist ein Ziel, organisiere die notwendigen Schritte und komm mit einem Ergebnis zurück". Watson läuft dafür auf einer eigenen Linux-VM, bekommt Aufgaben, verfügt über eigene Skills und kann auf definierte Werkzeuge und Arbeitsbereiche zugreifen. Langfristig sollen darunter spezialisierte Agenten arbeiten, etwa für Product Discovery, Research, Softwareentwicklung, SEO und GEO oder technische Reviews. Watson selbst muss dabei nicht der beste Entwickler oder Researcher sein. Er muss wissen, wer oder was eine Aufgabe am besten erledigt. --- ## Was nach vier Wochen schon gut funktioniert Ein Agent fühlt sich anders an, wenn er dauerhaft erreichbar ist. Ich muss nicht erst ein Repository öffnen, einen neuen Chat starten und Kontext erklären, um drei Tage später zu hoffen, dass ich noch weiß, was wir gemacht haben. Watson ist einfach da, ich kann ihm eine Aufgabe geben und später darauf zurückkommen. Das fühlt sich weniger nach „Tool benutzen" an und mehr nach Delegation. Ich formuliere Aufgaben dadurch auch anders: nicht mehr „Schreib mir bitte diesen Text", sondern eher „Analysiere dieses Thema nach unserem Prozess und bereite mir eine Entscheidung vor". Skills sind wichtiger als das Modell dahinter. Ein Skill legt fest, wann er verwendet wird, welche Informationen nötig sind, welche Schritte ausgeführt werden, welche Tools erlaubt sind, welches Ergebnis erwartet wird und wann ein Mensch eingebunden werden muss. Aus „Mach eine Product Discovery" wird so ein reproduzierbarer Prozess. Ein sehr gutes Sprachmodell kann improvisieren, ein guter Skill sorgt dafür, dass es das nicht jedes Mal muss. Für Unternehmen ist das wichtig: Wenn fünf Mitarbeiter Watson dieselbe Aufgabe geben, sollte das Ergebnis nicht davon abhängen, wer den besseren Prompt formuliert. Self-Hosting gibt uns viel Freiheit über die Umgebung: welche Modelle wir verwenden, welche Tools verfügbar sind, welche Daten erreichbar sind, welche Skills installiert werden. Für Experimente ist das großartig, weil ich einen Agenten umbauen oder ein anderes Modell testen kann, ohne mich an die Produktlogik eines einzelnen Anbieters zu binden. Diese Offenheit macht OpenClaw interessant und ist gleichzeitig eine seiner größten Herausforderungen, dazu unten mehr. Am zuverlässigsten laufen aktuell klar begrenzte Aufgaben: Informationen zusammentragen, bestehende Dokumentation prüfen, Reports vorbereiten, wiederkehrende Checks ausführen, Ergebnisse nach festen Vorlagen aufbereiten. Je klarer Eingang, Prozess und erwartetes Ergebnis definiert sind, desto besser funktioniert der Agent. Bei KI-Agenten entsteht schnell der Reflex, dass ein Agent, der zehn kleine Dinge kann, auch das große Ganze allein können müsste. Genau dort wird es schwierig. --- ## Was noch nicht gut funktioniert Ein Agent auf einem Server ist plötzlich ein echtes Produktivsystem. Solange ein Agent auf meinem Notebook läuft und abstürzt, starte ich ihn neu. Wenn er dauerhaft Aufgaben für mehrere Personen erledigen soll, geht es plötzlich um CPU und RAM, Swap, Datenbanken, Logs, Backups, Updates, Prozessüberwachung, Timeouts, parallele Tasks und den Umgang mit fehlerhaften Sessions. Wir hatten Situationen, in denen SQLite-Transaktionen ungewöhnlich lange blockiert waren, während gleichzeitig mehrere Prozesse liefen und die Maschine stärker mit Swap arbeitete. Das ist kein grundsätzliches OpenClaw-Problem, zeigt aber, dass autonome Agenten ebenso viel Betrieb brauchen wie klassische Anwendungen, vielleicht sogar mehr: Ein klassisches Backend führt relativ deterministischen Code aus, ein Agent kann dagegen Dateien analysieren, Prozesse starten, APIs aufrufen und mehrere Arbeitsschritte hintereinander ausführen. Aus „wir installieren einen Agenten" wird so überraschend schnell die Frage, wer eigentlich die Agenten-Infrastruktur betreibt. Nachvollziehbarkeit wird wichtiger, je autonomer der Agent arbeitet. Bei einer normalen Chat-Unterhaltung sehe ich meistens genau, was passiert. Bei längeren Agenten-Prozessen sucht Watson Informationen, liest Dateien, nutzt einen Skill, plant weitere Schritte, startet weitere Prozesse und führt Ergebnisse zusammen. Das Ergebnis kann hervorragend sein, aber irgendwann stellt sich die Frage, warum der Agent genau diese Entscheidung getroffen hat. Im Unternehmenskontext muss man wissen, welche Quellen verwendet wurden, welcher Prozess ausgeführt wurde, welche Annahmen getroffen wurden, welcher Agent beteiligt war und wo ein Fehler entstanden ist. Bei klassischen Anwendungen beobachten wir dafür Requests, Logs und Metriken. Bei Agentensystemen fehlt bislang ein vergleichbar etabliertes Gegenstück für einzelne Entscheidungen. Memory ist hilfreich, aber noch kein Unternehmenswissen. OpenClaw bringt dafür verschiedene Mechanismen mit und entwickelt den Bereich gerade weiter, aber Memory und Wissensmanagement sind zwei unterschiedliche Dinge. Dass Lars Variante B bevorzugt, ist Memory. Warum wir uns in einem Projekt vor drei Monaten gegen Variante A entschieden haben und welche Auswirkungen das auf die Architektur hatte, ist Unternehmenswissen und braucht strukturierte Quellen wie Confluence, Jira, Git-Repositories oder Decision Records. Wir denken deshalb inzwischen weniger darüber nach, wie der Agent ein möglichst großes Gedächtnis bekommt, und stärker darüber, wie er zuverlässig den richtigen Kontext für eine konkrete Aufgabe bekommt. --- ## Ein Agent für alles ist die falsche Idee Am Anfang ist die Vorstellung verlockend: ein Super-Agent, der Research, Product Discovery, Programmierung, SEO und Dokumentation gleichermaßen übernimmt. Je länger wir experimentieren, desto skeptischer werde ich gegenüber diesem Modell. Nicht weil ein leistungsfähiges Modell diese Aufgaben grundsätzlich nicht lösen könnte, sondern weil die Prozesse dahinter komplett unterschiedlich sind. Ein Product-Discovery-Agent braucht andere Skills, Datenquellen und Qualitätskriterien als ein Coding-Agent, und ein Coding-Agent braucht wieder andere Rechte als ein Marketing-Agent. Mir gefällt deshalb ein anderes Bild: Nicht ein Agent kann alles, sondern ein Agent weiß, welcher Spezialist etwas kann. Der zentrale Agent wird damit eher zum Orchestrator, oder etwas menschlicher formuliert: zum Manager. Genau hier zeigt sich auch, warum Multi-Agenten-Systeme schwieriger sind, als sie aussehen. Für eine Aufgabe wie „Finde eine neue Produktidee für diese Zielgruppe und entwickle daraus einen validierbaren Prototypen" lässt sich ein Ablauf mit mehreren spezialisierten Agenten und einem Human Gate zwischen Analyse und Entscheidung skizzieren: ein Discovery-Agent analysiert Zielgruppe und Probleme, ein Research-Agent prüft Markt und Wettbewerb, ein Mensch entscheidet, welche Idee weiterverfolgt wird, ein Agent erstellt daraus Anforderungen, ein weiterer baut einen Prototypen, ein letzter prüft das Ergebnis gegen die Anforderungen. Auf einem Diagramm wirkt das elegant. In der Praxis entstehen sofort neue Fragen: Wer besitzt den Gesamtstatus? Was passiert, wenn zwei Agenten unterschiedlicher Meinung sind? Wie wird Kontext weitergereicht, wer darf Entscheidungen treffen, wie verhindert man Endlosschleifen? Plötzlich baut man nicht mehr einfach Agenten, sondern Organisation. Multi-Agenten-Systeme sind aus meiner Sicht deshalb weniger ein KI-Problem als ein Prozessdesign-Problem. --- ## Human Gates und der unsichtbare Führungsaufwand Autonomie gilt bei KI-Agenten oft als Ziel. Ich bin mir nicht sicher, ob das die richtige Metrik ist. Entscheidend ist für mich nicht, wie viel ein Agent allein erledigen kann, sondern wie wenig menschliche Zeit wir brauchen, ohne relevante Kontrolle oder Qualität zu verlieren. Watson darf selbstständig recherchieren, Alternativen bewerten, Informationen strukturieren und einen Vorschlag erstellen. Bevor aus mehreren Produktideen eine ausgewählt und entwickelt wird, entscheidet ein Mensch. Das ist keine Schwäche des Agentensystems, sondern gutes Prozessdesign: Ich will nicht jeden Arbeitsschritt kontrollieren, sondern die Entscheidungen, die wirklich zählen. Wenn Watson schlechte Ergebnisse liefert, liegt die Ursache erstaunlich oft nicht beim Modell, sondern an einem fehlenden klaren Ziel, einem unpassenden Skill, fehlendem Kontext oder einer unklaren Definition von „fertig". Das sind dieselben Probleme, die man von menschlichen Teams kennt: Ein Agent mit einem schlechten Briefing produziert schlechten Output sehr effizient. Deshalb verändert sich aus meiner Sicht auch die Rolle von Product Ownern und anderen Wissensarbeitern. Wir müssen nicht nur lernen, KI zu benutzen, sondern Agenten zu führen: Ziele definieren, Kontext bereitstellen, Verantwortungsbereiche abgrenzen, Qualität messbar machen, Feedback geben. Prompt Engineering trifft das nur teilweise, ich würde es eher Agent Management nennen. --- ## Würde ich OpenClaw heute produktiv einsetzen? Für klar definierte, reversible und beobachtbare Prozesse ja. Dauerhaft erreichbare Agenten, Self-Hosting, Skills, flexible Modellwahl und spezialisierte Agenten für wiederkehrende Aufgaben finde ich schon jetzt tragfähig. Vorsichtiger wäre ich aktuell bei Prozessen, bei denen ein Fehler unmittelbar große Auswirkungen hat, etwa irreversible Produktivänderungen, Veröffentlichung ohne Review oder weitreichende Entscheidungen ohne Human Gate. Das kann sich mit besseren Guardrails und mehr Erfahrung ändern, aber aktuell würde ich Autonomie schrittweise erhöhen statt sie von Anfang an vollständig zu gewähren: erst beobachten, dann unterstützen, dann ausführen lassen, erst danach automatisieren. --- ## Fazit OpenClaw ist für uns aktuell weniger ein fertiger digitaler Mitarbeiter als eine Infrastruktur, um genau solche Systeme zu bauen. Die eigentliche Verschiebung liegt für mich nicht darin, dass ein Chatbot jetzt dauerhaft auf einem Server läuft, sondern darin, dass sich Arbeit anders strukturieren lässt: Menschen definieren Ziele und Entscheidungen, ein Manager-Agent koordiniert Prozesse, Skills legen reproduzierbare Arbeitsweisen fest, spezialisierte Agenten übernehmen konkrete Aufgaben, Human Gates sichern die wichtigen Entscheidungen ab. Watson hatte in den vergangenen vier Wochen seine Aussetzer, von Ressourcenengpässen bis zu Momenten, in denen wir uns fragten, warum er gerade das getan hat, was er getan hat. Genauso gab es Momente, in denen ich ihm eine größere Aufgabe übergeben habe, später zurückgekommen bin und gemerkt habe: Das ist nicht mehr einfach ChatGPT mit einem längeren Prompt. Deshalb experimentieren wir weiter. Die spannende Frage der nächsten Jahre ist für mich ohnehin nicht, welches Modell wir verwenden, sondern wie wir Arbeit organisieren, wenn Menschen und Agenten gemeinsam daran arbeiten.