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

O Prompt Morreu em 2024. A Nova Habilidade é Orquestração

Administrei 1.000 Agentes de IA por 30 Dias e Aqui Está o Que Descobri

A habilidade que substituiu o prompting 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 é quase todo o jogo.

Com dez agentes rodando por horas, o prompt é um erro de arredondamento.

O que decide a qualidade do trabalho é o sistema ao redor dos agentes:

• em qual modo cada tarefa é executada
• qual modelo executa cada etapa
• como os agentes se mantêm coordenados
• como a "conclusão" é verificada enquanto você dorme

Um prompt te dá um resultado. Um loop te dá uma operação de composição.

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 rodar.

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 de forma independente.
2. Delega cada subtarefa a um trabalhador, com um resumo conciso e propriedade clara dos arquivos.
3. Monta os resultados e decide o que acontece 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 como um todo.

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

Depois, vá fundo, não largo:

• Não faça o orquestrador gerar oito trabalhadores diretamente. Isso estilhaça 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 que atribui 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 consegue 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.

Aponte um agente para uma tarefa verificável e ele vai escalá-la a noite toda. 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 (eval).
• Decidir se uma API "parece" certa.
• Julgar se uma direção de pesquisa vale a pena ser perseguida.

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

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

• Transforme "deixar bom" em "passar nestas verificações específicas".
• Substitua alvos vagos por concretos e mensuráveis.
• Onde não puder, 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: fazer a suíte de testes ficar verde.
4            LEIA o código e construa um quadro completo ANTES de mudar qualquer coisa.
5            'npm test' está falhando. Faça a menor mudança possível em direção ao sucesso."
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 "leia primeiro". O modo de falha padrão de todo agente é dar um tiro no escuro no primeiro palpite viável em vez de ler o código.

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

Torne a "conclusão" 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 soluçã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. Assim, você só verá trabalho revisado como verde (aprovado).

Mais loops que você realmente usará

O loop de objetivo é o padrão base. Algumas variantes 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 para varreduras de regressão, type checks e qualquer passa 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 reside 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"   # commit apenas no verde
4done < tasks.txt

3. O loop de monitoramento.

Aponte um agente para um fluxo de sinais e deixe-o superfciar o que importa. Issues abertas, builds com falha, 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 NOVO padrão aparecer,
3            abra uma issue com uma repro mínima. Caso contrário, diga 'nada de novo'."
4done

4. O loop de planeje-depois-construa.

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

Você revisa o plano. Depois, uma passada de execução segue o plano aprovado.

O plano é barato de corrigir. O código é caro de corrigir. Capture a direção ruim 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. Gere a lista e pare.
5Objetivo: <objetivo>

2. O resumo 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 para <nome>.md e execute os testes.

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

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

4. O prompt de planejamento primeiro, para modo de plano:

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

5. O prompt de reflita ou mate, quando um agente está travado:

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. Depois, 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 é colocada como uma escolha. Coloco o modelo caro no planejamento ou na implementação?

Esse é o quadro errado. Roteie pelo raio do estrago. Pergunte onde um erro te custa mais caro.

A lógica é simples:

• Uma decisão ruim no planejamento se propaga por toda a sua frota.
• Uma linha ruim em uma função delimitada e testada é pega em minutos.
• Então, gaste onde os erros são caros e irreversíveis, e economize 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. Ser barato aqui é o erro mais custoso 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 adivinha errado em uma dúzia de direções.
4. Revisão e julgamento: uma família diferente, e não uma barata. É aqui que você pega os erros caros.
5. Navegação, busca, sumarização e classificação: o modelo mais barato e rápido. Zero raciocínio, alto volume. Nunca pague tarifas premium por grep.

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

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

Diferentes famílias de modelos 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. Isso ajuda quando as suposições são boas, e prejudica quando não são.
• Outra família é literal. Ela faz exatamente o que você disse e pouco mais, como um canivete suíço de precisão.

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 a usar um modelo caro para preencher as lacunas.

Invista no plano precisamente para que você possa 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 integrável (mergeable).

Um modelo barato que tenta cinco vezes e produz código que você não pode integrar é mais caro do que uma passada 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 aproximadamente 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 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 buscá-lo.

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 sozinho sem você nomeá-la.

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 leia superficialmente.
10
11Revise em três passadas:
121. Correção: erros de lógica, casos extremos, 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 acrescenta 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 para 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 será carregado.
3. Escreva a descrição para disparo. Detalhe os casos de "use quando".
4. Nunca deixe um agente reescrever uma habilidade. Um humano seleciona (curates) cada linha.

Habilidades são como um fluxo de trabalho se acumula. Na primeira vez que você resolve algo bem, você o salva e o torna encontrável. Cada sessão depois disso, é de graça.

Executando muitos: a frota

Assim que um loop funciona, você escala.

Dê a cada trabalhador duas coisas:

• Sua própria árvore de trabalho git (worktree), para que dois agentes nunca 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 name in hilbert gauss poincare; do
3  git worktree add -B "agent/$name" "../wt-$name" main
4  tmux new-window -t fleet -n "$name" -c "../wt-$name" "$AGENT"
5done

• Nomeie seus agentes. Executando quinze deles, "agente_7" é inútil.
• Nomes permitem que você mantenha toda a frota em sua cabeça. Este é o dono da camada de dados, aquele escreve avaliações (evals), aquele revisa.
• Legibilidade é o ponto. Uma frota que você não pode rastrear é uma frota que você não pode dirigir.
• Depois, faça-os cooperar. Por padrão, os 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. Os modelos são treinados para responder ao usuário e, em sua maioria, ignorar sinais ambientes.

1send() { tmux send-keys -t "fleet:$1" "$2" Enter; }
2send 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 tarefas e se desbloqueia mutuamente.

