Como tornar um agente de IA confiável: plano em oito passos, da medição ao trabalho autônomo

Por que um agente continua instável mesmo com um modelo forte

A confiabilidade do agente é uma propriedade do sistema inteiro, não só do modelo. Uma tarefa longa tem dezenas de passos, e os erros se acumulam: com 95% de acerto por passo, cerca de 60% das execuções chegam ao décimo passo sem nenhum erro (0,95^10 ≈ 0,60), e menos de 10% chegam ao quinquagésimo. Você não consegue elevar diretamente a precisão do modelo, mas consegue capturar o erro no passo em que ele acontece e tornar seu custo baixo. É isso que o harness faz: instruções, ferramentas, ambiente, estado e feedback montados em volta do modelo.

O plano a seguir vai de «avaliar pelo achismo» até a confiabilidade mensurável e, depois, ao trabalho autônomo. Os passos estão ordenados pelo retorno que trazem, e cada um se apoia no anterior.

Passo 1: pare de avaliar pelo achismo

Um engenheiro tem certeza de que o novo prompt mudou tudo, outro não nota diferença, e ninguém mediu nada. Comece com um diário de falhas: sempre que o agente travar, quebrar algo ou relatar uma funcionalidade que não roda, anote uma linha.

| data  | tarefa           | o que aconteceu                | subsistema     |
|-------|------------------|--------------------------------|----------------|
| 10/10 | desconto no carrinho | disse «pronto», não rodou e2e | feedback       |
| 10/10 | webhook de pagamento | não conseguiu subir o banco   | ambiente       |
| 11/10 | refatoração da API   | repetiu uma solução descartada| estado         |

A coluna «subsistema» é a mais importante. Em uma semana fica visível onde está o gargalo, e você conserta esse ponto em vez de mexer em tudo. Medir confiabilidade pelo número de execuções bem-sucedidas é um erro: é o diário de falhas que mostra onde o agente tropeça.

Passo 2: adote duas métricas, MTBF e MTTR

A confiabilidade se resume a dois números. O MTBF (tempo médio entre falhas), para um agente, é quantos passos ele dá antes de travar. O MTTR (tempo médio de recuperação) é quanto tempo leva para voltar a um estado de trabalho depois de uma falha. A disponibilidade sobe tanto quando o primeiro aumenta quanto quando o segundo cai.

Perseguir um agente que nunca erra é uma corrida sem fim. Já reduzir o MTTR costuma ser possível em um dia, então comece pelo segundo número.

Passo 3: torne o erro barato

Um agente pode trabalhar sozinho não porque deixou de errar, mas porque o custo de errar caiu quase a zero. Para isso são necessárias três coisas:

• Commits pequenos e limpos——qualquer alteração pode ser desfeita com um comando.
• Isolamento——o agente trabalha em uma branch ou cópia separada, por exemplo com git worktree, e em um sandbox sem acesso à produção.
• Script de reset do ambiente——banco, dependências e serviços voltam ao estado inicial com um comando.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # recria o banco, aplica as migrations, carrega os fixtures

Meça com um cronômetro quanto leva a volta completa a um estado de trabalho. Esse é o seu MTTR. Ao mesmo tempo, limite o raio de dano: um tamanho máximo de diff por tarefa e a proibição de editar arquivos fora do escopo.

Passo 4: feche o laço de feedback

Sem verificações, o agente é o único juiz e considera honestamente o trabalho concluído. Dê a ele comandos para se checar e torne-os obrigatórios.

• Fail-fast:a verificação para no primeiro erro, com mensagem clara, e não imprime cem linhas de ruído.
• Checagens rápidas após cada alteração:linter e checagem de tipos pelo hook do agente.
• Redundância:uma segunda verificação independente da mesma propriedade, como um cenário E2E sobre os testes unitários. Testes unitários verdes não provam que a funcionalidade funciona para o usuário.

Escreva o critério de «pronto» como uma condição verificável: «o cenário E2E de compra com cupom passa», e não «o desconto foi implementado».

Passo 5: transfira a memória para arquivos

O agente não lembra a sessão anterior. Tudo o que é necessário para continuar precisa existir no repositório: o objetivo, o que foi feito e como foi verificado, as decisões com seus motivos, os becos sem saída e o próximo passo. Um bom sinal é quando uma sessão nova, recebendo apenas o repositório e a palavra «continue», já começa um trabalho útil.

Um histórico de conversa compactado dá sensação de continuidade, mas perde o mais valioso: os motivos das alternativas descartadas. Encerrar a sessão de propósito, com um estado escrito completo, costuma ser mais barato do que tentar manter tudo na memória.

Passo 6: uma tarefa por vez

