Sete agentes de IA tocam as nossas noites: agentes agendados além do código, com os prompts

Em 23 de setembro, um usuário chamado Rob escreveu no nosso backlog público: “would love to get examples of how you guys are doing stuff beyond coding”. Pergunta justa. Tudo neste site fala de agentes de código, e o que realmente rodamos toda noite, na maior parte, não é código.

Desde 28 de agosto, sete agentes começam em um Mac mini às 20:00. Eles leem os commits do dia, o Search Console, os painéis de administração, o backlog, o feedback que as pessoas enviaram, os relatórios da noite anterior. Corrigem bugs, corrigem o site, escrevem e traduzem um artigo de blog a cada três dias, publicam em três redes sociais, atualizam uma base de conhecimento do produto, e às 22:00 o sétimo lê o que os outros seis deixaram e envia um e-mail de 25 linhas. Ninguém fica olhando. O fundador lê o e-mail no celular na manhã seguinte.

Este artigo é a resposta ao Rob. O que roda, como está ligado, como os agentes passam o trabalho entre si sem nunca conversar, qual modelo faz qual função e por quê, as quatro regras que os prompts tiveram de aprender do jeito difícil, e os próprios prompts, condensados em blocos que você pode copiar. Cada número abaixo vem do repositório: os relatórios estão lá com commit, noite após noite.

O que 33 noites produziram

A pasta de relatórios do repositório tem 33 diretórios datados, de 28 de agosto a 30 de setembro. Lendo-os, temos isto:

• 31 e-mails matinais enviados pelo relator.
• 51 bugs corrigidos pelo corretor, cada um com o link do commit na sua linha do relatório. Vários tinham sido reportados por usuários no backlog público e receberam uma resposta na versão seguinte.
• 7 artigos de blog escritos pela equipe de SEO desde 10 de setembro, um a cada três dias, cada um primeiro em inglês e em francês, depois em mais 18 idiomas na mesma noite.
• 29 dias de diário de redes sociais: três redes e cinco grupos do Facebook por noite, mais um comentário de agradecimento em cada post em que um usuário compartilhou o AgentsRoom.
• Uma base de conhecimento do produto com cerca de cem fichas, mantida em sincronia com os commits do dia, que o assistente do app lê e que o site serve como llms-full.txt.

Nada disso exigiu um humano depois das 20:00. Uma parte exigiu um humano às 08:00, e esse é todo o propósito do último agente.

O elenco: quem roda às 20:00

Cada agente é uma Tarefa agendada no AgentsRoom: um prompt, um agente (papel, CLI, modelo), uma máquina e um horário. Os sete rodam no Claude Code. Dois deles não são agentes isolados, e sim equipes de duas etapas, e vamos voltar ao porquê.

Os arquivos .md da última coluna ficam todos em reports/night/<date>/, com commit e push. Essa pasta é todo o sistema de coordenação, e a próxima seção explica por quê.

Como está ligado

Cada um dos sete é uma Tarefa agendada com o mesmo formato:

• Dispara todo dia às 20:00 (22:00 para o relator). Nenhuma expressão cron; a frequência é escolhida no editor.
• Fixada em uma única máquina. O projeto está aberto em vários computadores, e um gatilho dispara em cada máquina que o tem, a menos que você o restrinja. Os nossos estão restritos ao Mac mini, então um laptop aberto às 20:05 não inicia um segundo CEO.
• Acorda a máquina. O Mac mini entra em repouso. A tarefa tem uma opção “acordar a máquina”, que agenda um despertar com a ferramenta do próprio sistema operacional (pmset no macOS, o Agendador de Tarefas com despertar para executar no Windows, rtcwake no Linux) alguns segundos antes da execução. Sem ela, uma máquina em repouso simplesmente perde a execução.
• Recuperação ligada ou desligada, por tarefa. Se a máquina estava desligada às 20:00, uma tarefa com recuperação ligada dispara na próxima inicialização. O CEO, o PM e o relator estão com ela ligada. As tarefas de SEO, corretor, social e documentação estão com ela desligada: uma execução que começasse às 11:00 da manhã seguinte colidiria com o trabalho do dia no mesmo checkout.
• O modo de permissão é definido na tarefa, não no provedor. Uma execução sem supervisão não pode parar num pedido de aprovação às 3 da manhã, então a tarefa roda sem eles, enquanto os agentes que o fundador conduz à mão no mesmo CLI continuam perguntando antes.
• O console fecha após 60 minutos de inatividade. Um agente que terminou não fica na barra lateral até alguém fechá-lo.
• O prompt é a primeira mensagem. O texto de cada prompt fica guardado na Biblioteca de prompts e é o mesmo texto do campo prompt do gatilho, então editar um é editar os dois. Os prompts estão em francês, porque o fundador lê os relatórios em francês. Todo o resto, das mensagens de commit à base de conhecimento, está em inglês.

