OpenClaw und das agentische Zeitalter

OpenClaw fühlte sich an wie der ChatGPT-Moment der agentischen Entwicklungsstufe von KI.

Nicht weil es die zugrunde liegende Technologie erfunden hätte. ChatGPT hat Transformer auch nicht erfunden. Der Bruch lag in der Verpackung. Eine technische Fähigkeit, die vorher in verstreuten, unbequemen und spezialisierten Formen existierte, erschien plötzlich durch eine einfache Oberfläche, die viel mehr Menschen verstehen konnten.

OpenClaw hat etwas Ähnliches für Agenten getan. Es nahm Sprachmodelle, Werkzeuge, Rollen, Prompts, Speicher und Kanäle und ordnete sie in eine Struktur, die nach dem ersten Sehen fast selbstverständlich wirkte. Das System war mächtig, gerade weil es einfach genug blieb, um es zu begreifen.

Diese Einfachheit ist wichtig.

Viele Agenten-Frameworks beginnen mit einer vollständigen Theorie von Agency. Sie definieren komplexe Abstraktionen, Workflows, Graphen, Memories, Planner, Worker, Evaluatoren, Supervisoren und Kontrollschichten, bevor der Nutzer überhaupt gespürt hat, wofür das Ganze da ist. Ein Teil dieser Struktur wird später nützlich. Aber zu viel Struktur am Anfang kann den eigentlichen Sprung verdecken.

OpenClaw begann näher am Metall. Eine einfache Runtime. Prompt-Dateien als Verhaltensdefinitionen. Grundlegende Gateway-Mechaniken, durch die Agenten in Kanälen auftauchen konnten, die Menschen ohnehin schon nutzen. Genug Koordination, um Arbeit möglich zu machen, aber nicht so viel Architektur, dass das System zu einem Labyrinth wurde.

Dadurch wurde es lesbar. Man konnte sich die Teile anschauen und verstehen, warum sich der Agent so verhielt. Man konnte einen Prompt ändern und damit den Agenten verändern. Man konnte einen Kanal verbinden und dem System eine Oberfläche in der Welt geben. Man konnte ihm Werkzeuge geben und beobachten, wie die Grenze zwischen Gespräch und Operation zu verschwimmen begann.

Das Modell begann, die Struktur zu tragen

Das Timing war kein Zufall.

Agentensysteme waren jahrelang konzeptionell attraktiv und praktisch frustrierend. Man konnte ein Modell bitten zu planen. Man konnte es Werkzeuge aufrufen lassen. Man konnte es sogar über Prompts nachdenken oder kleinere Arbeitseinheiten koordinieren lassen. Aber die Fehlerquote blieb hoch. Das Modell verlor den Überblick, erfand Fakten, verstand Werkzeuge falsch, ignorierte Einschränkungen oder baute aufwendig klingende Strukturen, die in der Praxis zusammenfielen.

Verschachteltes Prompting war besonders fragil. Sobald ein Modell über einen anderen Prompt, eine andere Rolle, einen anderen Kontext oder eine andere Teilaufgabe nachdenken musste, wuchs die Fehlerfläche. Das Modell beantwortete nicht mehr nur eine Frage. Es half dabei, das System zu bauen, das spätere Fragen beantworten sollte. Dafür braucht es eine andere Stufe von Zuverlässigkeit.

Claude Opus 4 veränderte das Gefühl dieser Arbeit. Opus 4.5 schärfte es noch einmal. Die Modelle wurden gut genug im Umgang mit Terminals, im Bearbeiten von Code, in der Zerlegung von Aufgaben, im Befolgen von Anweisungen und im Denken über lange Kontexte, dass Orchestrierung nicht mehr wie ein Spielmuster wirkte, sondern wie nützliche Infrastruktur.

Auch größere Kontextfenster veränderten die Form des Problems. Ein Agent kann heute ein ernsthaftes Werkzeugset, detaillierte Betriebsanweisungen, Projektkonventionen, Nutzerpräferenzen, aktuellen Zustand und genug umliegenden Kontext tragen, ohne ständig zurückgesetzt zu werden. Das Kontextfenster wurde weniger zu einem kleinen Prompt und mehr zu einem temporären Operationsraum.

Deshalb konnte ein minimales Framework plötzlich mächtiger werden. Wenn das Modell schwach ist, muss das Framework mit starrer Struktur kompensieren. Wenn das Modell stärker wird, kann das Framework dünner werden. Es kann Grenzen, Werkzeuge und Schnittstellen definieren und dann dem Modell mehr kognitive Last überlassen.

OpenClaw erschien nahe an dieser Schwelle. Es löste nicht jedes Problem. Es zeigte, dass die Schwelle überschritten war.

