OpenClaw-Praxis: Enthusiasmus bei c't, Ernuechterung bei NonBioS

11. April 2026

OpenClaw ist diese Woche gleich zweimal im deutschsprachigen Raum aufgeschlagen -- mit gegensaetzlichen Vorzeichen. c't 3003 hat ein Praxis-Video unter dem Titel "Das kann OpenClaw in der PRAXIS" veroeffentlicht, das den Agenten als dauerhaft laufende Lern-Instanz zeigt, die proaktiv handelt. Am selben Tag schreibt Nishant Soni, Gruender der Deployment-Plattform NonBioS, einen Blog-Beitrag, dessen Titel fuer sich spricht: "OpenClaw's memory is unreliable, and you don't know when it will break." Wer beide Perspektiven nebeneinanderlegt, bekommt einen seltenen Fall, in dem sich journalistische Faszination und Operator-Ernuechterung praezise am selben Punkt reiben.

Soni: Tausend Deploys, ein einziger echter Use-Case

Soni betreibt mit NonBioS eine Automatisierung, die OpenClaw auf frische Linux-VMs installiert -- komplett ohne menschlichen Eingriff, etwa sieben Minuten pro Deployment. Ueber diese Pipeline sind mittlerweile rund tausend OpenClaw-Instanzen gelaufen. Dazu hat Soni Engineers, Founder und Operators aus seinem Netzwerk befragt, die OpenClaw selbst ueber Wochen produktiv zu nutzen versuchten. Sein Fazit ist kompromisslos: "Zero legitimate use cases." Der einzige Workflow, der sich tatsaechlich haelt, sind personalisierte Morgennachrichten per WhatsApp -- etwas, das sich mit einem Zapier-Flow oder ChatGPT-Scheduled-Tasks in einer halben Stunde nachbauen laesst.

Der Kern des Problems ist fuer Soni nicht die Oberflaeche, sondern die Context-Verwaltung. OpenClaw laeuft als persistenter Agent, der Kontext akkumuliert -- und genau dieser Kontext kippt irgendwann. Nicht mit einem Crash, sondern leise. Sein Beispiel trifft den wunden Punkt autonomer Agenten sehr genau: Der Agent verfolgt einen Geburtstags-Thread, drei Zusagen, eine Absage. Dann schickt er eine Update-Mail raus und hat die Absage vergessen. Wer autonom delegiert, hat per Definition nicht in die einzelne Aktion reingeschaut. "An autonomous agent that you have to verify every time is just a chatbot with extra steps", bringt Soni es auf den Punkt. Sein Urteil zu Memory-Architekturen, die versuchen, das Problem durch Tages-, Monats- und Jahres-Dateien zu erschlagen, ist genauso hart: "The brain is not a list of files that you index."

c't 3003: Dauerhaft, lernfaehig, proaktiv -- und mit Warnschild

Die c't-Video-Redaktion nimmt denselben Agenten und kommt zu einer ganz anderen Tonlage. OpenClaw laufe "permanent", lerne "selbststaendig" und handle "proaktiv" -- das sei der eigentliche Schritt weg vom Chatbot. Gleichzeitig ist das Warnschild nicht verschwunden: Der Teaser betont explizit, dass Vorsicht geboten sei. Das Video ordnet OpenClaw damit in eine Kategorie ein, die laut c't "die Zukunft" beschreibt, legt aber Wert darauf, dass aktuelle Installationen nicht sorglos produktiv gehen sollten. Der Tonfall ist der eines Formats, das dem Publikum ein Konzept zeigen will, nicht der eines Operators, der die Langzeitkosten trägt.

Beide Beobachtungen widersprechen sich weniger, als es scheint. c't beschreibt, was OpenClaw in der Demo kann -- und das ist beeindruckend genug, um ein achtminuetiges Video zu tragen. Soni beschreibt, was davon nach drei Wochen Betrieb noch uebrig bleibt.

Konkrete Failure-Modi im Memory-System

Aus Sonis Bericht lassen sich vier wiederkehrende Bruchstellen ableiten, die sich gut mit dem decken, was in Agent-Memory ohne Hype als "schlechte Kontext-Auswahl, unkontrolliertes State-Wachstum und fehlende Lifecycle-Verantwortung" beschrieben ist:

Stillen Context-Drop: Der rollende Working-Context wird vom Modell selbst getrimmt, relevante Fakten (wer hat abgesagt?) fallen unangekuendigt raus.
File-basiertes Langzeit-Memory als Indexillusion: OpenClaws Ansatz, Erinnerungen in kalendarisch organisierte Dateien zu schreiben, erzeugt das Gefuehl von Persistenz, ohne dass semantisches Retrieval vorgesehen ist. Der Agent liest spaeter nicht automatisch nach.
Kein Uebergabepunkt zwischen Sessions: Wer einen persistenten Agenten verspricht, muss definieren, was eine "Session" ueberhaupt noch ist. OpenClaw laesst diese Frage offen, sodass Kontext-Fenster einfach bis zum Limit wachsen.
Keine Feedback-Schleife bei Fehlverhalten: Weil der Agent autonom handelt (Mails verschicken, Shell-Befehle ausfuehren), merkt der Mensch erst nach dem Schadensfall, dass ein Fakt fehlte.

Diese Muster sind nicht OpenClaw-spezifisch, aber sie kumulieren hier, weil die Architektur alle drei Schichten gleichzeitig versucht: Always-on-Daemon, Datei-Memory und autonome Tool-Calls ohne harten Verifikationsschritt.

Praktischer Umgang, falls man OpenClaw trotzdem einsetzt

Wer OpenClaw aus Neugier oder fuer begrenzte Experimente laufen laesst, kann das Memory-Risiko nicht wegschreiben, aber einhegen:

Manuelle Checkpoints: Kritische Fakten (Empfaenger, Zusagen, Geldbetraege) vor jedem autonomen Schritt in einen externen, strukturierten Store schreiben, etwa DecisionNode (siehe OpenClaw-Oekosystem) oder eine simple SQLite-Tabelle, die der Agent per Tool-Call abfragen muss.
Session-Trennung erzwingen: Jeden Task in einem frischen Kontext starten, das Working-Memory nach jedem Run dumpen und extern zusammenfassen, statt den Daemon tagelang durchlaufen zu lassen. Das kostet Context-Persistenz, aber gewinnt Vorhersagbarkeit.
Reflection-Skripte: Nach jedem autonomen Schritt einen zweiten Agentenlauf anstossen, dessen einziger Job es ist, die Ausgabe gegen die ursprueenglichen Facts zu pruefen. Teuer, aber die einzige Alternative zum menschlichen Review.
Isolation first: Soni und c't sind sich an diesem Punkt einig -- OpenClaw gehoert in eine VM oder einen Container mit minimalen Berechtigungen, nicht auf die Workstation mit Mailzugriff. Nach der Sicherheitskrise um ClawJacked ist das ohnehin Pflicht.
Externer Memory-Store: Langzeit-Fakten nicht dem Agent-Dateisystem ueberlassen, sondern in einen Store schreiben, fuer den klar definiert ist, wer schreibt, wer liest und wie lange Eintraege gueltig sind. Die in Beyond RAG diskutierten Muster sind hier die bessere Referenz als OpenClaws Bordmittel.

Don't trust agent memory -- auch jenseits von OpenClaw

Der wichtigste Satz aus Sonis Artikel gilt nicht nur fuer OpenClaw: Ein Agent, den man jedes Mal verifizieren muss, ist kein autonomer Agent. Das betrifft Claude Code, Cursor, Codex und jedes andere System, das zwischen Turns Kontext verliert oder zwischen Sessions angeblich Wissen mitnimmt, ohne dass klar waere, welches. Die Forschung zu Multi-Layer-Memory und Cross-Domain-Personalisierung zeigt, dass aktuell kein System das zuverlaessig loest -- das Teilproblem "welche Fakten muss ich vergessen, welche aufheben" ist offen. Solange das so ist, bleibt die Pflicht beim Entwickler: Memory explizit entwerfen, Lifecycle nennen, Verifikationspunkte einbauen. Alles andere ist Theater, das in Produktion umkippt, sobald der Agent etwas Wichtiges tut.

Die parallele Beobachtung von c't und NonBioS ist in diesem Sinne keine Widersprueche, sondern eine vollstaendige Geschichte: Der Agent kann das, was die Demo verspricht. Nur nicht lange genug am Stueck, um dafuer die Verantwortung zu uebernehmen.

Quellen

Nach oben