Uma última peça é compartilhada pelos sete: uma skill chamada “agentes noturnos, regras comuns”. Cada prompt começa com “carregue esta skill e aplique-a”, e a skill contém tudo o que vale para todos: quem cuida do quê, a trava “uma noite, uma execução”, os direitos no git, o formato do relatório, as regras do backlog e o formato do e-mail para o relator. Quando uma regra muda, ela muda em um só lugar.

Como passam o trabalho entre si sem conversar

Os sete agentes nunca trocam mensagens. Poderiam, o AgentsRoom tem mensagens entre agentes, mas uma mensagem fica invisível na manhã seguinte e não dá para fazer grep nela. Tudo passa por três coisas que sobrevivem à noite:

O repositório. Cada agente escreve reports/night/<date>/<agent>.md, abre o arquivo no primeiro minuto da execução, reescreve-o depois de cada trabalho concluído, faz commit e push. O relatório tem quatro seções fixas: “Em duas palavras” (uma lista de tópicos, um tópico por coisa feita), “A decidir” (só o que o prompt reserva ao humano), “A verificar” (uma URL local ou uma tela para abrir), “Detalhes” (do tamanho que for preciso). Ele termina com um marcador de execução: o último commit que o agente viu.

O backlog. Um agente que encontra trabalho para outro não faz esse trabalho. Ele abre um ticket com uma tag: ceo-fix para um bug pequeno e verificado que o corretor vai pegar; ceo-seo para uma tarefa de conteúdo com a sua busca-alvo; ceo-decision para tudo o que precisa do humano (banco de dados, cobrança, auth, criptografia, preços, uma URL indexada, um comportamento padrão). O documentalista, lendo os commits, encontra uma feature sem página no site: abre um ticket ceo-seo, e o SEO pega na noite seguinte. O CEO, lendo os logs de erro, encontra um bug com a causa no código: ceo-fix, e o corretor pega na noite seguinte.

O relatório de ontem. Antes de abrir qualquer tarefa, cada agente lê o próprio relatório da noite anterior, mais a lista de tickets fechados durante o dia. O que ele sinalizou ontem muitas vezes já foi corrigido durante o dia. Um assunto já tratado não é levantado de novo; um ticket já aberto não é recriado.

O ciclo se fecha com o humano. O e-mail do relator termina com uma linha: para responder ao product manager, adicione uma seção “## Decisões” no fim de rapport.md (P1 OK / P2 NÃO: motivo / P3 DEPOIS), commit, push. O PM lê a versão enviada na noite seguinte e executa o que foi aprovado: cria o ticket, mescla os duplicados, estaciona o resto com o motivo. Uma decisão que fica três noites sem resposta é uma decisão: a proposta sai do e-mail e fica como ticket.

Qual modelo faz qual função, e por quê

A tabela acima mostra dois modelos. É a configuração atual, não um benchmark, e ela muda. Mas a divisão é deliberada.