Ein Agent ist eine Umgebung

Ein KI-Agent ist nicht einfach ein Chatbot mit besserem Prompt.

Ein Chatbot antwortet. Ein Agent wird in eine Umgebung gesetzt, in der er Werkzeuge benutzen, Kontext prüfen, Anweisungen behalten, andere Systeme aufrufen und über mehrere Schritte hinweg auf ein Ziel hinarbeiten kann. Das Modell ist nur ein Teil dieser Anordnung.

Die Umgebung ist mindestens so wichtig wie das Modell. Welche Dateien darf der Agent lesen? Welche Befehle darf er ausführen? Welche Zugangsdaten hält er? Über welche Kanäle darf er sprechen? Welcher Speicher folgt ihm zwischen Sessions? Was weiß er über den Nutzer? Was darf er ändern, ohne zu fragen? Was muss außerhalb seiner Reichweite bleiben?

Diese Fragen sind nicht zweitrangig. Sie definieren den Agenten.

OpenClaw machte das auf eine saubere Weise sichtbar. Es behandelte Agenten weniger wie magische Persönlichkeiten und mehr wie operative Einheiten, geformt durch Prompts, Werkzeuge, Kanäle und Kontext. Hermes, das System, das ich heute nutze, führt dieselbe Lektion mit saubereren Grenzen weiter: explizite Werkzeuge, Skills, Profile, geplante Jobs, Speicher und Orchestrierung. Weniger Mythologie. Mehr Umgebung.

Hier wird das agentische Zeitalter konkreter. Die nächste Phase von KI wird nicht nur ein Wettbewerb zwischen Modellanbietern sein. Es wird auch ein Wettbewerb zwischen Umgebungen sein. Wer die Runtime, die Werkzeuge, den Speicher, die Berechtigungen und den Datenpfad besitzt, besitzt einen großen Teil der praktischen Agency.

Souveränität ist eine technische Eigenschaft

Souveränität klingt abstrakt, bis ein Agent deine Dateien berührt.

Sobald ein Agent Dokumente lesen, Code verändern, Zugangsdaten verwalten, Logs inspizieren, Gespräche zusammenfassen oder über deine Accounts handeln kann, ist Datenbesitz kein Slogan mehr. Er wird zu einer Architekturfrage.

Es gibt Abstufungen.

Ein gehosteter SaaS-Agent ist die einfachste Version. Die Oberfläche ist poliert, das Setup minimal, und der Anbieter trägt den operativen Aufwand. Aber der Anbieter kontrolliert auch die Runtime, speichert die Logs, definiert die Werkzeuggrenzen und entscheidet über die Produktoberfläche. Du benutzt die Umgebung eines anderen.

Ein privater Server oder eine VM gibt dir mehr Kontrolle. Die Dateien liegen in deinem Raum. Die Werkzeuge laufen unter deinen Regeln. Du kannst Zugangsdaten isolieren, Logs prüfen, entscheiden, was der Agent berühren darf, und das System um deine eigene Arbeit herum formen. Das ist bereits eine andere Beziehung.

Aber eine private VM macht einen Agenten nicht privat, wenn der Verstand des Agenten noch immer woanders lebt.

Wenn jeder wichtige Modellaufruf an eine Cloud-API geht, dann reicht die Datenschutzgrenze weiterhin nach außen. Die lokale Runtime mag dir gehören, aber der Denkprozess, die Prompts, der Kontext und die Ausgaben laufen trotzdem durch ein anderes System. Das kann akzeptabel sein. Oft ist es das. Aber es sollte eine bewusste Entscheidung sein, kein Missverständnis.

Die tiefste Version ist lokale oder offline laufende Agency: Runtime, Werkzeuge und Modell auf Hardware, die du kontrollierst. Open-Source-Modelle machen das möglich. Bessere Consumer-Hardware und kleine spezialisierte Modelle werden es praktischer machen. Ein vollständig offline laufender Agent wird nicht immer so leistungsfähig sein wie das beste Cloud-Modell. Er kann langsamer sein, in der Einrichtung teurer und begrenzter. Aber das Datenschutzprofil ist radikal anders.

Nicht jeder braucht für jede Aufgabe vollständige lokale Agency. Es geht nicht um Reinheit. Es geht darum zu wissen, wo die Grenze liegt.

Wer den Stack versteht, kann entscheiden, wann Bequemlichkeit die Datenexposition wert ist und wann nicht. Wer den Stack nicht versteht, kann glauben, das System zu besitzen, weil es auf dem eigenen Server läuft, während der sensibelste Teil des Prozesses die Maschine weiterhin verlässt.

