Waarom Muse Code zijn agents de hele sessie in leven houdt
De stille architectuurkeuze achter de snelheid van Muse Code: achtergrondagents die de volledige sessie blijven draaien, in plaats van per taak te worden opgestart en weggegooid.
Het spawn-en-weggooiprobleem
De meeste multi-agent-codetools volgen hetzelfde recept: komt er een taak binnen, dan wordt er een hulpagent opgestart, die krijgt een stuk werk toegeschoven, het resultaat wordt opgehaald en de agent gaat weer de prullenbak in. Een nette abstractie met een lelijk prijskaartje. Elke vers gestarte agent begint namelijk bij nul — die moet de repositorystructuur opnieuw doorlezen, het buildsysteem opnieuw ontdekken en de conventies van je codebase opnieuw leren. In een sessie met tien taken betaal je die context-verzameltaks tien keer.
En die taks bestaat niet alleen uit tokens. Het is ook latency — elke koude start vertraagt het eigenlijke werk — en het is stuurwerk, want een agent die vergeten is wat hij een uur geleden leerde, stelt je dezelfde vragen twee keer.
Het antwoord van Muse Code: persistentie
Muse Code is opgebouwd als een eenvoudige main-agent-loop plus een set asynchrone achtergrondagents — en die achtergrondagents blijven de hele sessie actief. Ze worden niet per taak aangemaakt. Elk van hen is gespecialiseerd, stapelt gedurende de sessie context op en bepaalt zelfstandig wanneer iets belangrijk genoeg is om terug te melden aan de main agent.
Dat laatste detail weegt zwaarder dan het klinkt. De achtergrondagents blokkeren de main loop niet in afwachting van instructies, maar overspoelen hem ook niet met statusupdates. Ze voeren vervolgstappen zelfstandig uit en melden zich als het ertoe doet. Meta’s eigen onderbouwing komt exact neer op de twee kostenposten hierboven: persistentie drukt de latency én vermindert de hoeveelheid menselijke bijsturing bij lastige taken met veel stappen.
Workers parallel, reviewers op de achtergrond
In de praktijk voelt dit als een team met vaste rollen in plaats van een rij uitzendkrachten. Workers voeren wijzigingen parallel uit; reviewers leveren op de achtergrond continu kritiek op de output vóórdat die jou bereikt. De framing bij de launch — “multi-agent by default” — is precies raak: coördinatie is geen stand die je aanzet, het is hoe elke taak draait. Je levert sneller op, niet omdat één losse agent sneller is, maar omdat kwaliteitscontrole tegelijkertijd gebeurt in plaats van achteraf.
In het model getraind, niet erop geschroefd
Er is een reden dat dit harness-ontwerp beter werkt met Muse Spark 1.2 dan een generieke modelwrapper zou doen. Het model is samen met de Muse Code-harness getraind — het trainingsrecept optimaliseerde expliciet op subagentgedrag, naast doelen en contextcompactie. De taakverdeling tussen een main loop en persistente specialisten is geen prompt-engineeringtruc die er bovenop is gelegd; het model heeft die tijdens de training gezien. Daar komen de claims over “minder retries, beter toolgebruik” vandaan, en we duiken er dieper in in ons artikel over hoe Muse Spark 1.2 is getraind.
Wat persistentie níét oplost
Langlevende agents die tegelijk dezelfde repository bewerken zouden een recept voor merge-rampen zijn — als ze één werkkopie zouden delen. Dat doen ze niet. Waaiert het werk uit, dan krijgt elke schrijvende child-agent een eigen geïsoleerde git worktree, zodat parallel werk nooit op bestanden botst. Dat isolatiemechanisme verdient een eigen uitleg: agent-fan-out en git worktrees. En wil je weten wat een van die agents nou eigenlijk heeft uitgespookt terwijl jij niet keek, dan heeft het append-only event log het complete antwoord.