Fable onde a função é julgamento. O CEO decide se um polegar para baixo num oráculo é um erro real ou uma preferência. O corretor decide se um relato de bug é um bug ou uma configuração específica de uma máquina, e depois encontra a causa no código. A etapa 1 do SEO decide qual frase do site ficou errada com o commit de hoje, qual artigo escrever e qual página deixar em paz. A etapa 1 do Social escolhe o assunto da noite e escreve para um público que identifica um texto gerado em três linhas. Esses prompts são longos (o do SEO tem cerca de 4.000 palavras) e cheios de regras “você decide, não pergunta” com listas curtas de exceções. É aí que o modelo mais forte justifica o seu custo.

Opus com um contexto de 1M onde a função é volume. Traduzir um artigo para 18 idiomas com subagentes, três locales cada um, e depois conferir a mesclagem com a referência em francês, é leitura e escrita, muita, com as mesmas regras aplicadas 18 vezes. O documentalista lê um dia de diffs contra cerca de cem fichas. O PM lê uma exportação de 8 MB de conversas de saída. O relator lê cinco relatórios e copia, ele não pensa. Ali, um contexto grande e um custo por token menor importam mais do que o julgamento.

Dois dos sete são, portanto, equipes de duas etapas, cada etapa um agente com o seu próprio modelo. A etapa 1 no Fable termina escrevendo uma seção “Passagem” no relatório compartilhado: a lista exata de arquivos e chaves que o tradutor precisa entregar, ou os posts exatos que o publicador precisa publicar. A etapa 2 no Opus lê essa seção e faz só o que ela lista. O grafo da equipe é linear, um único ciclo, e o relatório mantém a sua linha “execução em andamento” até a etapa 2 removê-la. Vendo de fora, às 22:00, um relatório ainda marcado “em andamento” significa ou uma execução cortada ou uma equipe entre as suas duas etapas, e o relator diz qual das duas.

As quatro regras que os prompts tiveram de aprender

Os primeiros prompts eram descrições de cargo. Os atuais são sobretudo regras, e cada regra tem uma data, porque cada uma foi escrita depois de uma noite que deu errado.

1. Um marcador de execução, lido no relatório de ontem. A primeira versão do agente de SEO lia “os commits das últimas 24 horas”. Dois problemas: uma execução às 20:00 e uma às 20:10 no dia seguinte não veem as mesmas 24 horas, e uma noite em que o agente não rodou é um dia de commits que ninguém olha. Agora cada relatório termina com Último commit visto: <sha>, e a execução seguinte parte desse commit, não importa o que o relógio diga. Sem marcador (primeira noite, relatório ausente): dois dias para trás, e o relatório diz isso.

2. O histórico está no disco, então faça grep nele antes de levantar qualquer coisa. A reclamação que mais voltou nas duas primeiras semanas: “você já me disse isso, eu corrigi ontem”. A correção é uma regra com um comando dentro: antes de sinalizar um assunto ou abrir uma tarefa, grep -ril "<o assunto>" reports/night/ e git log --since="30 days ago" -- <o arquivo>. Uma correspondência significa ler esse relatório primeiro. Três casos, e só três, permitem voltar a falar de um assunto tratado: a correção não funcionou e você acabou de verificar; a correção é parcial e você nomeia o que falta; o assunto mudou de natureza. Dois corolários vieram junto. Uma noite, uma execução: se o relatório desta noite existe, contém “Em duas palavras” e não diz mais “execução em andamento”, o agente para. E uma proposta sem resposta por três noites sai do relatório; o ticket fica.

3. O relatório é aberto antes de o trabalho começar. Uma execução cortada às 21:30 não deixava nada. Agora a primeira coisa que um agente faz depois de carregar a skill é mkdir -p reports/night/$(date +%F) e escrever o esqueleto do relatório com os quatro títulos de seção e uma linha execução em andamento, iniciada às 20:01. Ele reescreve o arquivo inteiro depois de cada tarefa concluída. Uma execução cortada deixa um relatório parcial que o relator pode copiar, o que é muito melhor do que um agente que “não rodou”.

