Malleable Software: Wie du deinen Agent Harness an deinen Workflow anpasst

Beim letzten Open Space im April lief mein Pi Agent live im Terminal.

„Kann ich das auch selbst bauen?“

Das Interessante an der Frage ist nicht, dass die Leute einen Agenten bauen wollen, sondern, dass die meisten gar nicht wussten, dass sie ihren Agenten überhaupt verändern können. Claude Code, Codex CLI, Cursor — alle wurden im Team verteilt, alle laufen in der Default-Konfiguration. Niemand hat hineingegriffen.

Genau das ist die Lücke, die ich in diesem Post schließen will.

Was „malleable software“ im Agent-Kontext heißt

Der Begriff malleable software beschreibt Software, die ihre Nutzer einlädt, sie zu verändern. Nicht über mitgelieferte Einstellungen, sondern über echte Eingriffe in Verhalten und Struktur. Emacs ist das klassische Beispiel: Du startest mit einem Editor und endest mit einem System, das deinen Kopf abbildet. (Ich bin übrigens absoluter Fan von Emacs genau deswegen.)

Im Agent-Kontext heißt das: Der Agent Harness — also Claude Code, Codex oder ein vergleichbares Tool — ist nicht nur etwas, das du benutzt. Er ist etwas, das du formst.

Vergleich zu IDE-Plugins: Plugins erweitern Funktionen. Sie hängen sich an definierte Schnittstellen, die der Plugin-Entwickler vorgesehen hat. Du bekommst einen neuen Befehl, eine neue Sidebar, eine neue Linter-Regel. Die Substanz der IDE bleibt dieselbe.

Beim Agent Harness greifst du tiefer ein. Du legst Dateien ab, die der Agent automatisch liest. Du definierst Regeln, die seine Werkzeuge filtern. Du gibst ihm zusätzliche Kommandos über MCP. Du startest Subagents, die Teile der Arbeit übernehmen. Damit veränderst du nicht nur, was der Agent kann, sondern wie er denkt — welchen Kontext er hat, welche Reihenfolge er einhält, welche Pfade er nicht anfasst.

Drei Stufen der Kontrolle

Ich teile die Anpassung gerne in drei Stufen ein. Nicht, weil das eine Doktrin ist, sondern weil jede Stufe einen anderen Aufwand und einen anderen Nutzen hat. Die meisten Teams, die ich sehe, profitieren am stärksten davon, dass sie überhaupt Stufe 1 verlassen.

Level 1 — Kontext setzen

Aufwand: 5 bis 15 Minuten.

Du legst eine CLAUDE.md/AGENTS.md in dein Repo und beschreibst die Eckpunkte deines Projekts. Welche Sprache, welches Build-System, welche Test-Kommandos, welche Konventionen. Eventuell ein paar Stolperfallen, die der Agent ohne Hinweis garantiert tritt.

Beispiel aus einem meiner Projekte, das du vielleicht kennst, in frühen Stadien:

# Projekt: shift2ai.de

- Static site, Nanoc, Markdown-Sources unter `site/`
- Build: `bundle exec nanoc compile`
- Tests gibt es nicht; Vorschau über `bundle exec nanoc view`
- Deutsche Inhalte. Du-Anrede, kein Consulting-Sprech.
- Keine externen JS-Frameworks. Vanilla JS, wenn überhaupt.

Das ist trivial — und es verändert das Verhalten sofort. Der Agent fängt nicht mehr an, ein React-Setup vorzuschlagen. Er schreibt deutsche Texte im richtigen Ton (zumindest grob, denn für das Marketing-Sprech-Verbot muss man schon eine deny list mit angeben, habe ich gemerkt). Er führt das richtige Build-Kommando aus, statt eines erfundenen.

Wenn du nichts anderes machst: mach Level 1. Es ist der größte Hebel pro investierter Minute, um Abweichung vom Standardverhalten zu erzeugen.

Level 2 — Verhalten steuern

Aufwand: 30 bis 60 Minuten, plus laufende Pflege.

Hier hörst du auf, dem Agenten Hinweise zu geben, und fängst an, ihm Regeln zu setzen. Das geht über mehrere Mechanismen, je nach Tool:

