Bedeutet diese aktuelle Welle der kollektiven Umorientierung bei "persönlichen Agenten", dass die zugrundeliegende Infrastruktur der gesamten Branche ausgetauscht wurde?

Am 8. September veröffentlichte Meta den persönlichen intelligenten Agenten Muse. 12 Tage nach seiner Markteinführung verzeichnete er etwa 2,8 Millionen Downloads – ein schnelleres Wachstum als die mobile Version von ChatGPT in ihren Anfangsjahren.

Die anfängliche Begeisterung war kaum verflogen, als die Probleme begannen. Mitte September veröffentlichten das Sicherheitsunternehmen Surfshark und eine Gruppe technischer Nutzer Berichte, wonach das Berechtigungssystem „Sentinel“ von Muse weitgehend ausgefallen sei. Muse habe sogar die Sicherheitsfunktion „Vollständiger Festplattenzugriff“ von macOS umgangen und lokale iMessage-Chatverläufe des Nutzers ausgelesen. Nur wenige Tage später blockierten Einzelhandels- und SaaS-Unternehmen wie Amazon den automatisierten Datenverkehr von Muse in ihren Firewalls.

Die Kapitalbranche ließ sich davon aber keineswegs abschrecken. Ende September erhielt Instinct, ein Unternehmen mit nur 14 Mitarbeitern, eine Finanzierung von 1 Milliarde US-Dollar, was seine Bewertung auf über 10 Milliarden US-Dollar hob. Zum Monatsende erschienen nacheinander Cue von Manus und dots von OpenAI.

Die gemeinsame Erzählung in der Community um diese neue Welle von Agent-Produkten formte sich rasch zu der Aussage: „Agenten entwickeln sich von der Fokussierung auf Aufgaben hin zur Fokussierung auf den Menschen“.

Ist das aber schon die ganze Geschichte?

Schauen wir zurück: Bereits im August hat Grok Bot, der von der Fusion von xAI und Cursor zu SpaceXAI hervorging, das Licht der Welt erblickt. Im Unternehmen wird er hauptsächlich für Vertriebsaußendienst, Betriebsunterstützung und Fehlerbehebung eingesetzt – keineswegs ein „persönlicher“ Agent. Am 15. September wurde der Arbeitsassistent Doubao im Rahmen der Veröffentlichung von Feishu 8.0 vorgestellt. Er dient dem gesamten Team, durchsucht selbstständig Chatgruppen und entscheidet, ob er in einer Situation unterstützen soll.

Diese Agenten haben völlig unterschiedliche Zielgruppen, aber ihre Fähigkeiten entwickeln sich offenbar in die gleiche Richtung: Sie sind ständig online, merken sich fortlaufend den Kontext, suchen selbstständig nach Aufgaben und erhalten immer umfangreichere Berechtigungen.

Daraus stellt sich die Frage: Wenn die „Ausrichtung auf den Menschen“ nicht die gesamte Erklärung für diese neue Welle von Agent-Produkten ist, welche Art von Wandel treibt sie dann wirklich voran?

Um diese Frage zu beantworten, müssen wir zu dem „Hummer“ zu Beginn dieses Jahres zurückkehren.

Die Weiterentwicklung von Harness bedeutet, dass der Mensch die Kontrolle schrittweise abgibt

Wenn wir die diesjährigen Agent-Produkte danach ordnen, „wie viel der Mensch noch steuern muss“, ergibt sich ein eindeutiges Spektrum.

Ganz links stehen Produktionstools wie Claude Code und Codex. Entwickler prüfen jede Änderung (diff) und genehmigen jeden Befehl – jeder Schritt des Agenten läuft unter direkter Aufsicht des Menschen. Das ergibt sich aus der Produktpositionierung: In realen Geschäftsprozessen hat die präzise Steuerung immer höchste Priorität.