4. Commit ao longo do caminho, nunca no fim. Medido em 9 de setembro: dois agentes foram parados no mesmo minuto. O que fazia commit depois de cada tarefa não perdeu nada. O outro deixou 45 arquivos modificados, sem push e impossíveis de atribuir, que o fundador recolheu à mão na manhã seguinte, e o seu relatório não existia. Desde então a regra é um commit por tarefa concluída, arquivos nomeados um a um, um último commit para o relatório, e pelo menos um push durante a execução. Um commit também é um rastro datado, e é nisso que a regra 2 faz grep.

Uma quinta regra não é sobre memória, e sim sobre coragem, e é a que mais mudou o resultado. O prompt do SEO diz: “Você não é um auditor que reporta constatações: de noite, o site é seu. Uma execução que termina com seis pistas para validar é uma execução fracassada.” Depois ele lista os seis casos, e só seis, em que o agente deve perguntar em vez de agir: excluir ou renomear uma URL, mudar o título de uma página que ranqueia, texto jurídico, um preço ou uma quota, uma afirmação sobre privacidade ou criptografia, uma mudança que mexa em mais de cinco páginas. Todo o resto, ele faz, e o fundador remove o que não gosta na manhã seguinte. O corretor tem a mesma regra com três casos. Antes dessa regra, os relatórios eram listas de sugestões. Depois dela, são listas de commits.

Os prompts

Os originais estão em francês e são longos. O que vem a seguir é a parte que se transpõe, sem os nossos caminhos e nomes próprios do projeto. Três blocos: as regras comuns que todo agente carrega, o relator, e as duas seções “você decide, não pergunta”.

Bloco 1: as regras comuns (carregadas pelos sete como uma skill)

# Agentes noturnos: regras comuns
Elas prevalecem sobre o seu próprio prompt se os dois se contradisserem.

## Uma noite, uma execução
DAY=$(date +%F); F=reports/night/$DAY/<você>.md
Se F existe, contém “Em duas palavras” e não contém mais “execução em andamento”:
pare. Não escreva nada, não envie nada, termine com uma mensagem de uma linha.
Se ainda diz “execução em andamento”: é a sua própria execução, cortada há alguns minutos.
Retome de onde ela parou, não recomece do zero.

## O que você pode fazer
- Git: add <arquivos nomeados>, commit, push do SEU trabalho, ao longo do caminho.
  Nunca: add -A, commit -a, push --force, stash, reset, checkout, clean, branch novo.
- Build: typecheck, lint, scripts de verificação, um build local para conferir.
  Nunca: um script que faça deploy ou publique.
- Backlog: criar um ticket, acrescentar a um ticket, fechar um ticket que você corrigiu.
  Nunca: responder a um usuário (isso envia um e-mail), excluir um ticket, sobrescrever uma descrição.
- Nunca um número inventado. Fonte indisponível: diga isso e siga em frente.
- Antes de qualquer escrita no git: git status --short. A árvore é compartilhada com outros agentes.

## Atualizar-se, e saber o que JÁ foi feito
git fetch && git status -sb
Atrasado e limpo: git pull --ff-only. Atrasado e sujo: não faça pull, diga isso no topo do seu relatório.
O seu marcador de execução: a linha “Último commit visto: <sha>” no fim do relatório de ontem.
Sem marcador: --since="2 days ago", e diga isso.
Três leituras obrigatórias antes de qualquer análise:
1. git log --no-merges --format='%h %s' <sha>..HEAD e git diff --stat <sha>..HEAD
2. os tickets fechados desde ontem, e os tickets que um humano colocou em espera
3. o seu próprio relatório de ontem: “Em duas palavras” e “A decidir”

## A pasta de relatórios É o seu histórico
Antes de levantar uma constatação ou abrir uma tarefa:
grep -ril "<assunto>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <o arquivo>
Uma correspondência: leia esse relatório antes de decidir qualquer coisa.
Duas noites seguidas no mesmo assunto: a segunda é desperdiçada.
Uma página ou um texto que você mexeu não é mexido de novo por três semanas,
a não ser para corrigir algo que ficou errado.

