Warum Muse Code seine Agenten die ganze Session am Leben lässt
Die leise Architekturentscheidung hinter dem Tempo von Muse Code: Hintergrund-Agenten, die die komplette Session durchhalten — statt pro Aufgabe gestartet und wieder weggeworfen zu werden.
Das Spawn-and-Discard-Problem
Die meisten Multi-Agenten-Coding-Tools folgen demselben Rezept: Kommt eine Aufgabe rein, wird ein Helfer-Agent hochgefahren, bekommt sein Arbeitspaket, liefert das Ergebnis ab — und wird wieder abgerissen. Eine saubere Abstraktion mit einem hässlichen Preis. Jeder frisch gestartete Agent fängt bei null an: Er muss die Repository-Struktur neu einlesen, das Build-System neu entdecken, die Konventionen deiner Codebasis neu lernen. Bei einer Session mit zehn Aufgaben zahlst du diese Kontext-Steuer zehnmal.
Und die Steuer besteht nicht nur aus Token. Sie kostet Latenz — jeder Kaltstart verzögert die eigentliche Arbeit — und sie kostet Steuerungsaufwand, denn ein Agent, der vergessen hat, was er vor einer Stunde gelernt hat, stellt dir dieselben Fragen zweimal.
Die Antwort von Muse Code: Persistenz
Muse Code besteht aus einer schlichten Haupt-Agenten-Schleife plus einer Reihe asynchroner Hintergrund-Agenten — und diese Hintergrund-Agenten bleiben über die gesamte Session aktiv. Sie werden nicht für einzelne Aufgaben erzeugt. Jeder ist spezialisiert, sammelt im Verlauf der Session immer mehr Kontext an und entscheidet selbst, wann etwas wichtig genug ist, um es an den Haupt-Agenten zurückzumelden.
Gerade dieses letzte Detail wiegt schwerer, als es klingt. Die Hintergrund-Agenten blockieren die Hauptschleife nicht, während sie auf Anweisungen warten — und sie fluten sie auch nicht mit Statusmeldungen. Sie gehen die nächsten Schritte eigenständig an und melden sich, wenn es zählt. Metas erklärte Begründung sind exakt die beiden Kosten von oben: Persistenz senkt die Latenz und reduziert den Bedarf an menschlichem Eingreifen bei schwierigen, mehrstufigen Aufgaben.
Worker parallel, Reviewer im Hintergrund
In der Praxis fühlt sich das an wie ein Team mit festen Rollen statt einer Schlange von Aushilfen. Worker setzen Änderungen parallel um; Reviewer kritisieren die Ergebnisse kontinuierlich im Hintergrund, bevor sie bei dir landen. Die Launch-Formulierung — „multi-agent by default“ — trifft es präzise: Koordination ist kein Modus, den du einschaltest, sondern die Art, wie jede Aufgabe läuft. Du lieferst schneller, nicht weil ein einzelner Agent schneller wäre, sondern weil Qualitätssicherung nebenläufig passiert statt als nachträglicher Gedanke.
Ins Modell trainiert, nicht drangeschraubt
Es gibt einen Grund, warum dieses Harness-Design mit Muse Spark 1.2 besser funktioniert, als es ein generischer Modell-Wrapper je könnte. Das Modell wurde gemeinsam mit dem Muse-Code-Harness trainiert — sein Trainingsrezept hat Subagenten-Verhalten explizit optimiert, neben Zielverfolgung und Kontext-Kompaktierung. Die Arbeitsteilung zwischen Hauptschleife und persistenten Spezialisten ist kein Prompt-Engineering-Trick, der obendrauf gelegt wurde; das Modell hat sie im Training gesehen. Daher stammen die Aussagen zu „weniger Retries, besserer Tool-Nutzung“ — ausführlich behandelt in unserem Beitrag zum Training von Muse Spark 1.2.
Was Persistenz nicht löst
Langlebige Agenten, die gleichzeitig dasselbe Repository bearbeiten, wären ein Rezept für Merge-Desaster — wenn sie sich eine Arbeitskopie teilen würden. Tun sie aber nicht. Fächert sich die Arbeit auf, bekommt jeder schreibfähige Kind-Agent seinen eigenen isolierten Git-Worktree, sodass parallele Arbeit nie auf Dateiebene kollidiert. Dieser Isolationsmechanismus verdient eine eigene Erklärung: Agent-Fan-out und Git-Worktrees. Und wenn du wissen willst, was einer dieser Agenten getan hat, während du nicht hingeschaut hast: Das Append-only-Event-Log hat die vollständige Antwort.