Ich nutze OpenClaw als Grundlage für ein Setup, in dem mehrere Agenten unterschiedliche Aufgaben übernehmen können. OpenClaw verbindet dabei Modelle mit Werkzeugen, Arbeitsverzeichnissen und laufenden Gesprächen. Ein Agent ist hier also nicht einfach ein anderes Modell: Auch seine Anweisungen, sein Kontext und seine verfügbaren Werkzeuge gehören zur Rolle.

Der Einstieg ist main: Dort landen Gespräche, Ideen, Fragen und kleine Arbeiten. Wenn ich eine überschaubare Änderung möchte und der Kontext schon da ist, kann main sie direkt erledigen. Dafür muss nicht erst eine virtuelle Projektleitung ein Meeting einberufen.

Bei zusammenhängenden technischen Projekten kommt builder ins Spiel. Gemeint sind Aufgaben, bei denen mehrere Schritte aufeinander aufbauen: Einen Fehler eingrenzen, eine Änderung umsetzen, passende Tests durchführen und das Ergebnis bewerten. builder koordiniert dieses Paket und kann dafür gezielt Spezialisten einsetzen.

Das ist keine Pflichtstation für jede Aufgabe. main kann beispielsweise eine abgegrenzte Recherche direkt delegieren. Umgekehrt muss builder nicht jede kleine Änderung weiterreichen, wenn er sie mit weniger Gesamtaufwand selbst erledigen kann.

Direkt spreche ich dabei nur mit main und builder, jeweils in eigenen Gesprächen. Die beiden kommunizieren in meinem Setup nicht direkt miteinander: Für ein technisches Projekt spreche ich builder selbst an. Nötigen Kontext aus einem vorherigen Gespräch mit main bringe ich mit. Die übrigen Agenten arbeiten im Hintergrund: main oder builder wählen anhand meiner Delegationsregeln einen passenden Spezialisten, formulieren dessen Auftrag und sammeln das Ergebnis wieder ein. Ich muss die einzelnen Einsätze also nicht von Hand verteilen.

Die wichtigste Frage lautet für mich deshalb nicht: „Welcher Agent könnte das theoretisch auch?“ Sondern: „Wer kann das Ergebnis verantwortlich zu Ende bringen, ohne dass ich unterwegs ein halbes Transkript durchreichen muss?“

Die Rollen sollen vor allem verständlich sein. Ich will ihre Aufgaben auch ohne Organigramm erklären können.

Aktuell ist meine Konfiguration wie folgt aufgeteilt:

Bevor ein Modell meine Nachricht bearbeitet, stellt OpenClaw den Kontext für den jeweiligen Agenten zusammen. Zum Bootstrap gehören dabei die ausgewählten Workspace-Dateien, die grundlegende Anweisungen, Rollenbeschreibung und Hintergrundwissen liefern. Dieser vorbereitete Kontext ergänzt meine Nachricht.

Vereinfacht sieht der Ablauf so aus:

Werkzeugaufrufe und Delegation können weitere Modellaufrufe auslösen. Auch bei einer späteren Nachricht wird der Kontext erneut zusammengestellt, gegebenenfalls mit einer Zusammenfassung des bisherigen Gesprächs.

Wenn ich einem Agenten eine Frage stelle, reist also häufig mehr mit als mein letzter Satz. Je nach Laufzeit können folgende Bestandteile dazukommen:

Das Gepäck ist nicht grundsätzlich schlecht. Ein Agent braucht Kontext. Ohne Projektregeln oder relevante Entscheidungen produziert er unter Umständen etwas, das nur auf den ersten Blick passt. Aber viel Kontext bedeutet nicht automatisch guter Kontext. Widersprüchliche Regeln, veraltete Befunde und lange Logs können die entscheidende Information verdecken.

Wenn ich einem Modell gefühlt mit jeder Nachricht einen halben Roman ins Gesicht werfe, habe ich vielleicht viel Material dabei und trotzdem nicht die Antwort auf die eigentliche Frage. Ein großes Kontextfenster ist für mich eine Reserve, kein Füllziel.

Ich halte deshalb die rollenspezifischen Workspaces und die jeweilige Toolauswahl möglichst schlank. Ein Unteragent bekommt einen gezielten Aufgabenbrief statt pauschal den gesamten Chat als Roman: Relevante Fakten, Pfade und Quellen sowie bereits getroffene Entscheidungen samt Begründung. Was der delegierende Agent mit mir besprochen hat, weiss ein frisch gestarteter Spezialist nicht automatisch.

Früher ließ ich die Spezialisten immer wieder die AGENTS.md und die Projektdokumentation durcharbeiten, obwohl der delegierende Agent die nötigen Informationen bereits erarbeitet hatte. Den Wiederholungsaufwand hatte ich selbst verursacht: Ich hatte die Regeln in der AGENTS.md von builder unbewusst so formuliert, dass sie genau dieses Verhalten verlangten. Heute sollen main oder builder diese Regeln und Befunde mit Quellenbezug verdichten und weitergeben. Relevante Projektanweisungen und betroffenen Code prüfen die Spezialisten weiterhin Fehlende, geänderte oder widersprüchliche Informationen laden sie gezielt nach. So erspare ich ihnen vermeidbare Wiederholung.

