OpenClaw: 5 Workflows, die jetzt möglich sind

Stand der Fakten: 2. September 2026

Kurzantwort: OpenClaw kann heute Recherche, laufende Arbeitskontexte, Browseraufgaben und verteilte Ausführung zu überprüfbaren Abläufen verbinden. Der eigentliche Fortschritt ist nicht „mehr Autonomie“, sondern bessere Arbeitsteilung: Der Agent bereitet vor und dokumentiert Grenzen; der Nutzer legt fest, an welchen Haltepunkten ein Mensch entscheidet.

Montagmorgen, 8:10 Uhr: Drei Quellen widersprechen sich, im eingeloggten Kundenportal fehlen zwei Kennzahlen, und der Report muss bis Mittag zur Bereichsleitung. Gefragt ist kein weiterer Fließtext, sondern ein belastbares Arbeitsartefakt: die Quellenlage zu jeder strittigen Aussage, markierte Abweichungen im Portal und eine Liste der Entscheidungen, die noch offen sind. Bleibt unklar, welche Zahl gilt oder welche Daten fehlen, kann der fertige Report vollständig wirken, obwohl seine Entscheidungsbasis löchrig ist.

OpenClaw 2026.8.1 markierte als „OpenClaw 2.0“ den größeren Produktsprung. OpenClaw 2026.8.2 ist der aktuelle stabile Stand, der diese Richtung ergänzt und stabilisiert.

1. Recherche parallelisieren: von offenen Fragen zur Entscheidungsvorlage

OpenClaw kann eine breite Recherche in getrennte, gleichzeitig bearbeitbare Fragen zerlegen und die Ergebnisse anschließend als Quellenmatrix, Widerspruchsliste und Entscheidungsvorlage zusammenführen. Das ist vor allem dann wertvoll, wenn nicht die Menge der Links, sondern die Vergleichbarkeit der Belege das Problem ist.

Vor der Einführung eines Analysewerkzeugs brauchst du belastbare Antworten zu Funktionsumfang, Datenschutz, Kosten, Integrationen und Grenzen. In einem einzigen Chatverlauf kann ein früher, schwacher Fund unbemerkt die spätere Bewertung prägen.

So läuft der Workflow:

1. Du formulierst die Entscheidung und fünf prüfbare Teilfragen, jeweils mit gewünschtem Stichtag und bevorzugten Primärquellen.
2. Für jede Teilfrage startet eine eigene Hintergrund-Session. Eine sucht nicht „alles“, sondern liefert Claims, Fundstellen, Quellenqualität und offene Punkte in demselben Schema.
3. Eine separate Prüfrunde sucht gezielt nach Gegenbelegen: Stimmen Preise und Daten noch? Widersprechen sich Dokumentation, Produktseite und Release Notes? Ist eine Aussage bestätigt oder nur plausibel?
4. Die Hauptsession übernimmt nicht einfach die längsten Antworten. Sie baut eine Matrix aus Aussage, Beleg, Aktualität, Widerspruch und Entscheidungsauswirkung.
5. Du erhältst eine einseitige Entscheidungsvorlage: Was wissen wir, was bleibt unklar und welche Unsicherheit würde die Entscheidung verändern?

Das Ergebnis ist ein prüfbarer Arbeitsstand statt eines Linkfriedhofs. Voraussetzung sind abgegrenzte Fragen, Quellenzugriff und ein verbindliches Ausgabeformat. Auch die Session-Reichweite muss passen: Fehlt eine gültige Sichtbarkeitseinstellung, gilt derzeit agent; vorhandene gültige Werte bleiben bestehen. In gemeinsam genutzten Umgebungen ist vorab zu klären, welche Sessions der Lauf lesen darf.

Konfiguriere als menschlichen Haltepunkt, dass der Lauf vor der Empfehlung mit der Evidenzmatrix endet. OpenClaw darf Belege sortieren und Widersprüche sichtbar machen; Risiko, Kosten und strategische Bedeutung gewichtet der Verantwortliche. Vorher recherchiert eine Person nacheinander und rekonstruiert später den Zusammenhang. Nachher sieht sie in einer gemeinsamen Evidenzstruktur sofort, welche offene Frage die Entscheidung aufhält.

