Zwei Agentenhosts, eine Grenze: wie Claude Code und OpenClaw sich die Arbeit teilen

Bis in den Sommer hat diese Werkstatt sich selbst geprüft: Claude und Codex haben einander reviewt, aber beide saßen auf demselben Rechner und lasen dieselben Dateien. Seit September gibt es einen zweiten Agentenhost auf einem eigenen Gerät. Er heißt OpenClaw, und seine Aufgabe ist bewusst eng: auf die Live-Site schauen, wie ein Besucher sie sieht, messen, vergleichen, melden. Den veröffentlichten Stand verändert er nie.

Warum ein zweiter Host

Wer ein System baut und es selbst prüft, prüft mit denselben Annahmen, mit denen er gebaut hat. Ein Reviewer auf derselben Maschine liest den Quelltext und weiß, was gemeint war. Der Außenblick weiß das nicht. Er sieht nur, was ankommt: die ausgelieferte Seite, ihre Größe, ihre Antwortzeiten, ihre Widersprüche. Genau das ist der Wert.

Der zweite Host läuft deshalb getrennt: eigenes Gerät, eigenes Gedächtnis. Das Repository darf er lesen und prüfen, aber nicht verändern, was veröffentlicht wird. Was er über die Site weiß, weiß er aus dem Netz, aus dem Quelltext oder aus dem, was ich ihm schriftlich übergebe. Was OpenClaw ist und was bei mir darauf läuft, steht auf der Systemseite zum zweiten Agentenhost.

Die Rollen und die eine Grenze

Die Arbeitsteilung steht seit dem 17. September fest und ist auf beiden Seiten notiert:

• Claude Code hält das Repository, die Ground Truth, die Tests, die Umsetzung und die Verifikation nach dem Deploy.
• OpenClaw liefert den Außenblick: Messwerte, Diffs zum letzten Stand, die Perspektive eines Besuchers. Jeder Befund kommt mit URL und einem reproduzierbaren Messbefehl.
• Ich entscheide, was davon umgesetzt wird, und ich gebe frei, was veröffentlicht wird.

Die Grenze dazwischen ist hart: OpenClaw darf lesen, prüfen und auf Anfrage einen Patch vorschlagen, aber nie pushen, mergen oder deployen. Nicht, weil er es technisch nicht könnte, sondern weil zwei Schreiber auf demselben Stand genau die Kollision erzeugen würden, die ich mit Codex schon einmal gelernt habe. Ein Beobachter, der auch veröffentlicht, ist kein Beobachter mehr.

Das Postfach als Übergabe

Zwischen den beiden Hosts liegt kein gemeinsames Laufwerk, sondern ein Postfach mit zwei Richtungen. Der Ablauf ist immer derselbe:

1. Eine Anfrage geht hinüber: was geprüft werden soll, mit welchen Spielregeln (nur lesen, Zeitlimit, keine teuren Läufe).
2. Der Befund kommt zurück: nummeriert, mit URL, Messwert und Beleg. Vermutungen sind als Vermutung markiert.
3. Ich triagiere gegen das Repository: Ist der Befund echt, ist er ein Duplikat, verstößt der Vorschlag gegen eine meiner Regeln?
4. Was umgesetzt wird, bekommt eine Rückmeldung ins Postfach, mit der Bitte um Nachmessung.
5. Die Nachmessung schließt den Kreis oder öffnet den nächsten.

Das klingt nach Bürokratie für zwei Programme. In der Praxis ist es das Gegenteil: Weil jeder Schritt schriftlich ist, kann ich nachlesen, wer was wann behauptet hat, und Widersprüche fallen sofort auf.

Der Pilot als Beleg

Der erste vollständige Durchlauf war ein Baseline-Check der Site Mitte September. OpenClaw lieferte sieben Vorschläge. Die Triage ergab:

• Vier waren Duplikate oder Dinge, die die Site absichtlich so macht.
• Zwei verstießen gegen meine eigenen Regeln für diese Seite: Angebots-Sprache und neue Zahlen-Streifen.
• Einer war ein echter Befund: Das Startseiten-Bundle war deutlich zu groß.

Beim echten Befund stimmten alle Messwerte. Die Ursachenvermutung stimmte nicht. OpenClaw tippte auf eine Diagramm-Bibliothek im Startpaket. Tatsächlich zog eine Sektion der Startseite alle Blog-Texte mit in das Paket, obwohl sie nur die Titel brauchte. Der Fix hat das Paket um rund ein Achtel verkleinert; die Nachmessung von außen hat es bestätigt.

Die Lehre steht seitdem in beiden Gedächtnissen: Messungen trauen, Diagnosen reproduzieren. Ein Außenblick sieht, dass etwas nicht stimmt. Warum es nicht stimmt, weiß nur, wer den Quelltext hat.

Das Gegen-Gutachten

Einmal pro Woche laufen zwei Sichten gegeneinander. Von außen misst ein Skript, was der zweite Host tatsächlich tut: Version, Dienste, Rechte, Automationen. Von innen beantwortet der Host dieselben zehn Fragen aus seiner eigenen Sicht. Der Abgleich markiert, was belegt ist, was nur behauptet wird und was ich entscheiden muss.

Der Nutzen ist nicht die Kontrolle, sondern die Ehrlichkeit, die sie erzwingt. Im letzten Gutachten hat der Host selbst notiert, dass sein Bereitschaftsdienst seit Wochen nichts zu tun hatte. Das ist eine Antwort, die ein System ohne Gegenfrage nie geben würde.

Was als Nächstes geprüft wird

Dieser Text und die Änderungen an Startseite und Profil, die mit ihm entstehen, sind der nächste Testfall. Nach dem Deploy bekommt der Website-Agent des zweiten Hosts den Auftrag, genau diese Änderungen unabhängig zu bestätigen. Wo seine Messung von meiner abweicht, beginnt der nächste Kreis.