# Muse Code's Multi-Agent Architecture: What Actually Changes When Child Agents Get Their Own Worktrees > Source: > Published: 2026-09-27 19:50:58+00:00 Most coding agents you've used are single-threaded in a specific sense: one agent, one working copy of the repo, one task at a time. Muse Code, Meta's CLI coding agent (launched August 2026, running on Muse Spark 1.2), is built differently, and the difference is worth understanding on its own terms, separate from anything else Meta says about Muse. Muse Code uses a parent/child architecture. The parent agent doesn't write code directly for most tasks. Instead, it spawns write-capable child agents, and each child gets its own git worktree, a separate working directory checked out from the same repository, rather than sharing one working copy. That one design choice removes a specific class of failure: two agents (or two async operations from the same agent) stepping on each other's uncommitted changes in a shared directory. If you've ever had two terminal tabs both editing the same repo and lost track of which one has the change you wanted, that's the failure mode this avoids by construction, not by locking or coordination logic, but because each child simply doesn't share a directory with any other child. Two other pieces matter as much as the worktree split: For a one-file, one-shot edit, this architecture is overkill, you don't need worktree isolation to change a function signature. It starts to matter once a task decomposes into genuinely parallel or long-running subtasks: a migration touching many files, a feature that needs backend and test changes that can proceed somewhat independently, or a long task that might get interrupted and needs to resume cleanly. That's a different problem than "make the model smarter at writing code," and it's worth noting that Meta's own materials acknowledge Muse Spark has gaps versus other labs' models on raw coding benchmarks. The worktree/reviewer/event-log architecture is an orchestration answer, not a model-quality answer, and it's fair to evaluate those two things separately. If you've used Muse Code on a task that actually exercised the parallel child-agent path (not just a single-file edit), I'd be interested in how the decomposition and merge behavior held up in practice, that's the part I haven't been able to evaluate from the outside. Sources: developer.meta.com Muse Code docs and blog (Aug 2026 launch).