2. Home als Leitstand: offene Fragen priorisieren und den nächsten Prüfschritt wählen

Home kann neben einer laufenden Aufgabe zum Leitstand werden: Der prüf- und entfernbare Snapshot zeigt Seiten-, Session-, Agent-, Workspace- und sichtbare Datei-Metadaten sowie optional markierten Text. Mit einem passenden Prompt lässt sich daraus der nächste überprüfbare Schritt ableiten, ohne eine festgefahrene Session neu zu erklären.

Ein Entwurf ist fast fertig, aber drei Punkte bleiben unsicher; Notizen, Quellen und verworfene Ansätze liegen bereits im Verlauf. Beim Wechsel in einen neuen Chat wird leicht zu viel kopiert oder die entscheidende Passage vergessen.

So läuft der Workflow:

1. Du markierst optional die strittige Passage und öffnest Home im Dock neben der aktuellen Arbeit.
2. Vor dem Senden prüfst du den sichtbaren Snapshot. Enthält er unerwünschte Metadaten, entfernst du den gesamten Work Context; markierten Text fügst du separat und gezielt hinzu.
3. Bitte Home per Prompt, den Snapshot in „belegt“, „offen“ und „entscheidungsrelevant“ zu sortieren und genau einen nächsten Test vorzuschlagen.
4. Du wählst den Test, etwa „Originalquelle öffnen“, „Zahl gegenrechnen“ oder „Gegenbeispiel suchen“, und startest ihn als abgegrenzte Session.
5. Anschließend übernimmst du die Prüfnotiz mit Fundstelle und Konsequenz bewusst in die Ursprungssession.

Das Ergebnis ist eine priorisierte Fragenliste plus ein nächster Prüfschritt. Voraussetzung ist ein so kleiner Snapshot, dass der Engpass sichtbar bleibt. Der Snapshot selbst überträgt die darin angezeigten Informationen; welche weiteren Daten Home erreichen kann, bestimmen zusätzlich die Tool- und Session-Rechte.

Lege als Workflow-Regel fest, dass Home nur eine Prüfnotiz vorbereitet und der Verantwortliche jede Richtungsänderung auslöst. Er entscheidet, ob ein Abschnitt gestrichen, eine These umgebaut oder weitere Daten erhoben werden. Vorher bedeutete eine Blockade oft Kontextwechsel und erneute Erklärung. Nachher bleibt die Arbeit sichtbar, während die Unsicherheit als eigene, überprüfbare Aufgabe behandelt wird.

3. Ein eingeloggtes Portal bearbeiten: Tabs begrenzen, Bericht abgleichen, Export freigeben

OpenClaw kann in einem bereits eingerichteten Browserpfad Informationen aus einem eingeloggten Portal mit einer Vorgabe abgleichen und einen Bericht oder Export bis zur menschlichen Bestätigung vorbereiten. Der sinnvolle Einsatz ist nicht „mach irgendetwas in meinem Browser“, sondern ein eng begrenzter Auftrag in ausdrücklich freigegebenen Tabs.

Beispiel: Jeden Monat müssen zwölf Einträge in einem Partnerportal ohne passende API gegen eine interne Liste geprüft werden. Manuelles Klicken ist langsam, Zugriff auf das gesamte Browserfenster unnötig weit.

So läuft der Workflow:

1. Du richtest auf einem unterstützten macOS- oder Linux-Host den Browserpfad ein und gibst nur die benötigten Portal-Tabs frei. Neue automatische Chrome-Pairings starten mit „All tabs“; für diesen Ablauf stellst du aktiv auf „Selected tabs“ um.

2. Beim Standalone Direct Loopback müssen automatisches lokales Setup, Native Host und kompatible Erweiterung zusammenpassen. Das Pairing zeigt auf den lokalen Extension-Endpunkt:

   ws://127.0.0.1:<port>/extension

3. OpenClaw liest die zwölf Datensätze, gleicht definierte Felder ab und protokolliert Abweichungen. Unklare Zustände landen in einer Ausnahmeliste, statt durch Schätzen „repariert“ zu werden.

4. Der Agent bereitet einen Export oder einen abgeglichenen Bericht vor und nennt Datensatz, Abweichung, Quelle und vorgeschlagene Aktion.