• Pfadbasierte Regeln (bspw. .claude/rules/): „In diesem Verzeichnis darfst du keine Migrationen ändern“, oder „In diesem Modul gibt es eine eigene Lint-Konfiguration, halte dich daran.“
• Hooks: Skripte, die vor oder nach jedem Tool-Call laufen. Ein Pre-Commit-Hook, der den Agent zwingt, vor jedem Commit den Linter laufen zu lassen. Ein Post-Edit-Hook, der gezielt Tests in der betroffenen Datei ausführt. (Commit-basierte Hooks kann man auch mit git direkt einbauen, aber kommt der Agent immer einmal ins Straucheln, weil der Commit fehlschlägt.)
• Erlaubnis- und Ablehnungsregeln: Welche Shell-Kommandos darf der Agent ohne Rückfrage ausführen, welche niemals? Bei mir steht git push auf der Sperrliste, weil ich den letzten Schritt selbst mache, nachdem ich ein Review abgeschlossen habe.

Konkretes Beispiel: ein Hook, der nach jedem Edit den TypeScript-Compiler in dem geänderten Modul aufruft und das Ergebnis zurück in den Kontext schiebt. Der Agent sieht seinen eigenen Fehler sofort und korrigiert ihn, ohne dass du eingreifen musst. Die lassen sich mit Claude selbst generieren, aber es gibt auch Beispiele auf GitHub zu finden; hier wäre so eines. Das ist die Art geschlossener Feedback-Loop, die aus generiertem Code etwas macht, das man tatsächlich mergen will. Ähnlich wie das Scope-Pattern aus „Reviewbare Diffs“, nur dass die Schleife hier automatisiert ist statt im Prompt formuliert.

Level 2 lohnt sich, sobald du den Agenten regelmäßig auf demselben Projekt einsetzt. Die Stunde Setup verteilt sich auf hunderte Sessions.

Level 3 — Orchestrierung

Aufwand: 1 bis 2 Stunden Setup, dann fortlaufende Verfeinerung.

Hier wechselt das Modell. Du steuerst nicht mehr einen Agenten, der Aufgaben abarbeitet. Du baust ein kleines System aus mehreren spezialisierten Agenten, die unterschiedliche Rollen haben.

Was dazu gehört:

• Subagents für klar abgegrenzte Aufgaben: einer für Code-Review, einer für Exploration einer fremden Codebase, einer für Test-Generierung. Jeder bekommt einen eigenen Systemprompt, eigene Werkzeuge, eigenen Kontext. Der Hauptagent ruft sie auf wie Funktionen. Opus 4.7 beispielsweise ist insbesondere darauf hin ausgelegt, Subagenten zu prompten, und Anekdoten häufen sich, dass das besser/kompakter/effizienter/… geht als vorher.
• Eigene CLI Tools und MCP-Server, die internes bereitstellen: ein Wrapper um euer Deployment-Skript, ein Lookup in eurer Ticket-Datenbank, ein Zugriff auf interne Dokumentation. Damit muss der Agent nicht mehr raten, wie euer System aussieht, oder mit curl API Calls ausführen, sondern er kann direkt Anfragen in Kommandos übersetzen.
• Parallele Worktrees: Mehrere Agenten arbeiten gleichzeitig an verschiedenen Branches an verwandten Tasks. Du wechselst zwischen ihnen wie zwischen Tabs. Das ist in manchen Codebases ein bisschen umständlicher als in anderen, und Parallelisierung kommt mit eigenen Problemen beim Verständnis daher. Aber dort, wo sich Worktrees lohnen, nämlich bei Experimenten, sind sie ein sehr mächtiges Werkzeug und ein kompetenter Agent kann sie gut benutzen.

Level 3 lohnt sich nicht für jeden. Wenn du Coding-Agents zwei Stunden pro Woche benutzt, bleib bei Level 1 und vielleicht ein bisschen Level 2. Der Mehrwert von Subagents zeigt sich erst, wenn du täglich mehrere komplexe Aufgaben durch den Agenten schickst. Vorher baust du Komplexität, die du nicht brauchst.

Metaebene: Agent Harness Engineering

