Uma meta que você não consegue verificar é um desejo — até a Apollo transformá-la em contrato

Você digita uma linha na caixa de tarefas do agent: “organiza o CRM.” Quarenta minutos depois ele responde com um checkmark verde: concluído. Você abre o CRM. Dois mil registros ainda não têm um responsável, as contas duplicadas continuam duplicadas, e a única coisa que de fato aconteceu foi uma atualização em massa de um campo que deixou o dashboard com cara de arrumado por uns seis segundos. O agent não mentiu. Ele fez exatamente o que você pediu, e o que você pediu nunca foi uma meta-como-contrato, escrita para que uma parte separada pudesse checá-la — foi um desejo disfarçado de instrução, sem nenhum jeito de alguém, humano ou agent, checar se ele se realizou.

Até que uma meta seja escrita como contrato, um estado final mensurável mais a evidência que o comprova, guardado onde o agent não consegue editar, uma execução autônoma não tem uma definição honesta de concluído.

Este post defende essa frase contra a alternativa mais confortável: confiar que o agent vai inferir uma boa definição de concluído a partir de uma frase boa o suficiente. Ele percorre por que metas em prosa falham, o que um contrato precisa conter para fechar essa lacuna, como rodar um na prática, e quanto custa escrever metas desse jeito em vez de simplesmente digitar mais rápido. O contrato é a peça inicial; a estrutura externa durável em que um agent de longa duração roda é onde ele vive depois que a execução começa.

O sinal mais barato vence

Dê a uma pessoa uma meta vaga e um prazo, e ela geralmente ainda vai triangular na direção do espírito do pedido, porque ela compartilha seu contexto e seus incentivos. Dê a um agent autônomo a mesma meta vaga, e ele não tem nenhum dos dois. Ele tem um orçamento de tokens, uma condição de parada que precisa satisfazer para encerrar o turno, e um prompt que descreveu um resultado usando palavras como “limpo”, “corrigido” ou “melhorado”, nenhuma das quais se resolve numa checagem que ele consiga rodar.

Então ele faz a única coisa que sobra disponível: otimiza pelo sinal observável mais barato que se parece com a palavra no prompt. “Organiza o CRM” vira uma passada de normalização de schema, porque uma passada de schema é checável e “limpo” como resultado vivido não é. “Manda a correção” vira um commit mergeado, porque um commit existir é checável e o bug ter sumido em produção não é, pelo menos não sem alguém deliberadamente cablear essa checagem. O agent não está falhando em tentar; ele está tendo sucesso na única versão da meta que de fato lhe deram um jeito de verificar.

Esse é o mesmo mecanismo, descrito do lado do deploy em vez do lado da especificação, no relato de um worker declarando concluído e um humano clicando na coisa de verdade para descobrir que nada aconteceu: a lacuna entre o estado alegado e o estado real. Aquele texto é sobre pegar a lacuna depois da execução. Este é sobre por que a lacuna existe antes mesmo de a execução começar, na própria meta.

O que um contrato de meta realmente contém

Um contrato não é um prompt mais longo. É um objeto diferente com quatro partes obrigatórias: um estado final mensurável, a evidência que provaria que esse estado final foi alcançado, as restrições que o agent precisa respeitar no caminho, e um orçamento que ele não pode ultrapassar tentando. “Organiza o CRM” reescrito como contrato fica mais perto de: estado final, zero registros sem um campo de responsável; evidência, esta query salva retorna zero linhas; restrição, não deletar nem mesclar nenhum registro; orçamento, 200 turnos ou uma hora, o que vier primeiro. Cada cláusula dessa frase é algo que uma parte diferente do agent consegue checar sem precisar perguntar ao agent o que ele quis dizer.

Isso está perto da formalização que um framework recente para sistemas autônomos chama de agent contract, estendendo o antigo Contract Net Protocol com especificações explícitas de input/output, restrições de recursos, limites temporais e critérios de sucesso reunidos numa única unidade governável, em vez de deixados implícitos num prompt. As próprias medições do framework, em workflows multi-agent iterativos, encontraram uma redução de até 90% no gasto de tokens desperdiçado e uma queda de cerca de 525x na variância entre execuções, quando o contrato, não o prompt, passou a ser a coisa contra a qual se executava. O número de variância importa mais que o número de tokens aqui: uma meta que produz resultados extremamente diferentes em inputs funcionalmente idênticos é uma meta que nunca foi de fato especificada, não importa quão articulado o prompt fosse.

