Executei 1.000 agentes de IA usando 6 passos, 5 prompts e 1 arquivo (Guia do Desenvolvedor)

O ato de criar prompts morreu em 2024. A nova habilidade é a Orquestração

Eu executei 1.000 Agentes de IA por 30 dias e aqui está o que descobri

A habilidade que substituiu a criação de prompts, e os sistemas que você pode executar hoje.

Pare de otimizar seu prompt. Ele não é mais o gargalo.

Com um agente em uma janela de chat, o prompt é a maior parte do jogo.

Com dez agentes rodando por horas, o prompt é uma margem de erro.

O que decide a qualidade do trabalho é o sistema em torno dos agentes:

• em qual modo cada tarefa é executada
• qual modelo executa cada etapa
• como os agentes se mantêm coordenados
• como o "concluído" é verificado enquanto você dorme

Um prompt te dá uma saída. Um loop te dá uma operação composta.

A mudança é simples. Você deixa de ser a pessoa que lê cada resultado e digita a próxima instrução. Você se torna a pessoa que projeta o sistema uma vez e o deixa funcionar.

Essa camada de design é o trabalho agora. Aqui está como construí-la.

Você constrói o orquestrador, não o código

Você não gerencia trinta agentes conversando com trinta agentes. Você conversa com um. Esse um é o orquestrador, e ele gerencia o resto.

Um bom orquestrador faz exatamente três coisas:

1. Decompõe um objetivo em subtarefas delimitadas e verificáveis independentemente.
2. Delega cada subtarefa a um trabalhador, com um briefing sucinto e posse clara de arquivos.
3. Monta os resultados e decide o que fazer em seguida.

Uma regra está acima de todas as outras: o orquestrador nunca faz o trabalho em si.

No momento em que seu agente principal começa a escrever código de implementação, seu contexto se enche de detalhes e ele perde o fio da meada do trabalho geral.

Mantenha o contexto dele limpo. Ele pensa, divide, atribui e verifica. Nada mais.

Em seguida, vá fundo, não largo:

• Não faça o orquestrador gerar oito trabalhadores diretamente. Isso fragmenta o contexto dele.
• Em vez disso, faça ele gerar dois ou três líderes.
• Deixe cada líder gerar seus próprios dois ou três especialistas.

A recompensa é o triplo da profundidade de decomposição pelo mesmo custo de contexto. É assim que uma organização real escala, através de camadas, não tendo uma pessoa atribuindo cada tarefa.

Verificável ou não: a divisão que decide tudo

Antes de construir qualquer coisa, faça uma pergunta sobre a tarefa. Uma máquina pode verificar se ela está concluída?

Essa resposta decide toda a sua abordagem.

Se a tarefa for verificável, você pode colocá-la em loop:

• Os testes passam ou não passam.
• O type checker está verde ou não está.
• O benchmark ultrapassa o limite ou não ultrapassa.

Aponte um agente para uma tarefa verificável e ele vai escalá-la durante a noite. Você acorda com um problema resolvido.

Se a tarefa não for verificável, um loop sozinho não vai te salvar. Exemplos:

• Projetar uma boa avaliação.
• Decidir se uma API parece correta.
• Julgar se uma direção de pesquisa vale a pena ser perseguida.

Para essas, você injeta gosto. Você não pode entregar o objetivo e ir embora, porque não há um portão para parar.

Então, o movimento é tornar o máximo possível do trabalho verificável:

• Transforme "deixar bom" em "passar nestas verificações específicas."
• Substitua alvos vagos por concretos e mensuráveis.
• Onde não conseguir, mantenha um humano no loop e direcione.

A maior parte da engenharia de orquestração é converter objetivos difusos em verificáveis, para que o loop possa assumir o controle.

Comece com o menor sistema real: um loop de objetivo

Um loop de objetivo é um objetivo persistente mais uma verificação determinística. O agente trabalha passo após passo em direção a um alvo, em vez de parar após uma rodada.

O sistema inteiro é um loop em torno do seu agente e de um validador:

1i=0
2until npm test -s; do
3  agent -p "Objetivo: deixar a suíte de testes verde.
4            LEIA o código e construa um panorama completo ANTES de mudar qualquer coisa.
5            'npm test' está falhando. Faça a menor mudança possível para passar."
6  (( ++i > 20 )) && { echo "parar: 20 iterações"; exit 1; }
7done