Você fica no topo. Você envia mensagem para o líder, e o líder repassa 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 preenche 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 reside. O loop, a ramificação e os resultados intermediários ficam nas variáveis do script, não na memória do modelo.

O que isso te compra:

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

Quando usar:

• 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 usar:

• 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 files = await glob("src/**/*.ts");
3
4const results = await mapLimit(files, 16, async (file) => {
5  const r = await subagent(`Migrar ${file} para a nova API. Executar seus testes.`);
6  return { file, ok: r.testsPassed };
7});
8
9const failed = results.filter(r => !r.ok);
10return `migrados ${results.length - failed.length} de ${results.length}. ` +
11       `retentar: ${failed.map(f => f.file).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 de cada vez, cada um migrando um arquivo e executando seus testes.
3. Registra passa ou falha por arquivo em um array simples.
4. Retorna um resumo curto. As 200 transcrições intermediárias nunca tocam seu contexto.

Esse é o ponto principal. O modelo fez o pensamento 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. Em velocidade humana, os erros doem cedo e você os corrige conforme 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 se dobrará, e seus testes não serão confiáveis porque os 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. Faça disso uma regra permanente em todo prompt de construção, não um pedido por tarefa.
2. Limite e mate. Todo loop tem um limite de iteração. Todo agente tem um orçamento de tokens que pausa automaticamente perto de 85%. Após três iterações travadas 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. Re-injete 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 se enche.

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

O ponto mais profundo está abaixo de tudo isso:

• A verificação agora é o gargalo, não a geração.
• Os agentes produzem saída plausível mais rápido do que você pode verificá-la.
• 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 é uma 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 se foi, a menos que você o carregue.

Então, 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 perda de qualidade (lossy) e descartam o detalhe que você precisará depois.
• Em vez disso, aponte os agentes para arquivos, registros de tarefas e saídas anteriores que eles podem reler. Nada importante é silenciosamente jogado fora.

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 uma boa compactação, eles o farã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 arcabouço (scaffolding) é o que permite que eles rodem 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 a cada agente que você adiciona.

A regra que importa é combinar a forma 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 espalhe (fan out). Topologia plana, propriedade limpa de arquivos. É aí que o paralelismo compensa.
• Uma equipe coordenada quer de três a cinco trabalhadores. O custo de token escala aproximadamente linearmente com o tamanho. O custo de coordenação escala pior. Três trabalhadores focados vencem cinco dispersos.

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

Eles os executam como profundidade e independência:

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

A escala vem da profundidade de delegação e da independência. Nunca de alargar um único encadeamento.

O arquivo de controle: orchestration.md

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

No entanto, ele responde à pergunta errada para orquestração.

O arquivo orchestration.md responde a uma pergunta 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 para 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 a coloca em uma especificação que a frota segue.

Uma versão curta se parece com isso:

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 fresco cada.
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 pelo raio do estrago:
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 julgamento: uma família diferente. Nunca o modelo do implementador.
16- Navegação, busca, sumarizar: o mais barato. Otimize a saída integrável, não o preço da 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 travadas.
20- Qualquer execução com mais de uma hora precisa de um juiz separado. Trabalhadores nunca se autorreportam como concluídos.
21- Leia código antes de levantar 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 selecionou (curated) cada linha.

O que permanece sendo 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 com escopo com critérios claros de passa ou falha. Padronização (boilerplate), migrações, arcabouço de testes (test scaffolding) 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 você.
• Os agentes absorveram um oceano de arquitetura medíocre, e eles felizmente farão o "cargo cult" de padrões pesados em um projeto que não deveria tê-los. Dizer não é uma funcionalidade que eles não têm.

Segundo, sua especificação é a alavancagem:

Um prompt escrito de forma clara para uma IA gera resultados superiores a um pedido vago. Quanto mais específico você for sobre o que deseja, melhor será o resultado.

O ato de escrever uma boa especificação força você a pensar sobre o que realmente importa. É onde o valor real é criado, não na execução cega.

Quando você se espalha por uma frota, pensamentos vagos não apenas te atrasam. Eles se multiplicam.

Um requisito ambíguo se propaga por dezenas de execuções paralelas, cada uma errando em sua própria direção.

Uma especificação precisa se multiplica em implementações precisas em toda parte.

É por isso que um engenheiro forte extrai mais dessas ferramentas, não menos. A digitação foi automatizada. O entendimento foi amplificado.

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

Terceiro, subfinancie de propósito:

• Coloque dois agentes em uma tarefa que pediria quatro. 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 esse trabalho já está automatizado.
• Transfira seu orçamento do esforço manual para tokens. Alto investimento inicial, custo marginal quase zero para sempre.

As equipes que fazem isso se acumulam. 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 proprietário que sabe o que o produto deve ser.

Comece por aqui

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

1. Execute um loop de meta 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 que leve mais de uma hora. Proíba conclusão auto-relatada.
3. Escreva seu orchestration.md. Diga aos seus agentes para lê-lo primeiro. Observe-os começar a escolher modos para você.
4. Espalhe-se com cuidado. Uma tarefa paralelizável, três a cinco trabalhadores, worktrees isolados, orçamentos de tokens.
5. Roteie seus modelos. Nível superior em planejamento e revisão, mais barato em construção limitada e trabalho repetitivo. Meça a produção mesclável.
6. Deixe-o funcionar sem supervisão assim que um padrão for validado e objetivamente verificável. Drene o backlog durante a noite.

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

• O arquivo de controle dá à frota estrutura suficiente para se autodirigir.
• O juiz captura os casos extremos.
• O loop de lembrete lida com a memória.
• Seu gosto lida com as 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 meta, o loop de juiz, o lançador de frota, o barramento de mensagens, o watchdog de lembrete e o roteador de modelo — 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.