Enxame Autônomo de IA

Você pede a um agente de IA para construir uma feature de noite. Parece bom na teoria. Na prática, você acorda com metade de uma migração, dois arquivos quebrados e uma mensagem animada dizendo que a tarefa está completa.

Esse padrão de falha é comum. O agente não falhou porque o modelo é ruim. Falhou porque um único agente de longa duração precisa fazer trabalhos demais ao mesmo tempo: escolher a tarefa, manter o plano, editar o código, verificar o resultado e decidir se é seguro subir.

É exatamente isso que este post resolve. Abaixo está um Enxame Autônomo de IA. Dito de forma simples: orquestração automática de IA. Um gatilho dispara a cada 30 minutos. Um orquestrador lê o estado do projeto, distribui um ou vários especialistas e verifica cinco gates antes de qualquer coisa contar como feita.

As cinco formas como execuções noturnas de agentes falham

A maioria das demos "autônomas" esconde a parte difícil. Fazer um agente escrever código é fácil. Fazer ele continuar tomando decisões corretas por horas é a parte difícil.

Estes são os cinco modos de falha que aparecem primeiro.

1. Sem gatilho

Nada acorda o sistema na hora certa.

Você ainda precisa estar lá digitando o prompt. Ou inicia uma grande execução antes de dormir e torce para que sobreviva à noite. Se a execução travar depois de 20 minutos, tudo morre ali.

A correção é simples. Um gatilho temporizado. A cada 30 minutos, o sistema acorda, verifica o que aconteceu e decide o que fazer a seguir.

2. Sem roteamento

Um agente é forçado a ser gerente de projeto, arquiteto, engenheiro de frontend, engenheiro de backend, testador e revisor.

Parece eficiente. Não é. A mesma janela de contexto agora tem planejamento, implementação e verificação brigando por espaço. A execução deriva. O agente perde o controle do que está feito, o que está bloqueado e o que ainda precisa de prova.

A correção é separação de papéis. Um orquestrador roteia. Agentes especialistas executam. O cérebro de roteamento e o cérebro de trabalho param de atrapalhar um ao outro.

3. Sem guardrails

O agente escreve código e então marca a tarefa como completa porque o arquivo existe.

Isso não é o mesmo que subir. Um arquivo pode existir e ainda falhar type checks, falhar no lint, quebrar o build, vazar um segredo ou não ter testes.

A correção é uma pilha de gates. A execução não conta a menos que passe nas verificações que importam.

4. Sem prova

O agente diz que a feature está pronta, mas nada no sistema prova isso.

Esse é o mesmo problema que aparece em segurança de IA também. Uma descoberta sem prova é ruído. Uma feature sem prova é pensamento positivo.

A correção é verificação que roda em cada ciclo. O sistema precisa de um motivo para confiar no resultado que seja mais forte do que a confiança do próprio agente.

5. Sem memória entre execuções

Uma execução longa trava. Você reinicia. O próximo agente não sabe o que o último estava fazendo.

Aí você tem trabalho duplicado, edições conflitantes e resumos vagos em vez de progresso real. O sistema continua se movendo, mas está andando em círculos.

A correção é estado externo. O orquestrador lê a condição atual do projeto antes de cada ciclo e roteia a partir disso, não do que um agente lembra.

Por que um único agente não é suficiente

A resposta padrão é "deixa o agente continuar até os testes passarem."

Melhor do que um prompt único. Ainda não é suficiente.

Um único agente ajuda com persistência. Não resolve roteamento. Não resolve especialização. Não resolve o problema de um agente avaliar seu próprio trabalho. Não resolve o problema de decidir se deve planejar, construir, corrigir ou parar.

Essa é a diferença entre um trabalhador e um enxame.

Um único trabalhador fica repetindo uma tarefa.

Um enxame é um sistema pequeno que acorda, lê o estado, escolhe um papel, executa o trabalhador certo, verifica o resultado e avança ou dorme.

Por isso esse enxame não é um cluster distribuído, um control plane Kubernetes ou alguma "malha de agentes" abstrata. É muito mais simples. Uma máquina. Um repositório. Um gatilho temporizado. Um orquestrador. Um ou vários especialistas. Worktrees separadas são o modo paralelo quando o trabalho se divide de forma limpa.

A forma do enxame

Um enxame de orquestração de IA como esse tem cinco partes:

1. Gatilho: uma ativação a cada 30 minutos.
2. Orquestrador: uma sessão principal lê o contexto e escolhe o próximo passo.
3. Especialistas: planejador, construtor, designer, testador e guarda. O orquestrador pode direcionar um ou vários.
4. Gates: lint, tipos, build limpo, commit guard, suite de testes.
5. Resultado: se todas as verificações passarem, a feature está pronta. Se não, o enxame continua trabalhando ou dorme.

O fluxo completo:

30-minute trigger
      ↓
orchestrator reads state
      ↓
pick the next task
      ↓
dispatch one specialist or several
      ↓
run quality gates
      ↓
ship, continue, or sleep

A parte importante não é "mais agentes." A parte importante é que cada ciclo tem uma função.

Orquestradores separados importam aqui porque são o modo paralelo. Use quando o trabalho se divide em dois ou três recursos independentes com limites claros.

Passo 1: o gatilho

O gatilho é um ping a cada 30 minutos.

Você pode implementar isso com um cron job real do sistema. Pode implementar com tarefas agendadas do Claude Code Desktop. O ponto não é a marca do agendador. O ponto é a cadência.

A cadência faz duas coisas.

Primeiro, dá ao sistema mais de uma chance de se recuperar. Se uma execução morre às 2:07 da manhã, o próximo ciclo acorda às 2:30 e continua.

Segundo, mantém o sistema barato e legível. Você não precisa de um agente sempre ligado queimando tokens a cada segundo. Você precisa de um padrão de automação que acorda, decide, age e para.

Nessa configuração, o passo do gatilho se resume a uma linha:

Um cron job. Agenda o enxame inteiro.

Esse é o modelo mental certo. Um agendador. Não uma plataforma cloud.

Passo 2: o orquestrador

O orquestrador é o cérebro.

Ele não tenta fazer a feature inteira sozinho. Essa é a primeira regra.

O trabalho dele é ler o estado atual e responder a uma pergunta: qual é o próximo passo?

Essa pergunta é mais específica do que parece. O orquestrador não está inventando estratégia de produto. Está lendo contexto que já existe:

• qual tarefa foi tentada por último
• quais arquivos mudaram
• quais verificações passaram
• quais verificações falharam
• o que está bloqueado
• qual feature está mais perto de ficar pronta

Com esse estado em mãos, ele roteia o trabalho para o especialista certo, ou para vários especialistas se o trabalho se dividir de forma limpa.

Por isso o texto do carrossel diz:

Ele escolhe o próximo passo.

Essa frase importa porque define o orquestrador corretamente. Não é "o trabalhador principal." É o despachante.

Passo 3: os especialistas

Esse enxame usa cinco papéis especializados.

Pode renomeá-los. Os nomes não são o ponto.

O ponto é que cada agente tem um trabalho mais estreito do que "construir a feature." Isso reduz deriva e mantém o resultado mais consistente de ciclo em ciclo.

É também aqui que a maioria das configurações de times de agentes erra. As pessoas criam cinco agentes e dão o mesmo prompt para todos os cinco. Isso não é um time. É duplicação.

Um verdadeiro especialista só precisa do contexto necessário para o seu trabalho.

O planejador precisa da tarefa e do formato do projeto.

O construtor precisa dos arquivos alvo e dos critérios de aceitação.

O designer precisa dos requisitos de UI e das restrições dos componentes.

O testador precisa das condições de falha e das verificações.

O guarda precisa da política.

O orquestrador não precisa acordar os cinco toda vez.

Às vezes um especialista basta. Às vezes o trabalho se divide e o orquestrador distribui para vários especialistas em paralelo.

A versão limpa disso usa sessões isoladas ou Git worktrees separadas. Cada especialista recebe sua própria cópia do repositório, faz sua parte e evita pisar nos arquivos de outro especialista. É assim que o trabalho paralelo se mantém real em vez de bagunçado. Até detalhes básicos do repositório como .gitignore, .gitkeep, migrações, testes e arquivos de UI ficam mais fáceis de raciocinar quando cada trabalhador tem sua própria faixa.

É isso que "Um orquestrador. Um ou vários especialistas." significa na prática.

Como o trabalho paralelo se une de volta

Trabalho paralelo é útil até dois especialistas tocarem nos mesmos arquivos.

Por isso cada especialista trabalha na própria Git worktree. O branch principal fica limpo enquanto os especialistas constroem em paralelo.

Quando um especialista termina, o branch dele não faz merge diretamente. No modo separado, passa por um helper de merge limitado. Um branch por vez. Um branch alvo. Regras de fallback simples.

Se o merge estiver limpo, ele entra.

Se houver conflito, o sistema tenta três passos. Primeiro, um git merge limpo. Segundo, resolução automática determinística para os casos fáceis. Terceiro, uma resolução LLM por arquivo com rejeição rígida para output em prosa. Isso mantém o caminho de merge previsível.