Mein Pi Agent vom Meetup ist ein Beispiel für Level 3 und was danach noch kommt, nämlich das Erzeugen ganz eigener Agent Harnesses, mit deren Hilfe man all die vorherigen Schritte implementieren kann. Damit lässt sich auf der Basis des Werkzeugs selbst, nicht bloß in irgendwelchen Markdown-Dateien schon ein eigener Subagent für Requirements-Klärung (siehe „Requirements Analyst“), einer für die Implementierung, ein Hook, der nach jedem Schritt aufräumt und den Stand in eine Datei schreibt erzeugen. Das Ganze ist nicht magisch. Es ist ein laufender Bau, an dem ich seit Monaten immer mal wieder herumschraube.

Mit Codex für GPT 5.5 hat OpenAI im April 2026 auch einen Harness veröffentlicht, der bestehende Prompts an das neue GPT anpassen und vor allem angemessen kürzen kann. Das geht nicht ganz so weit, wie der Selbstbezug von Pi, aber es geht in die Richtung, in der sich die Software-Tools selbst anpassen.

Prompts und Konfiguration anpassen ist Level 2, auch mithilfe von Agenten; den Harness selbst zu verändern ist noch ein ganz anderes Level.

Warum die meisten auf Level 0 bleiben

Auf den Montags-Meetups (Claude Code Anonymous, Bielefeld) ist das Muster über Wochen stabil: Wer Claude Code installiert hat, nutzt es so, wie es aus der Box kommt. Keine CLAUDE.md, oder wenn, dann nur die von Claude selbst angelegt von /init. Keine Hooks. Keine Subagents. Oft nicht einmal eine bewusste Entscheidung darüber, welche Befehle automatisch durchlaufen dürfen.

Das liegt nicht an mangelnder Neugier. Die Leute, die zum Meetup kommen, sind per Definition neugierig.

Vielleicht liegt es daran, dass die Default-Erfahrung schon beeindruckend genug ist, um den nächsten Schritt nicht mehr zwingend wirken zu lassen. Oder auch unverstehbar, komplex, oder überfordernd genug. Schließlich muss man sich an die Arbeit mit Agenten erst gewöhnen.

Was fehlt, ist oft ein Blick über die Schulter von Leuten, die mit solchen Setups schon täglich arbeiten. Das ist kein Wunder; das Feld ist noch jung. In der Softwareentwicklung ist es ohnehin schwer genug, erfahrene Entwickler beim Arbeiten zu beobachten. Noch schwieriger ist es, jemanden zu sehen, der sein Agent-Setup offen zeigt: Welche Dateien er angelegt hat, welche Hooks er definiert hat, wie seine Subagent-Definitionen aussehen. Sobald das einmal sichtbar wird, lässt es sich auch im eigenen Alltag leichter nachbauen.

Installation ist nicht Konfiguration, und Konfiguration ist nicht Adoption. Lizenzen verteilen reicht nicht. Ohne ein gemeinsames „so machen wir das hier“ bleibt jeder bei seinem Standardverhalten. Das ist kein Vorwurf. Niemand hat den Leuten gezeigt, wie tief die Anpassung geht. Die Tutorials der Anbieter zeigen Features. Sie zeigen selten, wie ein erfahrener Nutzer das Tool für seinen Alltag zurechtbiegt. Und während du noch versuchst, die Doku zu lesen, hat sich der nächste Teil des Toolings schon wieder verschoben.

Diese Arbeit muss man im Team gemeinsam bewältigen. Sonst bleibt das Setup Einzelwissen oder wird zur Verschwendung.

Womit du anfangen solltest

Wenn du allein arbeitest und das Konzept neu für dich ist, fang mit Level 1 an. Eine Datei mit Anweisungen, fünf Minuten Investition. Beobachte über die nächste Woche, wie sich das Verhalten ändert. Wenn du dann mehr willst, kommt Level 2 fast von selbst.

Wenn ihr im Team arbeitet und dasselbe Muster seht — alle haben Lizenzen, niemand hat ein Setup, das über Default hinausgeht —, dann behandelt das nicht als Tool-Thema, sondern als Frage eurer Teamroutine. Legt fest, welche Datei den Projektkontext trägt, welche Kommandos erlaubt sind, welche Hooks sich lohnen und ab wann ein Diff nicht mehr reviewbar ist.

Der wichtige Punkt ist nicht, sofort Level 3 zu bauen. Der wichtige Punkt ist, Level 0 zu verlassen.