Agente de IA que termina tarefa longa: as 7 peças em volta do modelo

De onde vem este texto

O guia usa um exemplo simples: um fluxo que escreve artigos a partir de fontes, confere as afirmações e guarda o que foi aprovado. A lógica vale para qualquer tarefa que se repete, de um relatório mensal a uma conciliação.

Defina o que o agente precisa deixar no fim

A ideia central cabe numa frase: antes de mandar o agente trabalhar, combine o que ele precisa deixar pronto. O guia pede três coisas.

• Um resultado que dá para abrir. O arquivo final, salvo num lugar combinado, e não uma resposta perdida no meio da conversa.
• Evidência que dá para conferir. Uma tabela que liga cada afirmação a uma fonte, com veredito: verificado, incorreto ou não resolvido.
• Progresso salvo para continuar amanhã. Uma nota curta com o que foi feito, o que foi decidido, o que falta e a próxima ação.

Esse conjunto em volta do modelo tem nome: harness. São as instruções, as ferramentas, as permissões, o estado e as conferências. O modelo decide o próximo passo; o harness decide com o que ele decide, o que pode tocar e como prova que terminou.

As três peças que decidem o que entra

1. Fatos que valem sempre. Um arquivo de instruções do projeto (o CLAUDE.md) com o que continua útil entre tarefas: onde salvar, que fontes valem, como escrever. Prazo de uma tarefa ou dúvida pontual não vai ali; vai junto da tarefa.
2. O procedimento que se repete. Uma skill guarda a sequência (ler, redigir, revisar, salvar) e é chamada pelo nome, com o tema da vez. Cada passo precisa terminar num resultado que dá para ver. “Conferir a precisão” é vago; “salvar a tabela de conferência em tal arquivo” não é.
3. Acesso às fontes certas. Um conector (MCP) busca o material no sistema onde ele mora, como o Notion. Só entra quando sustenta um passo específico, com as ações que ele pode fazer bem definidas.

Repare que nenhuma dessas peças é um prompt mais esperto. São arquivos que ficam no projeto e servem para a próxima tarefa também.

A peça que decide o que o agente pode tocar

O guia põe as regras de ação na camada de execução, e não no texto do pedido. Uma configuração de permissões nega, por exemplo, a leitura dos arquivos de senhas e a edição da pasta de arquivos aprovados. A regra vale na fronteira da ferramenta, então não depende de o modelo lembrar dela.

Preparar e publicar são ações separadas, com autorizações separadas. O agente prepara para inspeção; quem aprova a publicação é uma pessoa.

Duas dicas de operação que valem ouro: para qualquer escrita num sistema externo, aprove o destino e o conteúdo exato, e revise de novo se o conteúdo mudar. E, se der timeout, olhe o destino antes de tentar outra vez, porque a primeira tentativa pode ter funcionado.

As três peças que provam que terminou

1. Um revisor que devolve evidência. Um subagente separado, só com ferramentas de leitura e busca, confere cada afirmação contra a fonte e devolve uma tabela: afirmação, veredito, fonte e correção. Quem corrige o texto é o agente principal.
2. Esforço escolhido por trabalho. A sessão principal roda em esforço médio, que é o padrão do Opus 5.5, e o revisor pede esforço alto. Escrever “pense com mais cuidado” no pedido não muda isso; o que muda é a configuração.
3. Uma meta com critério de aceite. O comando /goal diz o que precisa existir no fim (o rascunho, a tabela, as correções feitas, os pendentes marcados) e quando parar e avisar se não der.

A diferença entre “o agente disse que terminou” e “o agente terminou” está aqui. A conferência olha o arquivo salvo, não o que foi dito na conversa.

A nota de progresso é a passagem de turno

Tarefa longa atravessa sessões. O guia resolve com um arquivo simples, atualizado depois de cada etapa que importa, com seis campos: tarefa, saídas, o que foi concluído, decisões, pendências e próxima ação.

Uma sessão nova lê a nota, abre os arquivos citados e segue dali. Se ela recomeçar do zero, o problema está na nota: faltou registrar uma decisão ou um caminho. É a mesma disciplina de uma boa passagem de plantão entre pessoas.

Meça em trabalho aceito, não em trabalho entregue

Um resultado que precisa de muito conserto muda o valor da rodada inteira. Por isso o guia manda contar, além do consumo, o tempo de revisão e as correções que a saída precisou.

• Mantenha a mesma tarefa e o mesmo critério de aceite ao testar uma mudança.
• Mude uma peça por vez e compare o resultado salvo e a evidência.
• Quando uma correção se repetir, ela revela um passo que falta no procedimento.

O autor também faz um alerta honesto: a economia de tokens que aparece nos testes iniciais do Opus 5.5 é daquele experimento. A economia do seu fluxo só aparece medindo o seu fluxo.

O que isso muda na prática

A lição para quem está colocando IA na operação é que o salto para tarefas longas vem do desenho em volta do agente, não de um modelo mágico. Instruções que valem sempre, procedimento salvo, acesso controlado às fontes, regras na execução, revisão com prova, meta clara e passagem de turno.

• O Analista de IA mapeia a rotina e define o critério de aceite de cada tarefa antes de qualquer agente rodar.
• O Forward Deployed Engineer monta esse entorno dentro da operação: conectores, permissões, aprovação humana nos pontos certos, revisão e registro de progresso.
• O treinamento ensina o time a ler a evidência e a aprovar com segurança, que é onde a confiança nasce.

Relatórios, conciliações, propostas, cadastros e pesquisas são só exemplos. Se é tarefa que se repete, dá para automatizar, e com o harness certo dá para automatizar também as longas.