## Nunca levante a mesma coisa duas vezes
Uma constatação já tratada que volta no dia seguinte é uma falha.
Só três casos permitem isso:
1. a correção não funcionou, e você acabou de verificar: “corrigido em <data> por <commit>, ainda quebrado: <prova>”
2. a correção é parcial: nomeie exatamente o que falta
3. o assunto mudou de natureza: nova causa, nova medida, novo escopo
Não reconte um estoque. Informe a variação, nunca o estoque.

## Uma proposta sem resposta morre depois de três noites
Noites 1 a 3: a linha leva o seu contador e a primeira data (“2ª noite, levantada em 07/09”).
A partir da 4ª: ela sai de “A decidir”. O ticket fica; no máximo uma linha em “Detalhes”.
Se a decisão está no seu escopo, decida na 3ª noite e diga isso.

## Commit e push ao longo do caminho
Primeiro commit assim que a primeira tarefa estiver concluída e verificada. Depois um por tarefa.
Último commit para o seu relatório. Faça push pelo menos uma vez durante a execução e uma vez no fim.
Push recusado (o remoto avançou): git pull --ff-only, depois push. Ainda recusado: não force,
não faça rebase, escreva isso no relatório.

## O seu relatório: aberto no início, nunca escrito só no fim
reports/night/<YYYY-MM-DD>/<você>.md, criado ANTES do trabalho, com:
  # <Agente> - <data>
  _execução em andamento - iniciada às <HH:MM>_   (removida no fim)
  ## Em duas palavras  (3 a 5 linhas, ou uma lista de tópicos: um tópico por coisa feita)
  ## A decidir         (só o que o seu prompt reserva ao humano; senão “Nada”)
  ## A verificar       (- [ ] o quê : onde : o que se deve ver; senão “Nada”)
  ## Detalhes          (do tamanho que for preciso: provas, arquivos, comandos)
  ## Marcador de execução
  Último commit visto: <git rev-parse HEAD depois do seu último commit>
Reescreva o arquivo inteiro depois de cada tarefa concluída.
O leitor está num celular, por dois minutos: frases curtas, sem caminhos de arquivo,
sem SHA, sem nomes de função na primeira seção. Um número só se ele mudar uma decisão.

Bloco 2: o relator (22:00)

Você é o relator. Você roda duas horas depois dos outros.
O seu único trabalho: ler o que eles deixaram e enviar UM e-mail que o fundador lê
em um minuto num celular, e entende sem abrir mais nada.
Você não analisa nada, não corrige nada, não propõe nada. Você reúne e esclarece.

A noite que você relata é lida no disco, não no relógio:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only se a árvore estiver limpa: os relatórios têm commit.
2. ls reports/night/$DAY: espere os cinco arquivos (ceo, seo, pm, fixer, social).
   Faltando algum: sleep 9 minutos e reconte, no máximo 6 rodadas. Depois envie mesmo assim, nomeando quem falta.
3. Um relatório que ainda diz “execução em andamento” é uma execução cortada, não ausente.
   Copie o que ele contém e escreva em “O que não funcionou” que esse agente foi cortado.
4. De cada relatório pegue só três seções: “Em duas palavras”, “A decidir”, “A verificar”.
   Nunca cite “Detalhes”.
5. Os bugs corrigidos do corretor são tópicos em três partes separados por " > ":
   o que o usuário sofria > a causa em uma frase > a URL do commit.
   Copie-os caractere por caractere, link incluído, em “Bugs corrigidos”.
6. git status -sb e git log --oneline --since="4 hours ago": um relatório que declara
   trabalho sem commit, arquivos modificados que ninguém reivindica, ou commits sem push: primeira linha do e-mail.

Escreva reports/night/$DAY/rapport.md. No máximo 25 linhas de texto
(títulos de seção e linhas de “Bugs corrigidos” não contam).
Seis regras, aplicadas linha por linha:
1. Um tópico = uma frase completa que se entende sozinha. Nunca “como relatado ontem”.
2. Um assunto aparece em UMA seção só.
3. Zero jargão: sem caminho, sem SHA, sem nome de chave, sem abreviação interna.
   Uma exceção: a URL completa do GitHub de um commit, obrigatória em cada linha de “Bugs corrigidos”.