Das agentische Zeitalter braucht diese Unterscheidung.

Der Assistent ist nicht die Grenze

Agenten sind zugänglich, weil sie wie Assistenten wirken.

Das ist ein Teil ihrer Kraft. Man kann sie bitten, ein Repository zu inspizieren, einen Fehler zu erklären, eine Datei zu bearbeiten, Optionen zu vergleichen, einen Service zu deployen oder ein verwirrendes System zusammenzufassen. Die Oberfläche fühlt sich menschlich genug an, dass Delegation natürlich wird.

In dieser Freundlichkeit liegt eine Gefahr. Die Assistentenoberfläche kann operative Macht verdecken. Shell-Zugriff ist kein Chat-Feature. Browser-Zugriff ist kein Chat-Feature. Zugangsdaten, Deployment-Rechte, Dateisystemzugriff, Speicher und externe Nachrichten sind keine Persönlichkeitseigenschaften. Sie sind Sicherheitsgrenzen.

Anthropomorphisierung ist als Nutzeroberfläche nützlich. Als Sicherheitsmodell ist sie furchtbar.

Ein Agent braucht keine böswillige Absicht, um Schaden anzurichten. Er kann etwas missverstehen. Er kann zu weit verallgemeinern. Er kann der falschen Anweisung aus der falschen Quelle folgen. Er kann ein Geheimnis preisgeben, weil der Prompt das Geheimnis relevant wirken lässt. Er kann eine Datei überschreiben, einen Befehl ausführen, einem Dokument vertrauen oder eine Nachricht senden unter Bedingungen, die ein menschlicher Operator hinterfragt hätte.

Je fähiger der Agent wird, desto weniger akzeptabel ist es, ihn wie einen harmlosen Gesprächspartner zu behandeln.

Prompt Injection ist Architektur

Prompt Injection wird oft wie ein Trick beschrieben. Jemand versteckt feindliche Anweisungen in einer Webseite, einem Dokument, einer E-Mail, einem Issue oder einer Logzeile. Der Agent liest sie und behandelt die feindliche Anweisung so, als gehöre sie zum Nutzer.

Diese Beschreibung stimmt, aber sie ist zu klein.

Prompt Injection wird zu operativem Risiko, sobald Agenten Werkzeuge haben. Jeder nicht vertrauenswürdige Inhalt, der in den Kontext gelangt, kann zu anweisungsförmigem Input werden. Eine Webseite kann versuchen, einen Browsing-Agenten umzulenken. Ein README kann versuchen, einen Coding-Agenten zu manipulieren. Ein Ticket kann versuchen, Umgebungsvariablen abfließen zu lassen. Eine Logzeile kann versuchen, einen Incident-Response-Agenten zu steuern.

Die Antwort ist nicht Panik. Die Antwort ist Architektur.

Agenten brauchen Isolation. Sie brauchen das Prinzip geringster Rechte. Sie brauchen Werkzeuggrenzen, Audit Trails, Freigabeschritte, reversible Aktionen und Möglichkeiten zu erkennen, wenn der Kontext kontaminiert wurde. Sensible Daten sollten nicht verfügbar sein, nur weil es bequem wäre. Gefährliche Aktionen sollten nicht nur einen flüssigen Satz von der Ausführung entfernt sein.

Auch die offensive Seite wird sich verändern. Angreifer mussten früher Skripte, Payloads und Exploit-Ketten von Hand schreiben. Jetzt kann ein kompromittiertes System zum Arbeitsraum eines Agenten werden, der von innen heraus erkundet, sich anpasst, eigenen Code schreibt, lokale Konfiguration liest und nach einem Weg weiter sucht. Das ist eine andere Art von Automatisierung.

Die defensive Seite verändert sich im selben Moment. Agenten können Logs beobachten, Konfigurationen vergleichen, Änderungen prüfen, Anomalien bemerken, Alarme erklären und bei der Reaktion helfen. Sie können aktive Sicherheitsassistenten werden, gerade für kleine Teams und Einzelpersonen, die sich kein vollständiges Operations-Team leisten können.

Dieselbe Fähigkeit schneidet in beide Richtungen. Sicherheit kann nicht später als dekorative Schicht hinzugefügt werden. Sie muss die Umgebung von Anfang an formen.

Geliehene Kompetenz bleibt geliehen

Das Versprechen von Agenten ist real: Sie lassen Menschen Dinge tun, die sie allein nicht tun könnten.