A lei de Little diz que o número de tarefas no sistema é igual à taxa de chegada multiplicada pelo tempo que cada tarefa permanece nele. Com capacidade fixa, tarefas paralelas não aceleram o trabalho; apenas esticam cada uma. Para um agente, isso é ainda mais forte: três funcionalidades significam três modelos de domínio na mesma janela de contexto.

• Mantenha WIP = 1: uma funcionalidade até um resultado verificado.
• Corte as tarefas em pedaços: uma capacidade verificável para o usuário, de 1 a 3 arquivos, com verificação em menos de um minuto.
• Crie um BACKLOG.md como válvula para o «já que estou aqui»: se o agente notar um defeito vizinho, uma linha no backlog, e não uma correção por conta própria.

Passo 7: separe quem executa de quem verifica

A autoavaliação do agente é um freio fraco: a sessão que escreveu o código tende a achá-lo correto. Deixe o resultado ser avaliado por um subagente separado, ou por uma sessão independente que recebe apenas o requisito, o diff e os resultados das verificações, sem as justificativas de quem executou. O veredito do avaliador deve se apoiar em verificações mecânicas, e não em «parece razoável».

Passo 8: solte o agente em um ciclo autônomo

O harness torna confiável uma única execução; o ciclo torna autônoma uma série de execuções. Um ciclo sobre um harness ruim apenas multiplica os erros mais depressa, por isso este passo vem por último. O ciclo mais simples cabe em três linhas:

Objetivo:   cenário e2e de pagamento com cupom passa
Verificação: make lint && make test && make e2e
Parada:     objetivo atingido OU 15 tentativas OU 2 horas → chamar uma pessoa

Escolha o tipo de ciclo conforme a tarefa. Se o trabalho tem uma linha de chegada, use um ciclo orientado a objetivo: memória do progresso, avaliador independente e orçamento de passos. Se não há fim (como revisar o CI toda manhã ou triar erros novos), um ciclo agendado serve. O erro comum é agendar uma tarefa que tem fim: cada execução recomeça do zero.

Regras para uma autonomia segura

• A condição de parada precisa ser verificável por máquina, com limite de tentativas e de orçamento.
• Liste de antemão o que o ciclo não pode fazer: migrações de produção, dinheiro, exclusão de dados.
• Se a tarefa empacar e o progresso medido não avançar de fato, é sinal de passar o trabalho para uma pessoa, e não de continuar rodando.
• Leia os diffs. A velocidade do ciclo não deve ultrapassar a sua velocidade de leitura, ou você deixa de entender a própria base de código.

Erros comuns nesse caminho

Começar reescrevendo as instruções

A resposta mais popular a uma falha do agente é acrescentar uma regra ao AGENTS.md. Em alguns meses o arquivo passa de centenas de linhas e as regras importantes se perdem. Se o diário de falhas mostra que o agente não rodou as verificações, o remédio é o feedback: o comando de verificação e o hook, e não mais um parágrafo de texto.

Consertar tudo ao mesmo tempo

Dá vontade de melhorar os cinco subsistemas de uma vez, mas aí não dá para saber o que funcionou. Avalie cada subsistema de 1 a 5, gaste meia hora no mais fraco e rode o mesmo conjunto de cinco tarefas típicas antes e depois. A diferença no diário de falhas mostra se houve efeito.

Confundir «testes verdes» com «funcionalidade funciona»

O agente pode escrever um teste que verifica a própria implementação, e não o requisito. Esse teste fica verde para sempre. A proteção é verificar no nível do usuário (cenário E2E), escrito antes da implementação ou por um verificador independente, e a regra de que o agente não altera o teste para fazê-lo passar.

Desligar verificações por causa da velocidade

Verificações lentas tentam a pessoa a pular «só desta vez». Separe-as: linter e checagem de tipos rápidas após cada alteração; a suíte completa e o E2E antes de dizer «pronto». Assim o laço de feedback continua curto sem atrapalhar o trabalho.

Fazer a ablação como primeiro passo

É possível desligar subsistemas do harness um a um e ver quanto a qualidade cai. É um teste útil, mas caro e não o primeiro passo. Primeiro, o diário de falhas aponta o gargalo; a ablação apenas confirma a hipótese. Se desligar um componente não muda nada, isso não prova que ele é inútil: talvez o conjunto de tarefas escolhido não o tenha usado.

Escada de maturidade

Conclusão

Para tornar um agente de IA confiável: meça; ache o subsistema fraco pelo diário de falhas; torne o erro barato; feche o laço de feedback; transfira a memória para arquivos; mantenha uma tarefa por vez; e separe quem executa de quem verifica. Só depois disso um ciclo autônomo, com condição de parada verificável por máquina, passa a ser seguro. Cada passo deste plano é explicado na prática, em um projeto real, no curso de harness engineering.