O agente disse que terminou. Cadê as evidências?

Você delega uma correção, espera alguns minutos e recebe uma resposta impecável: tarefa concluída, problema resolvido, testes passando.

Aí começa o trabalho que deveria ter acabado. É preciso descobrir quais arquivos mudaram, qual comando de teste foi executado, se o fluxo afetado chegou a ser aberto no navegador e por que a sessão encerrou naquele ponto.

A mensagem parece um relatório, mas ainda exige que alguém reconstrua a execução inteira. Para revisar o trabalho sem esse garimpo, o agente precisa devolver um recibo verificável.

Esse recibo não precisa ser um painel novo nem um log gigantesco. Pode ser um bloco curto de Markdown, desde que registre o que foi pedido, o que mudou, como o resultado foi conferido e o que ficou de fora.

"Concluído" é status, não evidência

Agentes de código já conseguem dividir trabalho entre subagentes, manter sessões paralelas e mostrar informações de uso e custo. Esses dados ajudam a operar a automação. Eles não dizem se o bug sumiu.

Uma execução pode terminar sem erro e ainda assim entregar uma correção parcial. O teste pode não ter rodado. O agente pode validar a função isolada e ignorar o fluxo real. Um bloqueio pode aparecer perto do fim e virar uma resposta otimista porque o sistema só sabe encerrar como sucesso.

A revisão fica mais barata quando a saída responde a perguntas concretas:

Qual objetivo o agente recebeu?
Que parte do projeto ele tinha permissão para alterar?
Quais arquivos ou superfícies foram modificados?
Que comandos e validações rodaram, e com qual resultado?
Qual artefato prova o comportamento final?
Por que a execução parou?
Que risco ou cenário continua sem validação?

O resumo continua útil para leitura rápida. A diferença é que cada afirmação importante aponta para algo que outra pessoa consegue conferir.

Um recibo pequeno já muda a revisão

Considere uma tarefa de frontend: corrigir um formulário que perde os campos preenchidos depois de uma resposta de erro da API.

Uma saída ruim seria esta:

Corrigi a preservação do estado e todos os testes passaram.

Ela soa segura, mas não permite saber qual estado foi preservado, quais testes passaram ou se alguém percorreu o formulário de verdade.

Um recibo melhor poderia seguir este formato ilustrativo:

status: concluído
objetivo: preservar os campos do formulário após erro da API
escopo:
  - componente do formulário
  - teste do fluxo de envio
alterações:
  - estado local mantido quando a resposta não confirma o envio
  - mensagem de erro separada dos dados digitados
validações:
  - teste de regressão do formulário: passou
  - envio com resposta de erro no navegador: passou
evidências:
  - campos permaneceram preenchidos após a falha
  - console sem novo erro durante o fluxo
encerramento: critérios de aceite verificados
riscos_restantes:
  - cenário offline não validado

O exemplo separa resumo, validação e risco restante. Quem revisa ainda precisa olhar o diff e, conforme o impacto, repetir o teste. Só não precisa adivinhar onde procurar.

Informações como modelo usado, subagentes acionados e consumo também podem entrar no recibo. Eu as trataria como contexto operacional, não como prova de correção. Uma tarefa cara pode estar errada; uma tarefa curta pode ter resolvido o problema com um teste objetivo.

A prova depende do tipo de tarefa

Cobrar uma captura de tela para qualquer mudança apenas troca falta de evidência por ritual. O artefato precisa combinar com o comportamento que está sendo aceito.

Tipo de tarefa	Evidência útil
Documentação	diff, verificador de links e build da documentação quando aplicável
Backend	teste de regressão, resposta esperada e trecho relevante do log
Frontend	fluxo percorrido, estado final, console e captura quando houver resultado visual
Desempenho	benchmark reproduzível, ambiente e comparação com a referência anterior

Uma captura confirma aparência, mas não demonstra que o estado sobreviveu à próxima interação. Um teste unitário confirma uma regra isolada, mas pode deixar passar um erro de integração. Para tarefas de navegador, DevTools acessíveis ao agente e ações estruturadas ajudam a coletar console, estado final e outros artefatos. Ainda é o contrato da tarefa que define o que conta como prova.

Também vale calibrar o custo. Uma correção mecânica pode terminar com lint e diff. Um bug que atravessa interface, API e cache pede reprodução, teste de regressão e uma parada para revisão. Colocar o mesmo checklist em tudo cria burocracia e ensina o time a ignorar o recibo.

Falhar direito faz parte do contrato

Um workflow confiável precisa aceitar finais que não sejam sucesso. Eu usaria pelo menos estes estados:

concluído: os critérios definidos foram verificados;
bloqueado: falta acesso, informação ou dependência externa;
timeout: o limite de execução chegou antes de uma conclusão verificável;
revisão necessária: o agente avançou, mas encontrou uma decisão que não deve tomar sozinho.

Relatos públicos de loops, respostas interrompidas e tarefas encerradas sem resultado confiável mostram por que essa distinção é útil, embora não sirvam como medida geral da confiabilidade de um fornecedor. O controle prático é simples: ao parar, o agente registra o último checkpoint válido, explica o motivo e indica o próximo passo.

Bloqueado não é um fracasso de formato. É uma resposta melhor do que declarar vitória para satisfazer uma automação que só reconhece verde ou vermelho.

O mesmo vale para timeout. Se a investigação encontrou uma hipótese, mas não conseguiu reproduzir o bug dentro do limite, o recibo deve preservar a hipótese, os comandos já executados e o ponto de retomada. Assim, a próxima pessoa continua o trabalho em vez de repetir a sessão às cegas.

Recibo não é despejo de logs

Há um risco óbvio em registrar tudo: a evidência pode virar mais cara de ler do que o próprio diff. Logs extensos também podem carregar tokens de acesso, dados de usuário, caminhos locais e outros detalhes que não deveriam aparecer num comentário de pull request.

Eu manteria no corpo do recibo apenas comandos, resultados, artefatos e decisões que mudam o aceite da tarefa. Saídas longas podem ficar em arquivos separados, com referência curta. Dados sensíveis precisam ser removidos antes que o agente salve ou publique qualquer material.

Essa redução é importante. Observabilidade útil permite responder "por que aceitamos este resultado?" sem obrigar o revisor a ler cada passo interno do modelo.

Um template para usar na próxima tarefa

Dá para começar sem trocar de ferramenta. Acrescente este contrato ao prompt, à issue ou ao workflow que recebe o resultado:

## Resultado da execução

- Status: concluído | bloqueado | timeout | revisão necessária
- Objetivo recebido:
- Escopo permitido:
- Alterações realizadas:
- Validações executadas e resultados:
- Evidências geradas:
- Motivo de encerramento:
- Riscos ou cenários não validados:
- Próximo passo recomendado:

Depois, ajuste a seção de evidências ao tipo de tarefa. Um fluxo visual pode pedir captura e console. Uma migração pode pedir execução de ida e volta. Uma correção de API pode pedir teste de regressão e resposta observada.

O ganho aparece na revisão diária. O time passa a conferir artefatos em vez de avaliar o tom da resposta. Uma parada incompleta volta como estado explícito, pronto para ser tratado pelo workflow.

Na próxima vez que aparecer "tarefa concluída", não peça uma explicação mais bonita. Peça objetivo, alterações, validações, evidências e motivo de encerramento. A resposta pode até ficar menor. O trabalho fica muito mais fácil de conferir.