Für ein Follow-up schickt der koordinierende Agent nach Möglichkeit nur die Änderungen gegenüber dem bisherigen Auftrag: Was hat sich geändert, welcher Befund ist neu, was soll jetzt passieren? Das setzt voraus, dass der bisherige Auftragsstand noch verfügbar ist. Fehlt er nach einem Kontextverlust, muss der Koordinator zuerst das relevante Ziel, die Entscheidungen und Einschränkungen wieder zusammenstellen. Solange ein Paket offen ist oder eine Korrektur zum bisherigen Ergebnis gehört, bleibt derselbe Spezialist zuständig. Ist das Paket abgeschlossen und später kommt eine neue, unabhängige Aufgabe, sollen main oder builder dafür eine frische Spezialisten-Session starten. So bleibt der Zusammenhang erhalten, ohne dass ein Agent zum Dauerlager für alles wird.

Ein schlanker Prompt ist allerdings kein Selbstzweck. Wichtige Grenzen und Projektkonventionen dürfen nicht verschwinden, nur weil man damit ein paar Token spart. Die wöchentliche OpenAI-Quota schrumpft schließlich auch dann, wenn unklare Regeln in der AGENTS.md vermeidbare Korrekturschleifen auslösen.

Als hypothetisches Beispiel nehme ich ein Formular, das eine Einstellung speichern soll. Nach dem Neuladen erscheint allerdings wieder der alte Wert. Die Browseroberfläche zeigt eine erfolgreiche Aktion, während der erwartete Zustand nicht bestehen bleibt.

Ein schlechter Auftrag wäre: „Mach das Formular kaputtfrei.“ Ein brauchbarer Auftrag könnte so aussehen:

Dazu gehören im echten Auftrag natürlich die tatsächlichen Pfade und bereits bekannten Fakten. Wenn schon ein reproduzierbarer Request oder eine Fehlermeldung vorliegt, gehören sie ins Briefing. Zwei Agenten unabhängig dieselbe Ausgangslage suchen zu lassen, ist noch keine produktive Parallelisierung.

builder kann die Implementierung samt Tests an einen passenden Spezialisten geben. Ist bereits bekannt, dass mehrere eng gekoppelte Teile schwierig umzubauen sind, geht der Auftrag direkt an coder. Zeichnet sich eine kleine Änderung entlang eines bestehenden Musters ab, kann mini_coder passen.

Ich möchte dabei nicht fünf Übergaben für fünf Zeilen Code. Umsetzung und zugehörige Tests bilden oft ein nützliches Paket. Separate Recherche oder Browserprüfung kommen hinzu, wenn sie einen konkreten Mehrwert haben.

Ein gutes Ergebnis enthält nicht nur „fertig“, sondern die geänderten Stellen, ausgeführte Prüfungen samt Ergebnis und offene Grenzen. Der delegierende Agent sammelt diesen Abschluss ein und bewertet ihn. „Accepted“ oder „queued“ heißt erst einmal nur, dass ein Auftrag angenommen oder eingereiht wurde, nicht dass er erfolgreich beendet ist.

Ein grüner Haken beim Build ist ebenfalls kein Beweis, dass der Nutzerfluss funktioniert. Er kann bestehen, während Browser-Routing, CORS oder Persistenz im tatsächlichen Ablauf Probleme machen. Für mein Beispiel gehört deshalb eine echte Nutzeraktion dazu: Speichern, neu laden und den sichtbaren Zustand prüfen. Was nicht getestet wurde, sollte im Ergebnis weder als bestanden auftauchen noch verschwiegen werden.

Ein Spezialist ist fertig, aber im Chat passiert nichts mehr. Ich frage nach, und erst dann sammelt builder das längst vorliegende Ergebnis ein. Solche Hänger habe ich mit meinem Setup erlebt. Aus Nutzersicht ist das ziemlich lästig: Ich wollte Arbeit abgeben und muss nun selbst daran erinnern, dass sie auch abgeschlossen wird.

Die Rollen auf dem Papier sind der einfache Teil. Spannender wird es bei Toolverträgen und Abschlusswegen. In meinem Alltag mit OpenClaw haben sich geänderte Schnittstellen und unklare Rückmeldungswege als Stolperstellen erwiesen. Deshalb sollen main und builder prüfen, wie ein delegierter Auftrag seine Fertigstellung meldet, statt sich blind auf eine irgendwann eintreffende Rückmeldung zu verlassen. Entscheidend ist, welchen Abschlussweg der konkrete Auftrag hat und ob sein Ergebnis tatsächlich eingesammelt wurde.

Ähnlich verhält es sich mit Rechten. Welche Tools ein Unteragent nutzen kann, hängt nicht nur von seinem Profil ab, sondern auch von den Rechten, die der Elternkontext mitbringt. Eine eingeschränkte Toolauswahl ist zudem nicht automatisch eine Sandbox: Eine verfügbare Shell kann weitreichende Möglichkeiten haben. Ein kurzer Rollentext macht daraus noch keine technische Isolation.

