What “persistent background agents” means
Meta describes Muse Code as a simple main-agent loop supported by async background agents. These agents remain active through the session rather than being created only for a single subtask. They can take next steps independently and choose when to report back to the main agent.
Persistence can reduce duplicate discovery and waiting on difficult tasks, but it also means more work may happen outside the main conversational thread. Review and validation remain essential.
- Pattern
- Main + background Official runtime description
- Lifecycle
- Session-persistent Not per-small-task only
- Execution
- Async + parallel Can advance independently
- Fixed count
- Not published Overview page checked
Good evaluation tasks
| Task shape | Potential parallel work | Review focus |
|---|---|---|
| Cross-cutting feature | Explore UI, data, and test surfaces | Interface consistency |
| Large failing suite | Investigate independent failure clusters | Shared root causes |
| Repository migration | Map packages and compatibility risks | Integration order |
| Research-heavy fix | Trace call paths and documentation | Evidence quality |
Start with work that has separable questions and a crisp integration test. A vague request does not become well-scoped merely because more agents can work on it.
Questions the overview does not settle
The current product and launch pages do not specify a universal scheduler, token allocator, concurrency ceiling, or a single isolation strategy for every task. Meta’s broader cookbook contains multi-agent patterns, but those examples should not automatically be treated as the hidden implementation of Muse Code itself.
For the model relationship, read Muse Spark 1.2. For the audit and recovery layer that records actions around agent work, continue to event log and resume.