Ein Schritt weiter rechts steht OpenClaw. Anfang dieses Jahres ließ es viele Nutzer erstmals erleben, wie es sich anfühlt, einen „Agenten zu pflegen“. Es läuft dauerhaft auf deinem Computer, chattet mit dir auf WhatsApp und Telegram, wacht per Heartbeat in regelmäßigen Abständen auf, um nach neuen Aufgaben zu suchen, und speichert deine Identität in den Dateien USER.md und MEMORY.md.

Aber die Pflege ist wirklich aufwändig: Du musst die Bereitstellung selbst durchführen, Fähigkeiten manuell installieren, und das System speichert Erinnerungen nur dann, wenn der Kontext fast voll ist.

Später sank die Beliebtheit in der Community – im Grunde genommen, weil der Wartungsaufwand zu hoch war.

Noch ein Schritt weiter rechts steht Hermes. Es erschien Ende Februar und stand mehrere Wochen lang an der Spitze von GitHub Trending. Wenn man seine Funktionsliste Punkt für Punkt vergleicht, unterscheidet es sich kaum von OpenClaw. Aber wer diese Funktionen steuert, ist anders.

Immer wenn eine Aufgabe mehr als 5 Mal Tools aufruft oder vom Nutzer korrigiert wird, speichert Hermes diesen Ablauf stillschweigend als neue Fähigkeit. Nach etwa 15 Gesprächsrunden erhält der Agent automatisch eine Reflexionsanweisung, um zu prüfen, welche Informationen es wert sind, gespeichert zu werden.

Dieser Weg, „Entscheidungen für dich zu treffen“, wurde schnell zum Konsens. Im April ergänzte OpenClaw zwei Funktionen nacheinander: Zuerst Dreaming für die Offline-Speicherung von Erinnerungen, dann Active Memory, das vor jeder Antwort gezielt auf gespeicherte Erinnerungen zugreift.

Aber Hermes beseitigt diese Entscheidungen nicht – es wandelt sie nur in feste Regeln um. Zum Beispiel 5 Tool-Aufrufe, 15 Gesprächsrunden, ein Komprimierungsschwellenwert von 85 % und eine Schwarze Liste für gefährliche Befehle werden alle im Voraus vom Entwicklungsteam festgelegt.

Die Kerninnovation der aktuellen Agent-Generation liegt im nächsten Schritt auf diesem Spektrum. Die Komplexität verlagert sich erneut – diesmal in ein dauerhaft laufendes System und ein Modell, das zunehmend eigenständige Entscheidungen treffen kann.

Dieses dauerhaft laufende System ist ein „always-on“-Agent. Die Existenz des Agenten hängt nicht mehr von einem einzelnen Gespräch oder einem eingeschalteten Computer ab. Wenn du deinen Computer zuklappst und schlafen gehst, läuft er weiter, merkt sich den aktuellen Stand der Dinge, wird bei neuen Nachrichten geweckt und setzt die Arbeit fort.

Nur wenn er ständig verfügbar ist, kannst du ihm Aufgaben anvertrauen.

Du wirst einwenden, dass es diese Funktionalität doch schon beim „Hummer“ gab. Tatsächlich kann OpenClaw auch dauerhaft laufen – aber wenn der Computer zugeklappt wird, der Prozess abstürzt oder der Kontext überläuft, bricht die Verbindung ab.

Er ist nicht stabil. Ein Agent, der nur zu festgelegten Zeiten aufwacht, ständig deine Genehmigung braucht und nach längerer Laufzeit den Überblick verliert, verursacht zu hohe Wartungskosten für dich.

Damit er wirklich ständig verfügbar ist, müssen drei Probleme gelöst werden: Ob er zur richtigen Zeit aufwacht, ob er dich nicht unnötig stört und ob er sich Dinge merken kann – also Proaktivität, Berechtigungen und Gedächtnis.

Die aktuelle Agent-Generation hat bei diesen drei Punkten konkrete Fortschritte gemacht. Das ist die unverzichtbare Grundlage für jeden Assistenten und jeden Agenten, der mehr Arbeit für dich übernehmen soll.

Danach erfolgt die Differenzierung hauptsächlich im Kontext. Wenn du einen Always-on-Agenten an die Chatgruppen und Arbeitssoftware eines Teams anschließt, oder an den Kalender, die Chats und die Rechnungen einer Person, müssen diese drei Funktionen entsprechend angepasst werden. Im Büroalltag erwarten wir beispielsweise, dass der Agent proaktiv für das Team handelt – also überwacht er den Projektfortschritt und Aufgaben, die niemand übernommen hat. Wenn er für eine Privatperson arbeitet, achtet er hingegen auf Anmeldefristen für die Kinder.

Dieser Schritt kann als kontextspezifische Produktanpassung bezeichnet werden: Für Teams wird er zum Kollegen, für Privatpersonen zum Hausmeister.

Wenn wir diesem Spektrum folgen, werden in Zukunft dauerhaft online verfügbare Agenten, die Kontext und Berechtigungen verwalten und Aufgaben eigenständig vorantreiben, höchstwahrscheinlich zum Standard von Agent-Produkten werden. Akteure wie OpenAI, Meta und xAI, die an dieser Entwicklung teilnehmen, haben bereits ähnliche Lösungen für die hierarchische Speicherung von Erinnerungen und die dauerhafte Betriebsarchitektur gefunden.

Wie wird der Zustand „ständig verfügbar“ eigentlich erreicht? Die umfassendste Erklärung dafür liefert ausgerechnet der am wenigsten „persönliche“ Agent, Grok Bot.

Grok Bot: Die Funktionalität „ständig online“ wird solide umgesetzt

Am 11. August veröffentlichte SpaceXAI die Beta-Version von Grok Bot. Ursprünglich war es nur ein interner Prototyp, der sich später in Vertriebs-, Betriebs- und Technikteams verbreitete.

Die Nutzung ist einfach: Du erstellst mehrere Bots mit Namen und klarer Zuständigkeit und weist ihnen Aufgaben zu, als ob du Nachrichten an Kollegen schickst. Jeder Bot verfügt über einen eigenen Cloud-Computer mit Browser, Dateisystem und Terminal – auch Websites ohne API oder MCP-Anbindung kann er direkt aufrufen und bedienen.

Wenn du deinen Computer zuklappst, arbeitet er weiter und kontaktiert dich nur dann, wenn deine Entscheidung erforderlich ist. Du kannst ihm auch eine Arbeitsablauf vorführen – danach fasst er den Prozess als neue Fähigkeit zusammen und führt sie später selbstständig zu festgelegten Zeiten aus.

Mehrere Bots können sich auch gegenseitig Nachrichten senden und werden von einem „Stabschef“-Bot zentral gesteuert.

Grok Bot ist kein persönlicher Agent. Er folgt dem Weg von OpenClaw: Er kümmert sich nicht zuerst um die Zielgruppe, sondern macht die Funktionalität „ständig online“ selbst zuverlässig.

Vor kurzem erklärte Lee Robinson von SpaceXAI im Kurs CS146S der Stanford University die gesamte Architektur von Grok Bot detailliert.

Wenn man seine Ausführungen mit OpenClaw vergleicht, erkennt man die Verbesserungen: Fast alle Fähigkeiten von Grok Bot gab es bereits in der OpenClaw-Ära, aber sie waren sehr unausgereift.

Diese Unausgereiftheit zeigt sich vor allem in vier Punkten.

Engpass 1: Starrgeführtes Aufwachen

Die Dauerverfügbarkeit von OpenClaw basiert auf Heartbeat: Der Prozess läuft ständig und wacht in regelmäßigen Abständen auf, um nach neuen Aufgaben zu suchen.

Diese Methode hat zwei Nachteile: Erstens wacht er zur falschen Zeit. Wenn du dringend Hilfe brauchst, muss er noch auf den nächsten Heartbeat warten. Wenn keine Aufgaben anstehen, wacht er trotzdem, läuft leer und verschwendet Token. Zweitens ist er an einen einzelnen Computer und einen einzelnen Prozess gebunden. Wenn der Computer zugeklappt oder der Prozess abgestürzt ist, ist er nicht mehr erreichbar. Nach einem Neustart lässt sich der vorherige Arbeitsstand kaum nachvollziehen.

