Skills, Subagents, Memory, Headless-Ausführung. Der Claude-Code-Harness, der es einer Person ermöglicht, ein Multi-App-Studio zu betreiben. Über ein Jahr gebaut und betrieben, unter echtem Release-Druck.
Sapplify betreibt sechs mobile Apps in drei Stores, ein Produktions-SaaS in sieben EU-Ländern, eine Marketing-Pipeline, ein Analytics-Dashboard und ein Lead-Generation-System. Sechs Marken, drei Plattformen, dutzende interne Tools. Nichts davon ist eine Geschichte über härteres Arbeiten. Härteres Arbeiten reicht bei einer Person nicht aus.
Was ein Solo-Studio wirklich skaliert, ist den Agent zum Kollegen zu machen. Nicht zum Code-Completion-Tool, nicht zur Chat-Sidebar. Zu einem Worker mit delegierter Verantwortung, dauerhaftem Kontext und der Autonomie, zwischen Sessions zu handeln. Diese Fallstudie ist die Betriebsschicht, die ich im letzten Jahr um Claude Code herum gebaut habe, um das real werden zu lassen.
Der Harness ist aus vier Bausteinen komponiert. Skills bündeln Domänen-Expertise, die der Agent bei Bedarf lädt: wie man einen Android-Build in den Internal Track ausliefert, wie man einen Marketing-Post im Studio-Ton schreibt, wie man ein Supabase-Schema sicher migriert. Subagents sind Workers, die der Controller parallel für unabhängige Tasks einsetzt — jeder bekommt sein eigenes Kontextfenster und meldet sich, wenn fertig. Memory hält typisierte Einträge (wer ich bin, was ich bevorzuge, was läuft, wo Dinge liegen), die über Sessions hinweg bestehen. Ein Studio-CLI fasst alles zusammen mit einzeiligen Befehlen, die mehrstufige Operationen kapseln.
Nichts davon ist exotisch. Interessant ist, was bei der Komposition rausfällt. Eine neue Session liest den Memory-Index, lädt die richtigen Skills für die anstehende Arbeit, setzt Subagents für parallelisierbare Schritte ein und produziert Ergebnisse, die wie aus einem kleinen Team aussehen. Auf den vier Primitiven aufbauend drei Betriebsmuster: Verifizierung (Controller prüfen Subagent-Behauptungen), Fokus-Disziplin (der Agent setzt erlaubte Arbeit gegenüber dem Operator durch) und Headless-Ausführung (Agents, die ohne Operator-Präsenz laufen).
Das nützlichste Muster im Harness ist auch das gefährlichste. Einen Subagent für parallele Arbeit einzusetzen und seinem DONE-Report zu vertrauen ist nützlich, weil Subagents unabhängige Tasks abarbeiten können, während der Controller orchestriert. Es ist gefährlich, weil der Report das ist, was der Subagent vorhatte, nicht was tatsächlich auf der Platte gelandet ist. Subagents wissen, was sie ändern wollten. Sie prüfen nicht den Diff, den sie committet haben, gegen den Task-Scope. Wenn das Working Tree vorher schon staged-Dateien hatte oder wenn der Subagent Dateien als Seiteneffekt berührt hat, fahren die still im Commit mit.
Die Gegenmaßnahme ist strukturell. Jeder DONE-Report wird als Behauptung behandelt, die vor dem nächsten Schritt verifiziert werden muss. Nach einem Subagent-Commit prüft der Controller den Diff. Wenn Dateien außerhalb des Scopes auftauchen, wird der Commit gesplittet: die beabsichtigten Änderungen cherry-picken, den Rest zurücksetzen. Dem Subagent wird nie das letzte Wort darüber überlassen, was er geändert hat. Dieses eine Guardrail hat eine ganze Klasse von stillen Regressionen eliminiert, die früher Tage später in unverwandten Produkten aufgetaucht sind.
Ohne Memory startet jede Session bei null. Mit ad-hoc Memory häuft der Agent Widersprüche an. Der Harness nutzt ein typisiertes Memory-System: jeder Eintrag ist einer von vier Typen. User-Einträge beschreiben, wer ich bin und wie ich arbeite. Feedback-Einträge sind Regeln, die der Agent anwenden soll (inklusive Begründung, damit er Randfälle einschätzen kann). Project-Einträge tracken laufende Arbeit und Entscheidungen. Reference-Einträge zeigen, wo Informationen in externen Systemen liegen. Eine Index-Datei listet sie auf; Einträge verlinken sich gegenseitig per Namen, wenn sie zusammenhängen.
Die Disziplin, die das funktionieren lässt, ist was nicht gespeichert wird. Code-Muster, Datei-Pfade, Git-History, Projektstruktur — alles, was aus dem aktuellen Zustand ableitbar ist — bleibt draußen. Memory ist für das, was der Codebase nicht sagen kann: Präferenzen, Narben, laufende Entscheidungen, wo die Leichen begraben sind. Alles andere wird zu Session-Beginn aus dem Projekt neu berechnet. Diese Disziplin hält das Memory klein, aktuell und lesenswert.
Solo-Operatoren driften ab. Der Agent ist auf Hilfsbereitschaft kalibriert, was heißt: Ja zu Scope-Erweiterung sagen. Operatoren sind opportunistisch — wenn der Agent eh schon Kontext geladen hat, warum nicht das anliegende Backlog abarbeiten? Zusammen wandern sie. Eine Session, die mit Task A anfing, liefert Änderungen an D, E und einem halb-fertigen F aus. Task A ist am nächsten Morgen immer noch offen.
Focus Lock verschiebt die Scope-Disziplin in den System-Prompt, wo der Agent sie durchsetzen kann. Die aktuell erlaubte Arbeit wird explizit benannt. Der Agent ist angewiesen, gegen mich zurückzuschießen, wenn ich abdrifte — nicht als einmaliger Hinweis, sondern bei jedem Drift-Versuch. Es gibt eine Tangenten-Capture-Datei, damit gute Ideen nicht verlorengehen, und eine explizite Override-Phrase für legitime Re-Priorisierung. Der entscheidende Zug ist, dass der Agent gefragt wird, der Disziplinator zu sein, nicht ich. Der Agent hat die Konsequenz, zehn Mal hintereinander zurückzuschießen, wo ich nach zwei Mal nachgegeben hätte.
Der Harness hat Agents, die ohne Mensch an der Tastatur laufen. Ein geplanter Job startet über Nacht, durchsucht eine Domäne (Lead-Pipeline, Content-Backlog, Social-Kalender) und entwirft entweder Arbeit zur Prüfung — oder erledigt bei eng-skopierten Tasks alles end-to-end. Das Ergebnis landet in einer Queue, die ich morgens durchgehe.
Headless-Ausführung ist da, wo der Harness am meisten zurückzahlt und am schlimmsten kaputtgeht. Sie zahlt zurück, weil der Agent außerhalb meiner Arbeitszeit operiert und verfügbare Zeit multipliziert. Sie geht schlimm kaputt, weil kein Operator im Loop ist, der bemerkt, wenn etwas aus dem Ruder läuft. Die Disziplin, die das kompensiert, ist enger Scope, beobachtbare Artefakte (jeder Lauf hinterlässt Logs) und menschliche Gates vor allem, was die Außenwelt betrifft (Publishing, Zahlungen, Kommunikation). Der Agent arbeitet. Der Operator gibt frei. Das Studio läuft durch die Nacht.
Agents sind am nützlichsten, wenn man ihnen Autonomie zutraut — und am unzuverlässigsten gerade wegen dieser Autonomie. Die Claude-Code-Version, die ich bauen wollen würde, ist die, wo Verifizierung strukturell ist, nicht freiwillig. Ich habe über drei spezifische Fehler-Modi im Detail geschrieben.