Por que o Muse Code mantém seus agentes vivos a sessão inteira

O problema do “cria e joga fora”

A maioria das ferramentas de código multiagente segue a mesma receita: chegou uma tarefa, sobe um agente auxiliar, entrega um pedaço do trabalho, coleta o resultado e derruba tudo. É uma abstração limpa com um custo feio. Todo agente recém-criado começa do zero — precisa reler a estrutura do repositório, redescobrir o sistema de build, reaprender as convenções que o seu código segue. Em uma sessão com dez tarefas, esse pedágio de levantamento de contexto é pago dez vezes.

E o pedágio não é só em tokens. É latência — cada cold start atrasa o trabalho de verdade — e é esforço de condução, porque um agente que esqueceu o que aprendeu há uma hora faz a mesma pergunta duas vezes.

A resposta do Muse Code: persistência

O Muse Code é construído como um loop principal simples mais um conjunto de agentes assíncronos em background — e esses agentes em background ficam ativos durante toda a sessão. Eles não são criados para tarefas individuais. Cada um é especializado, vai acumulando contexto conforme a sessão avança e decide sozinho quando algo merece ser reportado ao agente principal.

Esse último detalhe importa mais do que parece. Os agentes em background não travam o loop principal esperando instruções, nem o afogam com atualizações de status. Eles executam os próximos passos de forma independente e se comunicam quando importa. A justificativa declarada pela Meta é exatamente os dois custos lá de cima: persistência reduz latência e reduz a necessidade de intervenção humana em tarefas difíceis de múltiplas etapas.

Workers em paralelo, revisores em background

Na prática, a experiência é a de um time com papéis fixos, não uma fila de temporários. Workers executam mudanças em paralelo; revisores criticam continuamente o resultado em background antes que ele chegue até você. O enquadramento do lançamento — “multiagente por padrão” — é preciso: coordenação não é um modo que você liga, é como toda tarefa roda. Você entrega mais rápido não porque algum agente individual é mais rápido, mas porque o controle de qualidade acontece em paralelo, e não como uma etapa tardia.

Treinado no modelo, não parafusado por cima

Existe um motivo para esse design de harness funcionar melhor com o Muse Spark 1.2 do que funcionaria um wrapper genérico de modelo. O modelo foi co-treinado com o harness do Muse Code — a receita de treinamento otimizou explicitamente o comportamento de subagentes, junto com objetivos e compactação de contexto. A divisão de trabalho entre um loop principal e especialistas persistentes não é um truque de engenharia de prompt colado por cima; o modelo viu isso durante o treinamento. É daí que vêm as alegações de “menos tentativas, melhor uso de ferramentas”, e o assunto é tratado a fundo no nosso post sobre como o Muse Spark 1.2 foi treinado.

O que a persistência não resolve

Agentes de vida longa editando o mesmo repositório ao mesmo tempo seriam receita para desastres de merge — se compartilhassem uma cópia de trabalho. Eles não compartilham. Quando o trabalho se espalha em fan-out, cada agente filho com permissão de escrita ganha sua própria git worktree isolada, então trabalho paralelo nunca colide em arquivos. Esse mecanismo de isolamento merece explicação própria: fan-out de agentes e git worktrees. E quando você quiser saber o que qualquer um desses agentes realmente fez enquanto você não estava olhando, o event log append-only tem a resposta completa.