Konfigurationsänderungen können ebenfalls zu falschen Erwartungen führen. Ein laufender Turn kann noch eine ältere Tooloberfläche sehen, obwohl die Konfiguration inzwischen geändert wurde. Wenn ein Tool anders aussieht als erwartet, ist „aber ich habe es doch gerade angepasst“ keine besonders hilfreiche Fehlersuche. Man muss prüfen, was in der konkreten Sitzung tatsächlich verfügbar ist.

OpenClaw entwickelt sich schnell. Das ist spannend, bedeutet im Alltag aber auch, dass einmal funktionierende Annahmen über Schnittstellen, Rechte und Abschlussmeldungen nicht dauerhaft gelten müssen. Diese Stolperstellen erlebe ich mit meinem Setup immer wieder.

Am OpenClaw-Code stören mich im Alltag vor allem uneinheitliche Muster und Änderungen, die einen Beispielpfad reparieren und an anderer Stelle etwas kaputtmachen. Dabei wirkt es auf mich öfter so, als seien die betroffenen Abläufe nicht ausreichend unter Alltagsbedingungen getestet worden.

In meinem eigenen OpenClaw-Setup gab es daneben ein hausgemachtes Problem: Zu viele Regeln. Für jeden beobachteten Ausrutscher lässt sich eine neue Anweisung formulieren. Irgendwann verwalten die Agenten mehr Ausnahmen, als sie Aufgaben erledigen. Nicht jeder einzelne Ausrutscher braucht deshalb einen neuen Absatz in der AGENTS.md. Wenn mehrere Regeln dasselbe Problem umkreisen, fasse ich sie lieber zu einer klaren Anweisung zusammen. Regeln, deren ursprünglicher Anlass nicht mehr besteht, können wieder raus. Kurz: Gelegentlich muss ausgemistet werden.

Die AGENTS.md ist bei mir keine vollständige Bedienungsanleitung für jeden denkbaren Fall. Sie beschreibt vor allem Zuständigkeiten und Arbeitsweisen. Ein paar Beispiele aus den Regeln von main und builder, hier auf Deutsch zusammengefasst:

Innerhalb dieses Rahmens entscheiden main und builder, welcher Spezialist passt und welche Prüfung tatsächlich nötig ist. Projektbezogene Details gehören dagegen in die jeweilige Projektdokumentation und in den konkreten Auftrag, nicht dauerhaft in jede Rollenbeschreibung.

Beim Formulieren solcher Regeln und Prompts kann ich mir wiederum von einem Agenten helfen lassen. Ich beschreibe in meinen eigenen Worten, was ich erreichen möchte und wo es bisher hakt, und lasse daraus einen verständlichen Auftrag oder eine knappe Anweisung machen. Wer spricht schließlich besser LLM als ein LLM? Die Ziele gebe weiterhin ich vor. Der Agent hilft mir, sie passend zu formulieren.

Nicht nur Regeln sammeln sich an, auch Gespräche wachsen. Nach längerer Arbeit mit builder stecken im Kontext Entscheidungen, Zwischenstände und Ausnahmen, die für dieses eine Problem sinnvoll waren. Wechsle ich danach zu einer unabhängigen Aufgabe, können diese Altlasten die neue Arbeit unnötig beeinflussen. Dieser schleichende Kontextzuwachs, Context Creep, fällt nicht unbedingt sofort auf.

Für ein neues Thema starte ich deshalb lieber eine neue Session. Benötigte Projektregeln und relevante Entscheidungen nehme ich gezielt mit. Der Rest darf im alten Gespräch bleiben. Eine laufende Umsetzung oder ihre Korrekturen halte ich dagegen zusammen, bis das Paket abgeschlossen ist.

Die Rollenaufteilung lässt sich auch für andere Aufgaben nutzen. Ich kann den Agenten etwa seine eigenen Arbeitsabläufe untersuchen lassen oder mit ihm prüfen, ob eine neu gemeldete Sicherheitslücke meine Projekte betrifft. Zwei Beispiele aus meinem Alltag:

Mit meinem Setup versuche ich, alltägliche Arbeit sauber aufzuteilen: main bleibt der direkte Einstieg, builder koordiniert zusammenhängende technische Pakete und Spezialisten bekommen begrenzte Aufträge mit einem klaren Ergebnis.

Die Modellwahl und Thinking-Stufen sind dabei Einstellungen, die sich im Alltag bewähren müssen, keine Qualitätsgarantie. Besonders viel bringt mir, das Prompt-Gepäck bewusst zu halten und möglichst nur dort zusätzliche Agenten einzusetzen, wo die Übergabe ihren Preis wert ist.

Wenn eine kleine Änderung direkt erledigt werden kann, darf sie klein bleiben. Wenn ein komplexer Nutzerfluss betroffen ist, reicht ein grüner Build dagegen nicht als Beruhigungspille. Mein Ziel ist nicht möglichst viel Agentenverkehr. Mein Ziel ist, dass am Ende die Arbeit erledigt ist, möglichst effizient und kostengünstig, und ich noch verstehe, was passiert ist.

Passende Schulungen zum Einsatz von KI-Agenten in der Softwareentwicklung: