Why Muse Code keeps its agents alive all session
The quiet architectural decision behind Muse Code’s speed: background agents that persist for the whole session instead of being spawned per task and thrown away.
The spawn-and-discard problem
Most multi-agent coding tools follow the same recipe: when a task arrives, spin up a helper agent, hand it a slice of work, collect the result, and tear it down. It’s a clean abstraction with an ugly cost. Every freshly spawned agent starts from zero — it has to re-read the repository structure, re-discover the build system, re-learn the conventions your codebase follows. On a session with ten tasks, that context-gathering tax is paid ten times.
The tax isn’t just tokens. It’s latency — each cold start delays the actual work — and it’s steering effort, because an agent that forgot what it learned an hour ago asks you the same questions twice.
Muse Code’s answer: persistence
Muse Code is built as a simple main agent loop plus a set of async background agents — and those background agents stay active throughout the session. They aren’t created for individual tasks. Each one is specialized, keeps accumulating context as the session progresses, and decides on its own when something is worth reporting back to the main agent.
That last detail matters more than it sounds. The background agents don’t block the main loop waiting for instructions, and they don’t flood it with status updates either. They carry out next steps independently and communicate when it matters. Meta’s stated rationale is exactly the two costs above: persistence reduces latency, and it reduces the need for human steering on difficult, multi-step tasks.
Workers in parallel, reviewers in the background
In practice you experience this as a team with standing roles rather than a queue of temps. Workers execute changes in parallel; reviewers continuously critique output in the background before it reaches you. The launch framing — “multi-agent by default” — is precise: coordination isn’t a mode you enable, it’s how every task runs. You ship faster not because any single agent is faster, but because quality control happens concurrently instead of as an afterthought.
Trained into the model, not bolted on
There’s a reason this harness design works better with Muse Spark 1.2 than a generic model wrapper would. The model was co-trained with the Muse Code harness — its training recipe explicitly optimized subagent behavior, alongside goals and context compaction. The division of labor between a main loop and persistent specialists isn’t a prompt-engineering trick layered on top; the model saw it during training. That’s where the “fewer retries, better tool use” claims come from, and it’s covered in depth in our post on how Muse Spark 1.2 was trained.
What persistence doesn’t solve
Long-lived agents editing the same repository concurrently would be a recipe for merge disasters — if they shared a working copy. They don’t. When work fans out, each write-capable child agent gets its own isolated git worktree, so parallel work never collides on files. That isolation mechanism deserves its own explanation: agent fan-out and git worktrees. And when you want to know what any of these agents actually did while you weren’t watching, the append-only event log has the complete answer.