Der erste Beitrag dieser Serie hat die Formel aufgestellt: Agent = Modell + Harness. Alles an einem KI-Agenten, was nicht das Modell ist (die Schleife, die Tools, das Gedächtnis, die Verifikation), ist Harness. Der zweite Beitrag hat argumentiert, dass Skills Harness Engineering sind, das Sie in einer Markdown-Datei erledigen können: Eine SKILL.md ist ein verpacktes Harness-Fragment, das im passenden Moment in Claude Code, DeepAgents oder Cursor eingespeist wird, ganz ohne Infrastrukturcode.
Dieser Beitrag schlägt den nächsten Schritt in derselben Abfolge vor. Wenn ein Skill ein Harness-Fragment in einer Markdown-Datei ist, dann ist ein reWritable ein vollständiger Harness in einer HTML-Datei. Es ist derselbe Kompressionsschritt (was früher Infrastruktur war, wird als Inhalt ausgeliefert), nur angewandt auf den ganzen Harness statt auf ein Stück davon.
Was reWritable ist
Ein reWritable ist eine einzelne .html-Datei, die sich in jedem Browser öffnen lässt und ein Dokument darstellt: einen Tracker, eine Presseaussendung, ein Budget, einen Brief, ein Kanban-Board, was auch immer die Datei gerade enthält. Sie drücken ⌘K und tippen eine Anweisung in normaler Sprache. Die Datei schreibt sich selbst neu: Der Agent erhält das Dokument und liefert ein geändertes Dokument zurück, und die neue Version ersetzt die alte. Mit ⌘Z gehen Sie durch frühere Versionen zurück. ⌘S schreibt den aktuellen Stand fest, indem die Datei an Ort und Stelle auf die Platte zurückgeschrieben wird (Chromium mit der File System Access API) oder indem sie eine aktualisierte Kopie ihrer selbst herunterlädt (überall sonst).
Kein Server, keine Installation, kein Konto, kein Build-Schritt.
Das mentale Modell: wie ein Word-Dokument, nur dass sich das Dokument selbst neu schreiben kann. Das Deployment-Modell: Ziehen Sie die Datei auf Ihren Desktop. Das Kollaborationsmodell: Schicken Sie die Datei weiter. Wer sie bekommt, hat alles.
Ein vollständiger Harness, kein Fragment
Der Unterschied zwischen einem Skill und einem reWritable ist der Unterschied zwischen einem Fahrgast und einem Auto.
Ein Skill ist ein Harness-Fragment. Die eigentliche Harness-Maschinerie (die Schleife, das Gedächtnis, die Tool-Ausführung, der Prompt-Aufbau, der Modellaufruf) steckt in der Host-Anwendung, die den Skill geladen hat. Ohne Claude Code, DeepAgents oder Cursor ist eine SKILL.md bloß eine Textdatei. Der Skill liefert das Fachwissen, der Host alles andere.
Ein reWritable ist ein vollständiger Harness. Klein, mit klaren Vorgaben, auf ein einziges Tool beschränkt, aber vollständig. Die HTML-Datei bringt ihre eigene Schleife mit (⌘K → ändern → darstellen), ihr eigenes Gedächtnis (einen Undo-Stack in IndexedDB, der zugleich als Dialogprotokoll dient), ihre eigene Persistenz (Commit an Ort und Stelle, mit Download als Rückfallebene) und ihren eigenen Modellaufruf (OpenRouter, wobei der API Key im sessionStorage liegt, sodass er nie mit der Datei mitreist). Es gibt keine Host-Anwendung. Der Browser ist die Runtime, die Datei ist der Harness, und beide kommen zusammen an.
Deshalb lässt sich ein reWritable so verteilen, wie es mit einem Skill nicht geht. Sie können einer Kollegin keine SKILL.md mailen und erwarten, dass irgendetwas passiert. Ein reWritable können Sie ihr mailen, und sobald sie doppelklickt, hat sie ein funktionierendes, sich selbst veränderndes Dokument auf dem Desktop.
Was der Harness enthält
Der erste Beitrag hat aufgezählt, worum sich Agenten-Harnesses im Produktivbetrieb typischerweise kümmern. Gehen wir die Liste für reWritable durch:
Prompt-Aufbau. Die Runtime stellt einen System-Prompt zusammen, der dem Modell die Rolle gibt, ein Dokument zu ändern, und nicht, eine App zu bauen oder Code zu generieren. Sie übergibt den aktuellen Dokumentinhalt und Ihre Anweisung. Retrieval, Scratchpad und Verhandlungen über mehrere Runden gibt es nicht. Ein Aufruf, eine Transformation.
Tool-Ausführung. Der Agent hat genau ein Tool: das Dokument neu schreiben. Er hat keine Shell, kein Dateisystem und keine Websuche. Genau diese Einschränkung ist der Sinn der Sache: Die Ausgaben des Agenten bleiben auf ein einziges Artefakt begrenzt, und das macht das System für Menschen ohne Entwicklerhintergrund beherrschbar.
Gedächtnisverwaltung. IndexedDB speichert das aktuelle Dokument und einen Undo-Stack mit höchstens zehn Einträgen. Jedes ⌘K legt den vorherigen Zustand auf den Stack, ⌘Z nimmt ihn wieder herunter. Zehn Undo-Stufen sind zugleich eine Wiedergabe des Gesprächs, aus dem das aktuelle Dokument entstanden ist, in zehn Schritten. Das Modell hat zwischen den Aufrufen kein Gedächtnis, der Harness hat eines über die gesamte Lebensdauer der Datei.
Zustandspersistenz. Der Bootstrap in der .html-Datei enthält einen Inline-Snapshot, eine eingefrorene Serialisierung des Dokuments und aller strukturierten Daten, von denen es abhängt. Beim Commit wird der Snapshot mit dem aktuellen Zustand neu geschrieben. Die Datei auf der Platte ist das dauerhafte Artefakt, IndexedDB der Arbeitspuffer.
Verifikation. Das ist das Standbein, das reWritable fehlt. Es gibt keinen automatisierten Test, kein LLM als Richter und keinen Review-Agenten. Der Mensch sieht sich das dargestellte Dokument an und entscheidet. Für ein persönliches Dokumentenwerkzeug, das eine einzelne Person nutzt, ist das der richtige Kompromiss. Wo mehr auf dem Spiel steht, ist die Verifikation die naheliegende Stelle für eine Erweiterung.
Viereinhalb von fünf. Nach der Definition aus dem ersten Beitrag ist reWritable ein Harness.
Wenn der Harness zum HTML-Dokument wird
Am besten lässt sich das tatsächlich Neue an reWritable strukturell fassen, nicht technisch.
Bei jedem anderen Harness, der heute im Produktivbetrieb läuft, sind Harness und Artefakt klar getrennte Dinge. Claude Code ist ein Harness, Ihr Repository ist das Artefakt. clive ist ein Harness, Ihre Terminal-Sitzung ist das Artefakt. DeepAgents ist ein Harness, Ihr Projekt ist das Artefakt. Der Harness ist Infrastruktur, die neben dem Artefakt steht oder es umschließt. Das eine installieren Sie, am anderen arbeiten Sie.
Bei reWritable ist der Harness mit dem Artefakt verschmolzen. Der Bootstrap, der Loader, die Runtime, der Inline-Snapshot: All das steckt in derselben .html-Datei wie das Dokument, das Sie verfassen. Sie müssen keine eigene Infrastruktur installieren und das Artefakt bei keinem Host-Harness registrieren. Der Harness reist mit dem Dokument. Wer das Dokument teilt, teilt den Harness. Wer das Dokument forkt, forkt den Harness. Wer das Dokument archiviert, archiviert den Harness.
Das ist derselbe Kompressionsschritt, den Skills gemacht haben, nur zu Ende geführt. Skills haben Harness Engineering von „Python-Middleware schreiben“ zu „eine Markdown-Datei schreiben“ gebracht. reWritable geht weiter: von „eine Markdown-Datei schreiben, die in Claude Code geladen wird“ zu „eine HTML-Datei schreiben, die überall läuft, wo ein Browser läuft“. Jeder Schritt verkürzt die Distanz zwischen dem Menschen, der eine Idee hat, und dem Artefakt, das sie verkörpert.
Warum das über die Architektur hinaus zählt
Daraus folgen zwei Konsequenzen, die ein Blick von der Infrastruktur her übersieht.
Die erste ist eine Rückkehr zum Dokument als Einheit des Eigentums. Word, Excel und PowerPoint waren in den Achtziger- und Neunzigerjahren aus einem strukturellen Grund erfolgreich: Ein Dokument war eine Datei auf der Platte, die Ihnen gehörte und die Sie verschicken konnten. Die Cloud-Ära hat dieses Modell zerstört. Dokumente wanderten auf Server, und die Datei wurde zum Verweis auf einen Ort, an dem das eigentliche Dokument lag. reWritable bringt das Dokument in die Form zurück, die funktioniert hat: Bytes auf der Platte, die Ihnen gehören, die Sie teilen und archivieren können und die Sie ändern dürfen, ohne jemanden um Erlaubnis zu fragen. Der Agent darin ist eine Modernisierung. Das Dateiformat ist eine Wiederherstellung.
Die zweite ist das Read/Write-Web, das Berners-Lee ursprünglich vorgeschlagen hat. Das Web war als beschreibbares Medium gedacht. Für die meisten Menschen wurde es zum reinen Lesemedium, weil die Oberflächen zum Bearbeiten in Entwicklerwerkzeugen und hinter Cloud-Plattformen blieben. Ein reWritable ist ein beschreibbares Web-Dokument auf Dateiebene: Öffnen, ändern, speichern, verschicken, und das ohne Plattform, ohne Deployment und ohne Konto.
Das sind keine Konsequenzen von Harness-Architektur im Allgemeinen. Sie ergeben sich daraus, dass der Harness im Artefakt steckt. Ein in Claude Code geladener Skill verschafft Ihrer Tante kein beschreibbares Dokument. Ein reWritable schon.
Das tiefere Muster
Die Abfolge über die drei Beiträge hinweg ist ein einziges Argument darüber, wer Harness Engineering betreiben darf und wie.
Infrastruktur-Harnesses (Claude Code, DeepAgents, clive) bauen Ingenieure, die Python oder Go schreiben und Dienste deployen. Skills haben Harness Engineering nach Markdown verlegt: Wer Dokumentation schreiben kann, kann Fachwissen so festhalten, dass der Agent es verlässlich ausführt. reWritable verlegt es nach HTML: Wer ein Dokument beschreiben kann, kann ein sich selbst veränderndes erzeugen, und wer eine Datei an eine E-Mail hängen kann, kann es verteilen.
Jeder Schritt in dieser Abfolge tut dieselben zwei Dinge. Er komprimiert den Harness, denn was früher Infrastruktur war, wird zu Inhalt. Und er vergrößert den Kreis der Menschen, die einen ausliefern können: von Infrastruktur-Ingenieuren über Leute, die Dokumentation schreiben, bis zu allen, die je ein Word-Dokument benutzt haben.
Das Modell ist für alle dasselbe. Der Harness war früher Infrastruktur. Jetzt wird er in der Datei ausgeliefert.
Aus dem Englischen übersetzt: zum Originalbeitrag