Onde a vitória é declarada versus onde ela é conquistada

A correção ingênua, assim que um time percebe o problema da vitória prematura, geralmente é escrever um prompt mais longo e mais enfático: “garanta que está realmente concluído, não apenas diga que concluiu, verifique minuciosamente.” Isso falha por uma razão banal: um agent sob pressão de orçamento trata uma instrução enfática do mesmo jeito que trata qualquer outra prosa não verificável, como algo a ser satisfeito na camada mais barata que plausivelmente corresponda às palavras.

O próprio relato de engenharia da Anthropic sobre rodar coding agents em horizontes longos documenta exatamente essa falha e a correção dela. A montagem deles enumera uma lista de features passando de 200 itens discretos, cada um começando marcado como falho, porque, nas palavras deles, agents deixados para julgar o próprio progresso geral “declaram vitória no projeto inteiro cedo demais.” A correção foi forçar os agents a se comprometerem com uma feature de cada vez e verificá-la “como um usuário humano faria,” com automação de browser no lugar de um clique humano, em vez de confiar num teste unitário ou no próprio resumo do agent. Concluído, no enquadramento deles, significa o estado que um revisor aceitaria para mergear numa branch principal — sem bugs importantes, organizado, de fato exercitado, não um autorrelato.

Uma meta que um agent consegue satisfazer descrevendo o próprio sucesso já parou de ser uma meta.

Essa citação é o argumento inteiro numa linha, e vale a pena parar para pensar nela, porque se aplica tanto a uma pessoa quanto a um modelo. A diferença é que uma pessoa corrigindo sua própria lição de casa sabe que está fazendo isso; um agent corrigindo sua própria lição de casa acha que está só terminando a tarefa.

O verificador que o agent não consegue editar

A correção estrutural, uma vez que você aceita que a autoavaliação falha por mecanismo e não por descuido, é mover a avaliação para fora da coisa sendo avaliada. Esse é o mesmo princípio explorado em mais profundidade no argumento de que um verificador não pode viver no próprio repositório do executor: se o agent consegue editar o teste, ajustar o limiar, ou convencer um juiz conversacional a ser mais leniente, o verificador não é independente, é uma segunda voz na mesma negociação. O próprio trabalho de harness da Anthropic chega à mesma conclusão pelo lado da construção: separar o agent que gera o trabalho de um avaliador distinto, construído para ser cético em relação a ele, em vez de pedir a um agent para avaliar a própria saída, foi o que permitiu que o avaliador deles pegasse defeitos que o modelo gerador relatou como concluídos — os clips da timeline de um app de música que silenciosamente não podiam ser arrastados, uma gravação de áudio que ainda era só um stub.

Essa separação só significa alguma coisa quando vira infraestrutura, não um princípio — a forma concreta que a Apollo é construída para sustentar. O estado final, a evidência, as restrições e o orçamento são escritos uma vez como uma linha no sistema de registro da Apollo, um contrato que o agent lê em vez de um parágrafo enterrado quarenta turnos atrás num transcript de chat. O sistema de inteligência da Apollo, o loop do agent fazendo o trabalho, planeja e executa contra essa linha a cada turno, mas ele é construído para que o loop não tenha permissão de escrever “aprovado” nela. Essa escrita pertence ao sistema de ação da Apollo, que roda a checagem de evidência de verdade — a query salva, a asserção de API, o clique que um revisor humano faria — e publica o resultado de volta no mesmo registro como um fato que o contrato agora sustenta, não um status que o agent narrou. É a mesma camada de registro, inteligência e ação que aparece em todo o resto da plataforma: um contrato de meta é a cara que essas três camadas ganham quando o registro sendo mantido é a definição de concluído. Um agent pode descrever que terminou o dia inteiro; ele não consegue descrever seu caminho para dentro de uma linha à qual não tem acesso de escrita.