5. Konfiguriere den Lauf so, dass er mit dem Entwurf endet. Download, Speichern oder Weitergabe löst du nach der Sichtprüfung in einem separaten menschlichen Schritt aus.

Das Ergebnis ist ein kontrollierbarer Entwurf mit Ausnahmeliste. Nötig sind ein freigegebener Browserpfad auf dem gekoppelten Host, eine kompatible Erweiterung und eine stabile Sitzung. Wake-up-Unterstützung gilt nicht für jeden Extension-Build; Linux- und macOS-Companions sind Zugänge, keine Sicherheitsgrenze.

Richte den menschlichen Haltepunkt ausdrücklich vor jeder irreversiblen oder extern sichtbaren Aktion ein; OpenClaw setzt ihn nicht automatisch. Vorher klickt jemand alle Zeilen durch und bemerkt Abweichungen nebenbei. Nachher konzentriert sich die Person auf die wenigen Fälle, bei denen Kontext, Berechtigung oder wirtschaftliche Wirkung eine echte Entscheidung verlangen.

4. Arbeit passend platzieren: lokal, in der Cloud oder auf einem gekoppelten Gerät

Mit OpenClaw kannst du getrennte Sessions bewusst auf Gateway, Cloud-Worker oder gekoppeltem Gerät platzieren und ihre Übergaben orchestrieren. Das ist keine automatische, nahtlose Verteilung: Der Gewinn entsteht durch eine bewusste Entscheidung über Ort, Datenübergabe und Ergebnisformat für jeden Schritt.

Bei einem Medienreport können Rohdateien lokal liegen, die Transkription in einen Cloud-Worker passen und die Sichtkontrolle eine Anwendung auf einem gekoppelten Gerät brauchen. Ein einziger Ausführungsort erzeugt unnötige Transfers oder manuelle Übergaben.

So läuft der Workflow:

1. Du zerlegst das Ziel nach Daten- und Werkzeugnähe und entscheidest für jede Teilaufgabe bewusst zwischen Gateway, Cloud-Worker und gekoppeltem Gerät.
2. Für jede Übergabe definierst du, welche Daten weitergegeben werden dürfen. Selektive Weitergabe ist Workflow-Design, keine automatische Datenminimierung.
3. Du startest die rechenintensive Verarbeitung als getrennte Session auf dem Cloud-Worker; ihre Werkzeugrechte dürfen durch den Ortswechsel nicht still erweitert werden.
4. Eine weitere, bewusst platzierte Session übernimmt auf dem gekoppelten Gerät den Teil, der eine dort installierte Anwendung oder einen freigegebenen Browserpfad braucht.
5. Du orchestrierst die Rückgaben in eine führende Session und gibst ein Provenienzformat für Status, Artefakte, Fehler und fehlende Teilresultate vor. OpenClaw erzeugt dieses Protokoll nicht automatisch.

Das Ergebnis ist ein bewusst zusammengesetzter Report mit Herkunft jedes Teilresultats. Nötig sind erreichbare Ausführungsorte, passende Werkzeuge, begrenzte Rechte und definierte Übergaben. Lokal bedeutet nicht automatisch privat: Externe Modell-APIs oder Provider können Inhalte weiterhin erhalten. Datenlokalität muss entlang des gesamten Pfads geprüft werden.

Konfiguriere vor dem Verschieben sensibler Daten und vor einem neuen Ausführungsort einen menschlich ausgelösten Übergabeschritt. Vorher richtet sich der Ablauf nach dem einzigen Rechner, auf dem „alles irgendwie geht“. Nachher wird jeder Schritt bewusst platziert, und der Verantwortliche kann anhand des vorgegebenen Protokolls seine Herkunft prüfen.

5. Einen Wochenreport kontrolliert automatisieren: anstoßen, Abweichungen prüfen, freigeben

OpenClaw kann einen wiederkehrenden Wochenreport zeitgesteuert anstoßen, Abweichungen gegenüber festen Erwartungen hervorheben und eine versandfertige Fassung zur Freigabe vorlegen. Der Zeitplan garantiert dabei nur den Anstoßversuch – nicht, dass der Lauf tatsächlich startet, alle Quellen erreicht oder erfolgreich endet.