Jemand ohne jahrelange Softwareerfahrung kann einen Agenten bitten, ein kleines Tool zu bauen, einen Workflow zu automatisieren, einen Server zu inspizieren oder Dienste zu verbinden. Das ist eine echte Erweiterung praktischer Handlungsfähigkeit. Die Distanz zwischen Absicht und Umsetzung wird kleiner.

Aber Vertrauen kann schneller kommen als Urteilskraft.

Ein Agent kann etwas erzeugen, das an der Oberfläche funktioniert, während das darunterliegende System brüchig ist. Er kann einen Service mit unklaren Grenzen, schwacher Authentifizierung, offengelegten Secrets, fehlender Backup-Strategie, chaotischen Abhängigkeiten, schlechter Fehlerbehandlung und keinem Wartungsplan bauen. Für einen nichttechnischen Nutzer kann es fertig aussehen. Für einen Entwickler kann es aussehen wie ein zukünftiger Incident mit schöner Oberfläche.

Das bedeutet nicht, dass nur Experten Agenten nutzen sollten. Das Gegenteil stimmt. Agenten sind zu nützlich, um sie nur Experten zu überlassen. Aber Menschen brauchen geführten Besitz. Sie brauchen genug Verständnis der Umgebung, um zu wissen, was der Agent berühren darf, was er nicht berühren sollte, welche Daten die Maschine verlassen und welche Fehler wirklich zählen.

Geliehene Kompetenz ist trotzdem nützlich. Man muss nur erkennen, dass sie geliehen ist.

Mind Making Labs und geführter Besitz

Das ist der praktische Grund hinter Mind Making Labs.

Ich möchte Menschen nicht noch ein weiteres undurchsichtiges KI-Abo verkaufen. Ich möchte ihnen helfen, agentische Umgebungen zu entwerfen und einzurichten, die sie wirklich verstehen und besitzen können: wo der Agent läuft, welche Werkzeuge er benutzen darf, mit welchem Modell er spricht, welche Daten die Maschine verlassen, was lokal bleibt und wie Berechtigungen begrenzt werden.

Die Arbeit ist Setup-Service und technische Beratung rund um eine konkrete Umgebung, kein Kurs über Agenten. Das Lernen entsteht, weil das System sichtbar wird. Wenn jemand die Form des eigenen agentischen Setups versteht, kann er es mit mehr Freiheit und weniger Aberglauben nutzen.

Für manche Menschen bedeutet das einen privaten Agenten in einer VM mit sauber begrenztem Zugriff auf Werkzeuge und Dateien. Für andere bedeutet es, ein lokales Modell auf eigener Hardware zu erkunden. Für andere bedeutet es ein hybrides Setup: Cloud-Modelle für Arbeit mit geringem Risiko, lokale oder isolierte Systeme für sensible Kontexte.

Die richtige Antwort hängt von der Person, der Arbeit, der Hardware, den Daten und dem Risiko ab. Wichtig ist, diese Entscheidungen bewusst zu treffen.

Wenn du Hilfe beim Einrichten deiner eigenen agentischen Umgebung möchtest, biete ich diese Arbeit über Mind Making Labs an.

Das agentische Zeitalter braucht Operatoren

OpenClaw war früh, rau und unvollkommen. Genau deshalb war es wichtig. Es zeigte eine Form, bevor diese Form poliert war.

Die nächste Welle wird spezialisiertere Frameworks bringen. Manche werden sich auf Coding konzentrieren. Manche auf Forschung. Manche auf Operations, Sicherheit, persönliches Wissen, Geschäftsprozesse oder lokale Automatisierung. Viele werden verschwinden. Einige werden zu Infrastruktur, die Menschen irgendwann nicht mehr bemerken.

Die wichtige Frage ist nicht nur, welches Framework gewinnt.

Die schwierigere Frage ist, welche Beziehung Menschen zu diesen Systemen haben werden. Werden Agenten eine weitere gemietete Oberfläche in der Cloud eines anderen, optimiert für Engagement und Lock-in? Oder lernen Menschen und kleine Organisationen, ihre eigenen intelligenten Werkzeuge mit klaren Grenzen, lokalem Wissen und echter Kontrolle zu betreiben?

Das agentische Zeitalter wird nicht nur durch klügere Modelle definiert. Es wird durch die Umgebungen definiert, die um sie herum entstehen: die Werkzeuge, die sie berühren dürfen, die Daten, die sie tragen, die Berechtigungen, die sie halten, den Speicher, den sie behalten, und die Menschen, die genug verstehen, um verantwortlich zu bleiben.

Das ist der Teil, der mich am meisten interessiert.

Keine Agenten als magische Angestellte. Keine Agenten als Maskottchen der Automatisierung. Agenten als Instrumente menschlicher Agency, wenn wir sie so bauen.