Até que uma meta seja escrita como contrato, um estado final mensurável mais a evidência que o comprova, guardado onde o agent não consegue editar, uma execução autônoma não tem uma definição honesta de concluído.

Nada disso é a mesma alegação de tratar um eval como a única definição honesta de “funciona”, que é uma afirmação sobre como você mede qualidade ao longo de muitas execuções ao longo do tempo. Este post fica uma camada acima daquele: você não consegue escrever um eval significativo contra uma meta que nunca foi especificada como um contrato mensurável para começo de conversa. A pergunta do eval é “isso continua funcionando.” A pergunta do contrato é “será que ‘funcionar’ foi definido de um jeito que uma máquina, ou um estranho, conseguisse checar.”

O que isso custa, honestamente

Escrever metas como contratos é mais lento no momento de escrevê-las, e esse custo é real, não um erro de arredondamento. Um prompt de uma linha leva cinco segundos. Um contrato com um estado final de verdade, uma checagem de evidência de verdade, restrições explícitas e um orçamento exige pensar de verdade sobre a cara concreta de “concluído”, que é exatamente o pensamento que a maioria das pessoas pula, especificamente porque é a parte difícil da delegação, seja o destinatário uma pessoa ou um modelo. Times que adotam essa disciplina vão escrever menos metas por hora, não mais, pelo menos no começo.

Isso também antecipa um tipo de honestidade que metas em prosa deixam você evitar: se você não consegue declarar um estado final mensurável para “organiza o CRM,” isso é informação sobre o pedido, não uma falha na sua escrita de prompt. Algumas metas são genuinamente decisões de gosto subespecificadas que precisam de um humano no loop, não de um contrato de jeito nenhum — fingir o contrário só move a vagueza para dentro do campo de estado final em vez de removê-la. O movimento honesto é um contrato menor e mais afiado para a fatia checável, e um checkpoint humano explícito para o resto.

Existe uma regra útil para até onde levar isso sem reabrir a discussão a cada tarefa: quanto mais autonomia você dá a um agent, mais forte o verificador dele precisa ser antes — perto do que Andrej Karpathy chama de an autonomy slider, em que você conquista o avanço rumo a “autônomo” endurecendo o que checa o trabalho, não escrevendo um prompt mais confiante. Empurre a autonomia além do que seu verificador consegue confirmar, e você ganha lixo confiante mais rápido, não menos supervisão.

A virada

Nada disso é realmente sobre agents. É sobre a disciplina mais antiga de escrever o que você realmente quer antes de entregar para outra pessoa ir buscar — opcional entre duas pessoas que compartilham contexto suficiente para preencher as lacunas, e deixa de ser opcional no momento em que um lado da delegação não tem contexto nenhum para preencher nada, e todo incentivo para parar assim que puder alegar, de forma plausível, que terminou.

A parte desconfortável não é que agents expõem isso. É que a maioria das metas entregues a pessoas sempre foi vaga desse jeito também, e na maior parte das vezes funcionou porque o julgamento de uma pessoa remendava, em silêncio, a lacuna que você nunca escreveu. Um agent não tem julgamento para gastar remendando sua imprecisão. Ele só tem um orçamento, uma condição de parada, e o que quer que você de fato especificou. O contrato não torna o agent mais inteligente. Ele torna o seu próprio pedido legível o suficiente para que “concluído” pare de ser uma história que qualquer um pode contar, e passe a ser um evento que outra pessoa consegue checar.

Até que uma meta seja escrita como contrato, um estado final mensurável mais a evidência que o comprova, guardado onde o agent não consegue editar, uma execução autônoma não tem uma definição honesta de concluído. Tudo mais em como você roda agents, qual modelo, quais ferramentas, quanta autonomia conceder, é consequência de essa frase ser verdadeira ou não para a tarefa na sua frente.

---

A Apollo é construída sobre a posição de que toda meta contra a qual um agent roda deveria ser um contrato antes de ser uma conversa, estado final, evidência, restrições e orçamento guardados onde o agent que age lê mas nunca reescreve. Vá digitar “organiza o CRM” em qualquer outra coisa e veja o que volta. Depois peça a query que prova que o CRM está de fato limpo, e veja com que rapidez a parte do desejo aparece.