4. Um número só se ele mudar uma decisão, e é uma variação, nunca um estoque.
5. No máximo duas linhas por tópico. O detalhe está no relatório do agente.
6. Notícia ruim antes da boa, e a primeira linha diz se algo está quebrado.

Seções, em ordem: A decidir / A verificar / Bugs corrigidos / O que foi feito /
Redes sociais (3 linhas no máx., links incluídos) / CLIs e modelos (1 linha) /
O que não funcionou. Uma seção vazia é uma palavra: “Nada”.
Nunca corte: “A decidir”, “Bugs corrigidos” com os links, os links dos posts, o artigo de SEO.
Envie. Verifique o código HTTP. Acrescente “Enviado para ... - HTTP <code>” no final.
Commit e push de rapport.md. Nunca envie duas vezes: se o rapport.md de hoje já tem
uma linha “Enviado para”, pare.

Bloco 3: as seções “você decide, não pergunta”

O agente de SEO, seção 0 do prompt dele:

# 0. Você decide, não pergunta
Esta é a regra mais importante deste prompt e ela prevalece sobre o seu reflexo de cautela.
Você não é um auditor que reporta constatações: de noite, o site é seu.
Uma execução que termina com “aqui estão 6 pistas, para validar” é uma execução fracassada.
Quando hesitar, coloque-se no lugar do fundador e decida com quatro referências:
- o que o produto realmente faz, lido no repositório e na versão publicada, nunca no texto existente;
- o que o site já diz: o seu ângulo, o seu tom, as suas promessas. Você prolonga, não reinventa;
- o que o Search Console diz: quais páginas estão vivas, quais intenções existem de verdade;
- o público: desenvolvedores que buscam no Google, e os assistentes de IA que recomendam ferramentas.
  O que conta para eles: uma afirmação verificável e datável; uma página que responde a uma pergunta precisa;
  um llms.txt atualizado e coerente com as páginas; comparações honestas.
O fundador lê o seu relatório na manhã seguinte e vai dizer para você remover o que ele não gostar.
Uma correção a mais custa cinco minutos; uma noite sem resultado está perdida para sempre.

Você só pede a opinião dele nestes seis casos:
1. excluir ou renomear uma URL existente;
2. mudar o título ou a meta description de uma página que ranqueia, quando não está errado;
3. texto jurídico (termos, privacidade, licença);
4. um preço, uma quota comercial, uma oferta;
5. uma afirmação sobre privacidade, criptografia ou onde os dados são processados;
6. uma mudança que mexeria em mais de cinco páginas de uma vez.
Nesses seis casos: um ticket com tag para decisão, uma linha em “A decidir”, e você segue em frente.
Todo o resto, você faz esta noite. Se “A decidir” contém outra coisa,
você delegou uma decisão que era sua.

O corretor, seção 0 do prompt dele:

# 0. Você corrige, não classifica
Um bug reportado por um usuário é uma promessa. Alguém teve o trabalho de escrever, está esperando,
e ninguém mais vai cuidar disso esta noite. Uma execução que devolve “5 bugs analisados, 1 corrigido,
4 documentados” é uma execução fracassada. O seu objetivo é a fila vazia: os bugs dos usuários primeiro,
do mais antigo para o mais recente, depois o resto, até não sobrar nenhum.
Quando hesitar sobre uma correção, decida com três referências:
- o que o código faz hoje, lido, não suposto;
- o que o usuário claramente esperava ao escrever o relato;
- o menor risco: a correção mais estreita que resolve a causa, não a mais elegante.
Uma correção discutível custa cinco minutos para desfazer; um bug deixado mais um mês custa um usuário.

Você só pode deixar um bug reportado sem correção em três casos, comprovados no ticket:
1. você não encontrou a causa depois de uma investigação de verdade: escreva o que você eliminou,
   não apenas “não reproduzível”;
