Von Mitte April bis Mitte Juni habe ich die Features meines Produkts kaum angefasst.
Ich baute damals an OwlMeans, einer Entwicklungspipeline, die aus User Stories Software macht. Die Arbeit drumherum war dagegen verstreut: Strategie, Markennotizen, Recherchen und Website-Texte lagen jeweils woanders. Bat ich einen Agenten um Hilfe, musste ich ihm die Firma jedes Mal von vorn erklären.
Zwei Monate habe ich gebraucht, um das zu ändern. Dabei ist die Arbeitsumgebung entstanden, die ich heute für Firmenwissen und wiederkehrende Arbeit nutze.
Das Problem zeigte sich bei ganz gewöhnlichen Aufgaben. Für einen Artikel brauchte ich die aktuelle Positionierung, für eine Änderung an der Website den tatsächlichen Funktionsumfang des Produkts. Eine Recherche setzte die Kundenfrage voraus, auf die wir eine Antwort suchten.
Es ging immer um dieselben Fakten, und trotzdem gab ich sie jedes Mal von Hand mit. Manchmal vergaß ich eine Einschränkung. Manchmal übernahm ein Entwurf eine Botschaft, die zu einer früheren Version der Firma gehörte.
Ein fähiger Agent kam mit dem Material zurecht, das ich ihm gab. Nur hatte ich ihm keinen verlässlichen Ort gegeben, an dem er dieses Material finden konnte.
Auf diesen Unterschied kam es an. Ich konnte für jede Aufgabe den Prompt verbessern. Oder ich sorgte dafür, dass sich das Arbeitswissen der Firma leichter finden und aktualisieren ließ. Ich habe mich für das Zweite entschieden.
Der gemeinsame Wissensbestand
Das Firmenwiki habe ich in Markdown angelegt. Es enthält Strategie, Kundenwissen, Markenregeln und Produktdokumentation. Die Indexdateien der Ordner zeigen einem Agenten, wo er suchen muss. Jede Seite hat ein klar umrissenes Thema, und eine neue Erkenntnis gehört neben das Wissen, das sie verändert.
Das klingt nach Ablage. Zu einem guten Teil ist es das auch.
Recherche und Umsetzung können auf denselben Bestand zurückgreifen. Braucht ein Artikel einen Fakt zum Produkt, weiß der Agent, wo er ihn prüfen kann. Fällt bei einer Änderung an der Website ein veralteter Fakt auf, hat die Korrektur im Wiki ihren Platz.
Ohne Urteilsvermögen kommt aber auch dieser Bestand nicht aus. Eine ungeprüfte Annahme über den Markt wird nicht dadurch wahr, dass ein Agent sie in einen ordentlich sortierten Ordner gelegt hat. Offene Hypothesen halten wir getrennt von gesichertem Wissen.
Die nächste Ebene waren Skills. Ich habe die Abläufe aufgeschrieben, die bei mir immer wieder anfielen: Recherche, Artikelvorbereitung, Abgleich der Website und Pflege der Produktdokumentation. Jeder Skill beschreibt die Aufgabe und die lokalen Regeln, die man leicht übersieht.
So kann eine Korrektur den nächsten Durchlauf verbessern. Dafür muss sie allerdings jemand in die passenden Anweisungen zurückschreiben. Das Modell lernt die Firma ja nicht dauerhaft kennen, nur weil ich es im Chat korrigiert habe.
Ein Skill kann veralten, genau wie ein Dokument. Jemand muss prüfen, ob sein Ablauf noch zu den Werkzeugen und zur Arbeit passt.
Die Agent-Skills-Spezifikation gibt das gemeinsame Format für Ordner und Metadaten vor. Die Anweisungen in unseren Skills müssen wir trotzdem selbst schreiben und pflegen.
Der Code gleich nebenan
Außerdem habe ich unsere Repositorys in die Arbeitsumgebung eingebunden. Beim Schreiben hat sich das ganz praktisch bemerkbar gemacht. Ein Release-Artikel konnte von der Implementierung ausgehen statt von meiner Erinnerung daran, was wir ausliefern wollten. Technische Dokumentation konnte unterscheiden, was schon als Code committet war und was noch als Idee auf der Roadmap stand.
Den Unterschied zwischen diesen Quellen hebt die Verbindung nicht auf. Ein Designdokument beschreibt eine Absicht. Ein Commit zeigt eine Implementierung. Keines von beiden belegt, dass ein bestimmter Ablauf in einem Kundenprojekt schon erfolgreich gelaufen ist. Für eine Firma, die eine KI-Entwicklungspipeline verkauft, gehört es zur Arbeit, diese Unterschiede sichtbar zu halten.
Mit dem Ablauf für Artikel bekam die Struktur sofort etwas zu tun. Ich konnte das Thema diktieren und den Agenten unser Wiki und externe Quellen prüfen lassen. Er bereitete einen Entwurf vor und schickte ihn durch die Textprüfung. Bilder und Fassungen für Social Media waren eigene Schritte. Veröffentlicht wurde nur, wenn ich es verlangte. Die Fakten mussten nicht mehr aus meinem Gedächtnis in jeden einzelnen Prompt wandern.
Derselbe Aufbau half bei der Arbeit an der Website. Die öffentliche Seite und die interne Erklärung ließen sich abgleichen, solange beide greifbar waren.
Von allein lief die Firma dadurch nicht. Ich habe weiterhin entschieden, was veröffentlicht wird, die Aussagen geprüft und festgelegt, welche Arbeit Aufmerksamkeit verdient.
Diese Erfahrung fließt auch in unsere Services ein. Den Ablauf festzulegen und eine Übergabe vorzubereiten, zählt dort genauso wie das Schreiben der Software. Beides braucht einen konkreten Umfang im jeweiligen Kundenprojekt statt des Versprechens, ein Agent werde das Geschäft schon führen.
Die Gedächtnisdateien
Die Juni-Fassung dieses Textes beschrieb die Kontextdateien, die ich damals nutzte. Dieser Aufbau hat sich inzwischen geändert.
Im Oktober lagen die Anweisungen, die alle Agenten teilen, bereits in AGENTS.md und einem gemeinsamen Skill-Verzeichnis. Wo nötig, kam eine kleine Brücke in CLAUDE.md dazu. Getrennte Kopien der Anweisungen für jeden einzelnen Agenten waren damit kein Vorbild mehr.
Die aktuelle Dokumentation zum Gedächtnis von Claude Code unterscheidet zwischen Projektanweisungen und automatischem Gedächtnis. Die alte pauschale Behauptung, das Werkzeug habe kein dauerhaftes Gedächtnis, lässt sich damit nicht mehr halten.
Unser Wissensbestand über die Firma ist für etwas anderes da. Er hält fest, was OwlMeans entschieden hat, welche Belege eine Aussage zum Produkt stützen und welcher Ablauf für eine Aufgabe gilt. Und ich muss ihn einsehen können, egal mit welchem Werkzeug ich gerade arbeite.
Der Text über den Umbau unseres Agenten-Setups beschreibt die spätere Struktur der Repositorys genauer.
Was es gekostet hat
Zwei Monate sind für einen Solo-Gründer ein großer Umweg. Mit der Arbeitsumgebung finde ich leichter in wiederkehrende Arbeit hinein, aber ihr Aufbau hat Features im Produkt verzögert. Außerdem bringt sie eine dauerhafte Pflicht mit sich: Anweisungen und Wissen müssen aktuell bleiben.
Ich würde die Zeit wieder investieren, weil ich mit dieser Struktur auch wirklich arbeite. Nur würde ich beim nächsten Mal kleiner anfangen. Ein verlässlicher Bestand für ein paar wiederkehrende Aufgaben ist schon nützlich, bevor daraus ein System für die ganze Firma wird.
Überarbeitet am 15. Oktober 2026. Am Bericht über den Umweg von April bis Juni hat sich nichts geändert. Die Abschnitte über die Struktur der Repositorys und das Gedächtnis trennen den ursprünglichen Aufbau vom heutigen.