Bei Grok Bot hingegen wacht er nicht zu festen Zeiten auf, sondern bei Ereignissen.

Die meiste Zeit schlafen der Agent und der dazugehörige Cloud-Computer. Ereignisse wie eine Slack-Nachricht, eine E-Mail, der Beginn einer Besprechung oder der Abschluss eines mehrtägigen Hintergrundprozesses dienen als Wecker. Nach dem Aufwachen lädt er seinen Zustand aus der Datenbank. Wenn er Internetzugriff braucht, weckt er zusätzlich den Cloud-Computer. Nach Abschluss der Aufgabe gehen beide wieder in den Schlafmodus und speichern Chatverlauf, Erinnerungen und geplante Aufgaben vollständig in der Datenbank zurück.

Das Aufwachen bei Ereignissen hat aber auch ein Problem: Es gibt zu viele Ereignisse. Wenn dich jemand @erwähnt, anruft oder eine Besprechung beginnt, strömen alle Signale gleichzeitig ein – der Agent würde sonst leicht von Nachrichten überflutet und überfordert.

Deshalb durchlaufen alle diese Signale bei Grok Bot zuerst eine Routing-Funktion: Doppelte Nachrichten werden entfernt, und die Ereignisse werden nach Priorität sortiert. Eine Nachricht, die du persönlich sendest, hat Vorrang und unterbricht die laufende Arbeit. Chatgruppen und Hintergrundaufgaben werden in eine Warteschlange gestellt, und mehrere aufeinanderfolgende Ereignisse werden zu einem einzigen Verarbeitungsschritt zusammengefasst.

Nach jedem Aufwachen und Abschluss der Aufgabe prüft er auch: Ist es notwendig, den Besitzer zu stören? Wenn ein Kollege nach jedem kleinen Fortschritt eine Meldung sendet, wird das schnell lästig. Die meisten Angelegenheiten reichen aus, einmal am Tag abgestimmt zu werden.

Heartbeat ist ein Wecker, Ereignisse sind eine Türklingel. Erst wenn der Agent von „zeitgesteuertem Aufwachen“ zu „ereignisgesteuertem Aufwachen“ wechselt, wird er von einem laufenden Prozess zu einem Assistenten, der immer verfügbar ist und dich nicht stört.

Engpass 2: Häufige Abstürze, schwierige Zustandswiederherstellung

Das Wesen von „Always-on“ ist, dass der Zustand dauerhaft erhalten bleibt und der Agent nach dem Aufwachen sofort die Arbeit fortsetzen kann.

Der Zustand muss stabil sein. Eines der Probleme des „Hummers“ war seine mangelnde Stabilität: Er läuft auf deinem lokalen Computer. Wenn der Computer abstürzt, gehen nach dem Neustart Informationen verloren, und die vollständige Wiederherstellung dauert sehr lange.

Deshalb läuft der Zyklus von Grok Bot auf dem Server, nicht auf seinem eigenen Cloud-Computer. Der Server nutzt eine Firecracker-Virtuelle Maschine, die jederzeit Schnappschüsse erstellen, herunterfahren und in ihrem ursprünglichen Zustand wiederherstellen kann. Bei einem Defekt kann sie einfach neu erstellt werden. Da der Zustand nicht auf der VM gespeichert ist, ist die VM nur ein Werkzeug – auch bei einem Austausch erleidet der Agent keinerlei Schaden. Selbst wenn dringende Sicherheitsupdates für die VM installiert werden müssen, muss der Agent nicht angehalten werden.

Um die Wiederherstellung nach Abstürzen zu beschleunigen, wurde zusätzlich ein dauerhafter Workflow (durable workflow) implementiert. Bei normalen Aufgabenwarteschlangen stürzt der Server beispielsweise im dritten Schritt ab – nach dem Neustart muss der Prozess vom ersten Schritt an wiederholt werden, was dazu führen kann, dass dieselbe E-Mail zweimal verschickt oder eine Bestellung zweimal aufgegeben wird.