2. não é um bug, é uma decisão: banco de dados, cobrança, auth, criptografia, privacidade,
   uma URL indexada, um comportamento padrão. Ticket para decisão, com a sua recomendação;
3. uma verificação recusa a sua correção e você não consegue consertá-la.
“É grande”, “mexe em vários arquivos”, “prefiro perguntar” não são motivos.
Um bug = um commit. Depois o ticket vai para concluído, e se um usuário o reportou,
uma mensagem de duas frases fica na fila para a próxima versão. Nunca “em espera”: essa coluna
pertence aos humanos.
A sua linha de relatório para cada bug corrigido, copiada literalmente no e-mail da manhã:
- <o que o usuário sofria> > <a causa, em uma frase simples> > <URL do commit>

Os outros quatro prompts (CEO, PM, documentalista, etapa 2 do SEO) seguem o mesmo esqueleto: carregue a skill, nomeie os arquivos que você pode escrever, liste as leituras em ordem, diga o que vai no ticket e o que vai no relatório, termine com o marcador de execução.

O que não funcionou, e ainda não funciona

Algumas noites aparecem na seção “O que não funcionou” do e-mail, e vale a pena listá-las porque é com isso que você vai esbarrar.

• Cinco agentes fazendo push no mesmo branch no mesmo minuto. Um push é recusado porque o remoto avançou. A regra é git pull --ff-only e depois push, nunca forçar, e se falhar duas vezes o relatório diz isso e o humano faz o push de manhã. Acontece mais ou menos uma vez por semana.
• Um commit que levou junto um arquivo em staging de outro agente. Em 29 de setembro, o primeiro commit do SEO levou uma exclusão que o documentalista tinha colocado em staging no checkout compartilhado. Nada se perdeu (a exclusão era intencional), mas o commit ficou atribuído ao agente errado. Desde então cada commit usa caminhos explícitos, e a regra “arquivos nomeados um a um” não é uma preferência de estilo.
• Um disco que chegou a zero bytes livres às 20:10, duas noites seguidas. Externo aos agentes, se recuperou sozinho às 20:25, nenhum arquivo perdido. Mas os relatórios dizem isso, porque uma noite com o disco cheio parece exatamente uma noite em que um agente não fez nada.
• O relator esperando 54 minutos por um relatório que não vai chegar. Seis rodadas de nove minutos é o limite. Uma equipe entre as suas duas etapas às 22:00 parece uma execução cortada, e o e-mail diz “não tinha terminado”, o que é honesto e um pouco alarmante de ler.
• As primeiras semanas de constatações repetidas. A regra 2 acima não existia até o fundador escrever “você me disse isso três dias atrás” pela quarta vez.

Como montar isso você mesmo

Você não precisa de sete agentes. Precisa de um que escreva um relatório que você vai ler, e um relator só é útil a partir do terceiro agente. No AgentsRoom:

1. Escreva o prompt na Biblioteca de prompts. Comece pelo bloco 1 acima como skill, e um prompt curto que diga do que esse agente cuida e quais arquivos ele pode escrever.
2. Crie uma Tarefa agendada no projeto: diária no horário que você quiser, o papel, o CLI e o modelo do agente, o prompt, e no bloco avançado o modo de permissão para uma execução sem supervisão. Fixe-a na máquina que vai rodá-la, e ative “acordar a máquina” se essa máquina entra em repouso.
3. Crie a pasta reports/night/ no repositório e faça commit dela. Essa é toda a camada de coordenação.
4. Adicione um segundo agente no dia em que o primeiro começar a produzir tickets para outra pessoa: uma tag ceo-fix só significa algo quando um corretor a lê na noite seguinte.
5. Quando uma função se divide em julgamento e volume, transforme-a numa equipe de duas etapas com dois modelos, e faça a etapa 1 escrever uma seção de passagem que a etapa 2 lê.