Jeden Montag kommen Kennzahlen aus mehreren Systemen zusammen. Gerade im langweiligen Normalfall werden fehlende Werte, geänderte Definitionen oder ausgefallene Connectoren leicht übersehen. Ein sichtbar unvollständiger Bericht ist sicherer als eine automatische Erfolgsmeldung.

So läuft der Workflow:

1. Du definierst feste Quellen, erwartete Felder, Vergleichszeitraum und Schwellenwerte. Außerdem legst du fest, welcher Zustand als „keine Daten“ statt als Null gilt.
2. Ein Zeitplan versucht den Lauf zum vereinbarten Zeitpunkt anzustoßen. Der Scheduler und die Run-Historie machen Start und Abschluss nachvollziehbar; Zwischenstände lässt du im Workflow ausdrücklich melden.
3. Der Lauf sammelt Werte und vergleicht sie mit Vorwoche, Zielkorridor und Datenvollständigkeit.
4. Statt jede Zahl zu kommentieren, erstellt OpenClaw einen Abweichungsbericht: Was hat sich relevant verändert, welche Quelle fehlt und welche Aussage ist deshalb nicht belastbar?
5. Der geplante Lauf endet mit einer vorbereiteten Fassung. Versand, Veröffentlichung oder weitere Aktionen erfolgen separat und werden vom Verantwortlichen ausgelöst.

Das Ergebnis ist ein Wochenreport plus Fehler- und Abweichungsprotokoll. Nötig sind stabile Lesezugriffe, explizite Fehlerzustände und ein Empfänger für Fehlläufe. Bei aufbewahrten Automations-Sessions kann der Fallback agent Same-Agent-Sessions zugänglich machen. Sandboxed Aufrufer bleiben beim Standard spawned auf ihren Spawn-Baum begrenzt; separate Agents sind keine harte Mandantengrenze für Tools, Credentials und Dateien.

Konfiguriere die externe Zustellung außerhalb des geplanten Laufs als menschlich ausgelösten Schritt. Vorher kostet der Normalfall jede Woche dieselbe Aufmerksamkeit, während Ausnahmen leicht untergehen. Nachher prüft ein Mensch vor allem Abweichungen und Ausfälle – und ein fehlgeschlagener Lauf bleibt ein sichtbarer Fehler statt eines still fehlenden Reports.

Der 7-Tage-Test: weiterbauen oder abbrechen?

Teste genau einen risikoarmen Workflow sieben Tage lang, etwa einen rein lesenden Quellenabgleich für einen internen Kurzbericht. Miss drei Dinge: die einmalige Setup-Zeit, die Zahl manueller Korrekturen und wie viele relevante Quellen oder Ausnahmen übersehen wurden. Baue weiter, wenn das Ergebnis nach der Anlaufphase verlässlich Zeit spart und mindestens so vollständig ist wie der bisherige Prozess. Brich den Versuch ab oder gestalte ihn neu, wenn Einrichtung und Korrekturen den manuellen Aufwand übersteigen oder wichtige Ausnahmen schlechter sichtbar werden.

Quellen

• OpenClaw 2026.8.1 („OpenClaw 2.0“) und aktueller stabiler Stand 2026.8.2
• Session-Tools und Sichtbarkeit sowie Konfiguration der Session-Tools
• Cloud-Sessions und Cloud-Worker
• Automationen, Cron-Jobs und Run-Historie
• Chrome-Erweiterung und Standalone Direct Loopback Relay
• Linux-Desktop-Companion
• Modellanbieter, Plugin-Fähigkeiten und MCP-Anbindung
• Zur Einordnung: OpenClaw, Hermes und Grok Bot im Vergleich sowie Prompt Injection und Agenten-Sicherheit

Hinweis

Der Artikel beschreibt dokumentierte Möglichkeiten mit Stand 2. September 2026, keine Funktions- oder Sicherheitsgarantie für jedes Setup. Tatsächliche Fähigkeiten hängen von Plattform, Konfiguration, angebundenen Providern, verfügbaren Werkzeugen und vergebenen Rechten ab; irreversible oder extern sichtbare Aktionen sollten zunächst eine menschliche Freigabe verlangen.