Se nada disso funcionar, o merge para e o branch é marcado como falhado.

Isso importa. Um enxame não é "faz merge de tudo e torce." É trabalho paralelo com regras.

Passo 4: o caminho de execução full-stack

A fase de construção é onde o sistema mostra valor real.

Muitas demos de agentes param em "o agente escreveu um arquivo." O objetivo aqui é o oposto: um caminho do banco de dados até o output ao vivo.

Por isso a fase de build no enxame não é descrita como "escrever código." É descrita como:

Agentes executam a stack completa.

Num sistema assim, isso significa que o orquestrador pode rotear pelas camadas reais que uma feature real toca:

• trabalho de banco de dados
• lógica de backend
• páginas e ligação de UI
• polimento de design
• testes

Por isso o slide 4 termina com:

Banco de dados até o ar. Uma feature, zero passos manuais.

Esse também é o lugar certo para definir full stack em termos simples. Nesse sistema, não significa "toda tecnologia do mundo." Significa as camadas necessárias para tornar uma feature real do armazenamento até a tela.

Se o banco de dados muda mas a página não, a feature não está pronta.

Se a página muda mas os testes falham, a feature não está pronta.

Se tudo constrói localmente mas o commit guard sinaliza um segredo, a feature não está pronta.

O enxame continua se movendo por essas camadas até a cadeia fechar.

Passo 5: os cinco gates

A fase do guarda é o que torna o sistema confiável.

Sem ela, o enxame é só uma forma rápida de gerar trabalho quebrado.

Nossa pilha de gates tem cinco verificações:

Isso é o oposto exato de "deixa o agente subir e torce."

O texto aqui é direto por um motivo:

Nada sobe sem passar.

Não é slogan. É a regra.

Os cinco gates fazem dois trabalhos.

Primeiro, impedem código ruim de chegar ao main.

Segundo, dão ao orquestrador um sinal confiável sobre o que fazer a seguir. Se o type check falha, o próximo passo não é "celebrar." O próximo passo é "rotear uma correção."

Isso significa que os gates não são só verificações de segurança. São sinais de roteamento.

Como fica o resultado

O objetivo não é "o agente rodou por quatro horas."

O objetivo é: você volta e a feature está de fato pronta.

Por isso a última fase no enxame não se chama "resumo" ou "relatório." Chama-se resultado.

Uma execução noturna pode ter esse aspecto:

• 2:00 da manhã: planejou o sistema de autenticação
• 2:30 da manhã: construiu três endpoints de API
• 3:00 da manhã: rodou 47 testes
• 3:30 da manhã: fez deploy para produção

Essa sequência importa porque prova que o sistema está fazendo trabalho ordenado, não trabalho aleatório.

Um exemplo simples:

4 horas. Auth construída, testada e subida.

Esse é exatamente o formato de prova certo para um sistema de build autônomo. Curto. Concreto. Verificável.

Não "o modelo raciocinou muito bem." Não "o sistema parecia promissor." Uma feature cruzou a linha.

Como a automação funciona na prática

Essa parte importa porque "autônomo" significa pouco se o gatilho for vago.

A automação não é mágica. Começa com uma ativação agendada.

A versão mais simples é uma entrada de cron do sistema que inicia uma nova execução a cada 30 minutos. Conceitualmente fica assim:

*/30 * * * * cd /path/to/repo && claude -p "run the swarm orchestrator for the next task"

Isso é suficiente para criar a cadência.

Você também pode rodar o mesmo padrão com tarefas agendadas do Claude Code Desktop. Nesse modelo, o app Desktop mantém o agendamento e inicia uma nova sessão no intervalo escolhido. O trabalho funciona do mesmo jeito depois da ativação:

1. uma execução agendada começa
2. o orquestrador lê o estado atual do projeto
3. um especialista ou vários recebem a próxima tarefa
4. o resultado passa pelos quality gates
5. o sistema sobe, tenta novamente ou dorme

A escolha entre cron e tarefas agendadas do Desktop é operacional, não arquitetural.

Use cron se quer o gatilho mais simples no nível da máquina.

Use tarefas agendadas do Desktop se quer um agendamento visível, histórico embutido e uma nova sessão de Claude a cada vez sem precisar ligar shell scripts manualmente.

O que importa é que cada execução começa do zero e cada execução consegue ver o estado atual. É isso que torna o enxame durável em vez de frágil.

O que acontece quando nada está pronto