A página de Tarefas agendadas descreve os campos, e o artigo sobre colocar agentes de código no turno da noite é o raciocínio que veio antes do elenco. Se os seus agentes compartilham uma máquina, leia primeiro o que acontece quando dez deles rodam o mesmo comando: aconteceu aqui, de noite, e a correção é um pequeno lock compartilhado.

Rob, é isso que fazemos além do código. Os prompts são o produto.

Perguntas frequentes

Preciso do AgentsRoom para rodar agentes em horário fixo assim?

Não. Uma linha de cron e claude -p iniciam uma sessão do Claude Code às 20:00 em qualquer máquina. O que você mesmo escreve depois é o resto: acordar um computador em repouso, recuperar uma execução que a máquina perdeu, manter uma única execução por noite quando o projeto está aberto em dois computadores, passar um relatório de um agente para um segundo agente com outro modelo, e ver no celular que a execução está travada numa pergunta. As Tarefas agendadas do AgentsRoom cuidam dessas peças, e os sete agentes deste artigo usam todas elas. Os prompts e as regras se transpõem do jeito que estão, seja o que for que inicie a sessão.

Quanto custa uma noite de sete agentes?

Eles rodam como sessões do Claude Code em uma assinatura do Claude, como qualquer agente que você inicia no AgentsRoom, então não há fatura por token para eles, e não publicamos um custo por noite. A regra que mantém isso sob controle é a trava “uma noite, uma execução”: um gatilho que dispara duas vezes, ou uma execução cortada e reiniciada, não refaz o trabalho, porque a primeira coisa que cada agente faz é verificar se o relatório desta noite já existe e está fechado.

É seguro deixar agentes fazerem commit e push sem ninguém olhando?

É seguro por causa do que eles não têm permissão de fazer, não por causa do que pedimos que eles queiram. As regras comuns proíbem git add -A, commit -a, push forçado, stash, reset, checkout, clean, criar um branch e qualquer script que faça deploy. Cada commit nomeia seus arquivos um a um, a árvore é inspecionada com git status antes de qualquer escrita, e um push recusado porque o remoto avançou é resolvido com um pull em fast-forward ou fica para o humano. A revisão da manhã é a lista de commits da noite, e o que estiver errado é um revert de cinco minutos.

Por que os agentes escrevem relatórios em Markdown no repositório em vez de um painel?

Porque o relatório também é a memória. Cada agente começa lendo o próprio relatório da noite anterior, encontra ali o seu marcador de execução (o último commit que viu), e faz um grep em toda a pasta de relatórios antes de levantar qualquer coisa, então um assunto tratado na semana passada não é levantado de novo. Um painel mostraria os mesmos números e não lembraria de nada. Fazer commit do relatório também o data, e é isso que permite à noite seguinte saber exatamente o que a anterior mexeu.

Por que dois dos sete agentes são equipes de duas etapas com dois modelos diferentes?

Porque as duas metades do trabalho não são o mesmo trabalho. A etapa de SEO que lê o Search Console, decide o que está errado no site e escreve o artigo em inglês e em francês exige julgamento, e roda no Fable. Traduzir esse artigo para outros 18 idiomas, passar pelas verificações de i18n e pelo build é volume, e roda no Opus com um contexto de 1M. A primeira etapa escreve uma seção de passagem explícita no relatório compartilhado, a segunda faz só o que essa seção lista. A mesma divisão para a equipe Social: redação e visual no Fable, publicação no Chrome e agradecimentos no Opus.

O que acontece quando uma execução é cortada no meio?

O relatório existe desde o primeiro minuto da execução, com uma linha que diz “execução em andamento”, e cada trabalho concluído recebe commit na hora. Então uma execução cortada às 21:40 deixa um relatório parcial, os seus commits e nenhum arquivo não rastreado. O relator copia o relatório parcial e escreve que o agente foi cortado. Aprendemos isso do jeito difícil em 9 de setembro: dois agentes pararam no mesmo minuto, o que fazia commit ao longo do caminho não perdeu nada, o outro deixou 45 arquivos modificados que ninguém conseguia atribuir.