O validador é qualquer comando cujo código de saída é o portão. Testes, um typecheck, um linter ou um script personalizado.

Duas coisas são inegociáveis:

1. Um limite. Um loop sem condição de parada é como você acorda com uma conta de tokens de cinco dígitos.
2. Uma instrução de ler primeiro. O modo de falha padrão de todo agente é dar um chute aleatório na primeira correção plausível em vez de ler o código.

Force a leitura. É mais lento por passo e muito mais rápido no geral.

Torne o "concluído" inegociável: o juiz

Agentes desistem cedo. Eles são treinados para parar no instante em que conseguem justificar.

"Fiz o meu melhor, parando por aqui" não é o mesmo que concluído.

Se um agente avalia o próprio dever de casa, ele trapaceia. Não maliciosamente. Ele simplesmente se convence de que terminou.

A correção é um juiz separado:

• Um segundo agente cujo único trabalho é pontuar o trabalho contra uma rubrica concreta.
• Ele responde a uma pergunta: concluído ou não concluído, e o que está faltando.
• Ele não tem interesse em parar, então não hesita.

Execute o construtor e o juiz em famílias de modelos diferentes. Famílias diferentes cometem erros não correlacionados, então o juiz vê o que o construtor não enxerga.

1while :; do
2  agent --model "$BUILD" -p "Tarefa: $TASK. Leia primeiro, implemente, execute os testes."
3  veredito=$(agent --model "$JUDGE" -p "Revisor rigoroso. Pontue contra cada item em rubric.md.
4            Responda exatamente 'PASS' ou 'FAIL: <o que está faltando>'.")
5  [[ $veredito == PASS* ]] && break
6done

Torne a rubrica concreta e binária:

• Rubrica boa: "todos os testes verdes, migração incluída, sem logging de debug."
• Rubrica ruim: "deixar bom."

Um verificador desinteressado com poder de veto é a única coisa que permite que uma execução continue por horas em vez de desmoronar no momento em que o trabalhador se cansa.

Dispare-o a cada conclusão de tarefa. Então você só verá trabalho revisado como verde.

Mais loops que você realmente usará

O loop de objetivo é o padrão base. Algumas variações cobrem a maior parte do que você executará.

1. O loop de validação.

Aja, execute o validador, alimente a falha de volta, repita até que o portão esteja verde.

Use-o para varreduras de regressão, type checks e qualquer passagem ou falha determinística.

2. O loop de fila e reinicialização.

Divida o trabalho em uma lista de tarefas pequenas e atômicas. Processe uma de cada vez.

Após cada tarefa, reinicialize o agente para um contexto limpo e pegue a próxima.

Um contexto que roda por horas se enche de confusão. Reinicializar mantém cada tarefa limpa.

A memória vive fora do agente, no arquivo de tarefas e no histórico de commits.

1while read -r task; do
2  agent -p "Tarefa: $task. Leia primeiro. Implemente, depois execute os testes."
3  npm test -s && git commit -aqm "auto: $task"   # commita apenas no verde
4done < tasks.txt

3. O loop de monitoramento.

Aponte um agente para um fluxo de sinais e deixe-o surfar o que é importante. Issues abertas, builds falhando, logs de erro, novos feedbacks.

Ele não espera você perguntar. Ele lê, tria e reporta para cima, ou abre um rascunho de correção.

1while sleep 300; do
2  agent -p "Leia os logs de erro dos últimos 5 minutos. Se um padrão NOVO aparecer,
3            abra uma issue com uma reprodução mínima. Caso contrário, diga 'nada de novo'."
4done

4. O loop de planejar-depois-construir.

Execute o loop em duas fases. Primeiro, uma passagem de planejamento que produz um plano escrito e para.

Você revisa o plano. Em seguida, uma passagem de execução segue o plano aprovado.

O plano é barato de corrigir. O código é caro de corrigir. Capture a direção errada no plano.

Os prompts que fazem o trabalho

Um prompt não é um desejo. Para um agente, é uma especificação.

A diferença entre uma saída mediana e uma excelente é quase inteiramente a qualidade destes.

Mantenha um pequeno conjunto de prompts reutilizáveis. Cinco carregam a maior parte do peso.

1. O prompt de decomposição, para o orquestrador:

1Você é o orquestrador. NÃO escreva código.
2Divida este objetivo em 3 a 6 subtarefas delimitadas.
3Para cada uma: um resumo de uma linha, os arquivos exatos que ela possui e sua verificação de conclusão.
4Sinalize qualquer tarefa que dependa de outra. Produza a lista e pare.
5Objetivo: <objetivo>

2. O briefing do trabalhador, para um especialista:

1Você possui APENAS estes arquivos: <arquivos>.
2Tarefa: <uma linha>. Concluído quando: <verificação verificável>.
3Leia esses arquivos e seus chamadores ANTES de editar. Não mude nada fora dos seus arquivos.
4Quando terminar, escreva um relatório de 5 linhas em <nome>.md, depois execute os testes.

3. O prompt do juiz, para uma família de modelos diferente:

1Você é um revisor rigoroso e sem caridade. Você não escreveu este código.
2Pontue o repositório contra CADA item abaixo. Uma falta é um FAIL.
3<rubrica>
4Responda com exatamente uma linha: 'PASS' ou 'FAIL: <o que está faltando>'.

4. O prompt de planejar primeiro, para o modo de planejamento:

1Produza um plano escrito para <objetivo>. Cubra: abordagem, arquivos a tocar,
2casos de borda, estratégia de teste e o que você NÃO fará.
3Não escreva código ainda. Pare após o plano para que eu possa revisá-lo.

5. O prompt de refletir ou matar, quando um agente está emperrado:

1Você falhou na mesma verificação 3 vezes. Pare de repetir a abordagem.
2Responda em 3 linhas: o que exatamente falhou, qual suposição estava errada,
3e a menor coisa diferente a tentar. Em seguida, tente APENAS isso.

Um padrão percorre todos os cinco. Declare o papel, os limites, a verificação de conclusão e o que NÃO fazer.

Roteamento de modelo: a pergunta que todos fazem

A pergunta geralmente é formulada como uma escolha. Eu coloco o modelo caro no planejamento ou na implementação?

Esse é o enquadramento errado. Roteie pelo raio de explosão. Pergunte onde um erro te custa mais.

A lógica é simples:

• Uma má decisão no planejamento se propaga por toda a sua frota.
• Uma linha ruim em uma função delimitada e testada é pega em minutos.
• Então, você gasta onde os erros são caros e irreversíveis, e economiza onde são baratos e contidos.

Aqui está o roteamento, camada por camada:

1. Planejamento, arquitetura e decomposição: camada superior, sempre. Maior alavancagem, volume de tokens minúsculo. Economizar aqui é o erro mais caro que você pode cometer.
2. Implementação com especificação restrita: camada média, execute em paralelo. A especificação fez o pensamento. Verifique com testes.
3. Implementação com especificação solta: camada superior. Preencher lacunas é raciocínio, e um modelo barato chuta errado em uma dúzia de direções.
4. Revisão e julgamento: uma família diferente, e não barata. É aqui que você pega os erros caros.
5. Navegação, busca, resumo e classificação: o modelo mais barato e rápido. Zero raciocínio, alto volume. Nunca pague taxas premium por grep.

Portanto, a resposta real para "planejamento barato ou implementação barata" não é nenhum dos dois, cegamente.

Modelo topo no planejamento e revisão, sempre. Implementação é a variável.

Famílias de modelos diferentes também têm personalidades diferentes, e isso importa para o roteamento:

• Uma família preenche lacunas. Quando a especificação é solta, ela faz suposições razoáveis e continua em frente. Isso ajuda quando as suposições são boas e atrapalha quando não são.
• Outra família é literal. Ela faz exatamente o que você disse e pouco mais, como uma faca utilitária precisa.

Use o preenchedor de lacunas onde o trabalho é aberto e a especificação é solta. Use o literal para revisão e para mudanças exatas e bem especificadas.

A alavanca que controla a implementação é sua especificação

• Uma especificação restrita te dá o direito de executar trabalhadores baratos e paralelos.
• Uma especificação solta te força de volta a um modelo caro para preencher as lacunas.

Invista no plano precisamente para poder baratear a construção.

Uma armadilha merece ser mencionada. O roteamento barato otimiza o preço de cada chamada, mas pode destruir silenciosamente a parcela de tokens que produzem saída enviável e mesclável.

Um modelo barato que tenta cinco vezes e produz código que você não pode mesclar é mais caro do que uma passagem limpa de um modelo premium.

Meça o custo da saída útil, não o custo por chamada.

Para escala, dois números ajudam:

• Sua camada superior custa cerca de cinco vezes o preço de saída por token de uma camada barata.
• O roteamento em camadas normalmente reduz os gastos em 40% a 60% em comparação com executar seu melhor modelo em todos os lugares.

Habilidades: empacote um fluxo de trabalho uma vez, reutilize-o para sempre

Quando você fica colando o mesmo prompt ou executando o mesmo fluxo de trabalho, transforme-o em uma habilidade.

Uma habilidade é um pequeno arquivo de instrução que o agente carrega apenas quando é relevante.

Você escreve o fluxo de trabalho uma vez, e todo agente pode recorrer a ele.

Um arquivo de habilidade tem duas partes:

• Frontmatter YAML com um nome e uma descrição.
• Um corpo em markdown com as instruções reais.

A descrição é a linha mais importante. Ela diz ao agente o que a habilidade faz e exatamente quando usá-la, para que o agente a pegue por conta própria sem que você a nomeie.

Um arquivo de habilidade mínimo:

1---
2name: revisao-termonuclear
3description: Revisão de código profunda e adversarial. Use após qualquer alteração não trivial,
4  ou quando for solicitado a revisar, auditar ou endurecer um diff antes do merge.
5---
6
7# Revisão Termonuclear
8
9Leia o diff completo e os arquivos que ele toca. Não passe o olho.
10
11Revise em três passagens:
121. Correção: erros de lógica, casos de borda, condições de corrida, erros de off-by-one.
132. Segurança: injeção, autenticação, segredos, entrada insegura, operações destrutivas.
143. Adequação: corresponde à arquitetura existente ou adiciona um novo padrão?
15
16Para cada achado: arquivo, linha, gravidade e a correção de uma linha.
17Termine com um veredito: SHIP ou BLOCK, mais os 3 principais itens a corrigir primeiro.

Regras para boas habilidades:

1. Mantenha o arquivo curto. Abaixo de algumas centenas de linhas. Mova material de referência longo para arquivos separados para os quais a habilidade aponta.
2. Faça o nome corresponder à sua pasta, ou não carregará.
3. Escreva a descrição para acionamento. Explique os casos de "use quando".
4. Nunca deixe um agente reescrever uma habilidade. Um humano cura cada linha.

Habilidades são como um fluxo de trabalho se acumula. A primeira vez que você resolve algo bem, você salva e torna detectável. Em cada sessão seguinte, é de graça.

Executando muitos: a frota

Assim que um loop funciona, você escala.

Dê a cada trabalhador duas coisas:

• Seu próprio worktree git, para que nunca dois agentes toquem nos mesmos arquivos.
• Sua própria janela de terminal, para que você possa observá-lo e enviar mensagens.

1tmux new-session -d -s fleet
2for nome in hilbert gauss poincare; do
3  git worktree add -B "agent/$nome" "../wt-$nome" main
4  tmux new-window -t fleet -n "$nome" -c "../wt-$nome" "$AGENT"
5done

• Dê nomes aos seus agentes. Executando quinze deles, "agent_7" é inútil.
• Nomes permitem que você mantenha a frota inteira na sua cabeça. Este é dono da camada de dados, aquele escreve evals, aquele outro revisa.
• Legibilidade é o objetivo. Uma frota que você não pode rastrear é uma frota que você não pode dirigir.
• Em seguida, faça-os cooperar. Por padrão, agentes se ignoram e tratam qualquer coisa de um irmão como ruído de fundo.

O truque é entregar mensagens entre agentes como turnos de usuário. Modelos são treinados para responder ao usuário e ignorar principalmente sinais ambientes.

1enviar() { tmux send-keys -t "fleet:$1" "$2" Enter; }
2enviar hilbert "GET /search?q= retorna [{id,title,url}]. Conecte a UI a ele."

Esse único movimento transforma uma pilha de processos isolados em uma equipe que passa contratos e desbloqueia uns aos outros.

Você fica no topo. Você envia mensagem para o líder, e o líder retransmite para os trabalhadores.

Fluxos de trabalho dinâmicos: compile a coordenação em código

Um loop mantém a coordenação dentro do modelo. O modelo decide cada passo, o que queima tokens e enche seu contexto.

Um fluxo de trabalho dinâmico inverte isso. O orquestrador escreve um script que coordena os trabalhadores, e um runtime separado executa o script em segundo plano.

A ideia chave é onde o estado vive. O loop, a ramificação e os resultados intermediários residem nas variáveis do script, não na memória do modelo.

O que isso compra:

• A coordenação custa zero tokens de modelo, porque código simples está fazendo isso.
• Seu contexto principal permanece limpo. Apenas o resultado final volta.
• Ele se expande. Dezenas de trabalhadores de uma vez, até mil em uma execução.

Quando recorrer a ele:

• O padrão é conhecido e a verificação é objetiva.
• O trabalho é amplo e repetitivo. Muitos arquivos, muitos casos, muitos endpoints.
• Pode ser executado sem supervisão.

Quando não recorrer a ele:

• Você ainda está descobrindo o que fazer. Isso é um loop de objetivo, não um fluxo de trabalho.
• A tarefa precisa de uma cadeia de raciocínio coerente. Isso quer um único agente forte, não mil.

Um formato concreto. Digamos que você precise migrar 200 arquivos para uma nova API:

1// o orquestrador escreve isso uma vez; um runtime executa, não o modelo
2const arquivos = await glob("src/**/*.ts");
3
4const resultados = await mapLimit(arquivos, 16, async (arquivo) => {
5  const r = await subagente(`Migrar ${arquivo} para a nova API. Executar seus testes.`);
6  return { arquivo, ok: r.testesPassaram };
7});
8
9const falhas = resultados.filter(r => !r.ok);
10return `migrados ${resultados.length - falhas.length} de ${resultados.length}. ` +
11       `repetir: ${falhas.map(f => f.arquivo).join(", ")}`;

Leia o que isso faz:

1. Lista os 200 arquivos em código, não na cabeça do modelo.
2. Executa 16 subagentes por vez, cada um migrando um arquivo e executando seus testes.
3. Registra passou ou falhou por arquivo em um array simples.
4. Retorna um breve resumo. As 200 transcrições intermediárias nunca tocam seu contexto.

Esse é o ponto principal. O modelo pensou uma vez, para escrever o script. O script fez a coordenação, de graça.

Barreiras de proteção: o que impede uma frota de se autodestruir

O gargalo humano costumava fazer trabalho real. Na velocidade humana, os erros doem cedo e você os corrige enquanto avança.

Remova-se completamente e pequenos erros se acumulam mais rápido do que você pode senti-los. Uma duplicação aqui, uma abstração desnecessária ali.

Um dia a arquitetura não vai ceder, e seus testes não serão confiáveis porque agentes também os escreveram.

Cada barreira de proteção abaixo substitui a correção que o gargalo costumava fornecer:

1. Leia antes de adivinhar. Torne isso uma regra permanente em todo prompt de construção, não um apelo por tarefa.
2. Limite e mate. Todo loop recebe um limite de iterações. Todo agente recebe um orçamento de tokens que pausa automaticamente perto de 85%. Após três iterações emperradas no mesmo erro, mate o agente e entregue a tarefa a um novo.
3. Um arquivo, um dono. Isole com worktrees. Nunca deixe dois agentes editarem o mesmo arquivo.
4. Reinjete a missão. Em execuções longas, publique a lista de verificação como uma mensagem de usuário a cada poucos minutos para que o agente não se desvie à medida que seu contexto enche.

1while sleep 900; do
2  enviar gauss "LEMBRETE: ainda na tarefa? Leia primeiro. Execute os testes após cada mudança. Fique nos seus arquivos."
3done &

O ponto mais profundo está abaixo de tudo isso:

• A verificação é agora o gargalo, não a geração.
• Agentes produzem saída plausível mais rápido do que você pode verificar.
• Plausível não é correto.

Até que sua verificação seja tão rápida quanto sua geração, a revisão humana não é sobrecarga. É o sistema de segurança.

Memória: você é o armazenamento de longo prazo

Um modelo tem memória de curto prazo, a janela de contexto, e nada mais. Tudo além dessa janela desaparece, a menos que você carregue.

Portanto, trate a si mesmo e aos arquivos que você mantém como a memória de longo prazo para agentes que só têm memória de curto prazo.

Dois hábitos importam.

Primeiro, passe o estado por referência, não por resumo:

• Quando um contexto enche, a correção preguiçosa é resumi-lo. Resumos são com perdas e descartam o detalhe que você precisará mais tarde.
• Em vez disso, aponte agentes para arquivos, registros de tarefas e saídas anteriores que eles podem reler. Nada importante é descartado silenciosamente.

Segundo, mantenha a memória durável fora do agente:

• Um arquivo de tarefas com status.
• Um log de progresso contínuo.
• O histórico de commits.
• Um arquivo de notas de longo prazo que coleta padrões e pegadinhas.

Projete como se seus agentes fossem executar por dias, porque com boa compactação, eles executarão.

Os modelos ainda não sabem disso sobre si mesmos. Eles carregam um viés para resolver tudo dentro de um orçamento curto, como se gastar tokens fosse fatal. Seu scaffolding é o que permite que eles executem por muito tempo sem perder o fio da meada.

Topologia: quantos agentes e em que formato

Mais agentes não é mais saída. Além de um ponto, é menos, porque a coordenação não é gratuita e se agrava com cada agente que você adiciona.

A regra que importa é combinar o formato com o trabalho:

• Raciocínio sequencial e dependente quer menos agentes, às vezes um. Dividir uma única cadeia de pensamento fragmenta o raciocínio e degrada o resultado.
• Trabalho independente e paralelo quer que você se expanda. Topologia plana, posse de arquivo limpa. É aí que o paralelismo compensa.
• Uma equipe coordenada quer de três a cinco trabalhadores. O custo de tokens escala aproximadamente linearmente com o tamanho. O custo de coordenação escala pior. Três trabalhadores focados superam cinco dispersos.

Então, como alguém executa centenas? Não como uma conversa gigante discutindo consigo mesma.

Eles executam como profundidade e independência:

• Alguns agentes com os quais você realmente conversa, cada um delegando para baixo em subtarefas delimitadas que não precisam se coordenar.
• Enxames de loops independentes fazendo suas próprias coisas e reportando para cima.

Escala vem da profundidade de delegação e independência. Nunca de alargar um único tópico.

O arquivo de controle: orchestration.md

Você provavelmente mantém um arquivo que diz aos agentes como escrever código no seu repositório. Estilo, pegadinhas, arquitetura. Mantenha-o.

Ele responde à pergunta errada para orquestração, no entanto.

O arquivo orchestration.md responde a uma diferente. Como o trabalho deve ser executado aqui?

É um contrato escrito por humanos que cobre:

• qual modo usar para qual tarefa
• qual camada de modelo vai onde
• quais são as barreiras de proteção
• quando escalar para um humano

Todo agente o lê no início de cada sessão e o usa para auto-selecionar sua abordagem.

Este é o arquivo de maior alavancagem no repositório. Ele move a decisão de seleção de modo para fora da sua cabeça, onde você a refaz inconsistentemente a cada sessão, e para dentro de uma especificação que a frota segue.

Uma versão curta se parece com isto:

1# orchestration.md. Como o trabalho é EXECUTADO aqui. Curado por humanos. Agentes não devem editar.
2
3Escolha o modo:
4- Loop de objetivo (supervisionado): trabalho difuso ou de design. Defina a verificação de conclusão.
5- Loop de validação: portão determinístico. Sempre limite iterações e custo.
6- Construir mais juiz: trabalhador constrói, um juiz de família diferente aprova.
7- Frota (três a cinco): subtarefas interdependentes, worktrees isolados, mensagens entre pares.
8- Fila e reinicialização: muitas tarefas atômicas pequenas, contexto novo a cada vez.
9- Fluxo de trabalho dinâmico: padrão conhecido, portão objetivo, amplo e repetitivo. Coordenação em código, sem supervisão.
10
11Roteie modelos por raio de explosão:
12- Planejamento e arquitetura: camada superior, sempre.
13- Construir, especificação restrita: camada média, paralelo, verifique com testes.
14- Construir, especificação solta: camada superior, porque preencher lacunas é raciocínio.
15- Revisão e juiz: uma família diferente. Nunca o modelo do implementador.
16- Nav, busca, resumo: o mais barato. Otimize saída mesclável, não preço por chamada.
17
18Barreiras de proteção:
19- Orçamento de tokens por agente. Pausa automática perto de 85%. Mate e reatribua após 3 tentativas emperradas.
20- Qualquer execução com mais de uma hora precisa de um juiz separado. Trabalhadores nunca se auto-reportam como concluídos.
21- Leia o código antes de criar hipóteses. Planeje por escrito antes da primeira edição.

Duas regras governam o arquivo:

1. Mantenha-o curto.
2. Nunca deixe um agente reescrevê-lo.

O valor é que um humano curou cada linha.

O que permanece seu

A orquestração torna os agentes confiáveis na execução. Ela não escolhe o problema e não sabe como é o "bom".

Três coisas ficam do seu lado da linha, permanentemente.

Primeiro, delegue as tarefas, não o julgamento:

• Entregue aos agentes trabalho escopo com critérios claros de aprovação ou reprovação. Código padronizado, migrações, scaffolding de testes e abordagens que você nunca teria tempo de tentar manualmente.
• Mantenha a arquitetura, a decisão sobre o que não construir e a revisão de contexto completo para si mesmo.
• Agentes absorveram um oceano de arquitetura medíocre, e eles felizmente farão cargo-cult de padrões pesados em um projeto que não deveria tê-los. Dizer "não" é um recurso que eles não têm.

Segundo, sua especificação é a alavancagem:

Quando você distribui o trabalho por uma frota, o pensamento vago não apenas te atrasa — ele se multiplica.

Um requisito ambíguo se propaga através de dezenas de execuções paralelas, cada uma seguindo em uma direção errada diferente.

Uma especificação precisa se multiplica em implementações precisas em todos os lugares.

É por isso que um bom engenheiro tira mais proveito dessas ferramentas, e não menos. A digitação foi automatizada. A compreensão foi amplificada.

Passe a maior parte do tempo no modo planejamento, com um plano escrito no qual todos estejam alinhados, antes da primeira edição.

Terceiro, subfinancie de propósito:

• Monte um trabalho de quatro agentes com dois. A restrição força o comportamento que você deseja.
• Você cria loops em vez de fazer as coisas manualmente, e da próxima vez aquele trabalho já está automatizado.
• Mude seu orçamento de esforço manual para tokens. Alto investimento inicial, custo marginal próximo de zero para sempre.

As equipes que fazem isso se beneficiam do efeito composto. As que não fazem pagam o preço total toda vez.

Você não está mais escrevendo o software. Você está construindo a fábrica que o escreve.

Uma fábrica precisa de entradas precisas, controle de qualidade em cada estação e um dono que saiba qual deve ser o produto.

Comece aqui

Não tente executar cem agentes na segunda-feira. Suba a escada:

1. Execute um loop de objetivo em uma tarefa com uma linha de chegada verificável. Aprenda como é uma boa verificação de conclusão.
2. Adicione um juiz de uma família de modelos diferente para qualquer coisa acima de uma hora. Proíba conclusão auto-reportada.
3. Escreva seu orchestration.md. Diga aos seus agentes para lê-lo primeiro. Observe-os começando a escolher modos para você.
4. Distribua cuidadosamente. Uma tarefa paralelizável, três a cinco trabalhadores, árvores de trabalho isoladas, orçamentos de tokens.
5. Roteie seus modelos. Nível superior para planejamento e revisão, mais barato para construção limitada e trabalho pesado. Meça saída integrável.
6. Deixe-o rodar sem supervisão assim que um padrão for validado e objetivamente verificável. Esvazie o backlog durante a noite.

O sistema só precisa estar direcionalmente correto, não perfeito:

• O arquivo de controle dá à frota estrutura suficiente para se autodirigir.
• O juiz pega os casos extremos.
• O loop de lembrete cuida da memória.
• Seu gosto cuida das decisões que não delegam.

Criar prompts era a habilidade do ano passado. Esta é a habilidade agora.

As versões executáveis de cada sistema aqui — o loop de objetivo, o loop do juiz, o lançador da frota, o barramento de mensagens, o watchdog de lembrete e o roteador de modelos — estão no kit complementar. Defina uma variável para sua CLI de agente e vá em frente.

Aviso Legal

Este artigo foi escrito usando sessões do Claude Code e sessões do codex do autor.

Editado pelo autor e pelo modelo Kimi K2.6 para questões gramaticais e de formatação.