Um bom enxame automatizado precisa de um estado de sono.

Parece pequeno. Não é.

Se nada mudou, nenhum gate falhou e nenhuma feature está perto o suficiente para avançar, o orquestrador deve registrar o estado e parar. Não deve forçar trabalho só porque o agendador disparou.

É assim que você mantém o sistema limpo.

O gatilho cria oportunidade. Não cria urgência falsa.

Por que isso funciona melhor do que um framework genérico de agentes

A maioria dos frameworks genéricos de agentes dá as partes móveis mas não as regras de operação.

Você recebe ferramentas para criar agentes. Ferramentas para passar mensagens. A sensação de estrutura. E ainda precisa decidir:

• quando o sistema acorda
• que estado ele lê
• como ele escolhe a próxima tarefa
• como evita trabalho duplicado
• o que torna um passo completo
• o que bloqueia um deploy

Essas são as perguntas reais.

O enxame funciona porque as responde com antecedência.

Gatilho dá cadência.

Orquestrador dá roteamento.

Especialistas dão foco.

Gates dão prova.

Resultado dá uma linha de chegada.

Um framework genérico pode hospedar esse formato. Não pode substituí-lo.

Como construir a sua própria versão

Você não precisa de uma stack enorme para copiar isso.

Comece com esse formato mínimo:

one scheduler
one orchestrator
one or several specialists
three to five quality gates
one state file or report directory

Depois siga essas regras.

1. Mantenha o gatilho barato

Não rode um agente sempre acordado se um ping temporizado funciona.

Um ping a cada 30 minutos é suficiente para a maioria dos sistemas de build noturno. Dá comportamento de retry sem pagar por atividade constante.

2. Separe roteamento de execução

Não faça o orquestrador fazer o trabalho de implementação.

Se o cérebro também é o trabalhador, a qualidade do roteamento cai e o contexto fica confuso rápido.

3. Dê a cada especialista um trabalho estreito

Um agente não deve planejar, programar, projetar e verificar na mesma passagem.

Prompts estreitos são mais fáceis de avaliar, mais fáceis de tentar novamente e mais fáceis de substituir.

Se vários especialistas rodam em paralelo, dê a cada um um limite claro. Worktrees separadas são a versão mais limpa porque cada especialista edita seu próprio checkout em vez de brigar pelos mesmos arquivos.

4. Faça os gates bloquear, não avisar

Um quality gate que só escreve um aviso não é um gate.

Se o build está quebrado, o sistema precisa rotear uma correção em vez de fingir que a feature está completa.

5. Mantenha a prova fora do auto-relato do agente

O agente dizer "feito" não é prova.

Prova vem de verificações, testes, logs e builds bem-sucedidos. Sinais externos sempre superam confiança interna.

6. Durma de propósito

Se nada está pronto, registre o estado e durma.

Isso é mais importante do que parece. Sistemas ficam caros e bagunçados quando não conseguem decidir parar.

O que esse sistema realmente é

Resposta direta à sua pergunta: é um crontab?

No nível do gatilho, sim, tem formato de cron.

Há um agendador que acorda o sistema a cada 30 minutos. Esse agendador pode ser:

• uma entrada real de crontab na sua máquina
• uma tarefa agendada do Claude Code Desktop

O enxame não é só o agendador.

O fluxo completo é:

1. o agendador dispara
2. nova sessão acorda
3. o orquestrador lê o estado
4. o orquestrador escolhe o próximo passo
5. um especialista ou vários rodam
6. os gates verificam o resultado
7. o sistema sobe, tenta novamente ou dorme

Por isso a resposta certa não é "é um crontab" nem "é um framework de IA."

É um enxame autônomo de IA.

Um formato válido é:

main session -> route work -> sub-agents -> gates -> sleep

Outro formato válido é:

main session -> partition 2-3 independent features -> spawn isolated worktree sessions -> merge back safely

Mesma ideia. Orquestração automática de IA com papéis claros, regras de merge limitadas e uma linha de chegada.

Onde mais esse padrão se aplica

Uma vez que você vê o formato, dá para usar fora de builds de features.

O mesmo padrão de enxame funciona para:

• revisão de segurança
• auditorias de dependências
• produção de conteúdo
• triagem de analytics
• babysitting de PRs

O agendador acorda o sistema. O orquestrador verifica o estado. Um ou vários especialistas fazem o trabalho estreito. Os gates decidem se o output é bom o suficiente. Depois o enxame dorme.

Esse é o modelo completo.

Um ping. Um cérebro. Um ou vários especialistas. Cinco gates. Features prontas quando você acorda.