Dê ao Claude uma tarefa grande o suficiente e ele vai desistir no meio do caminho, convencido de que terminou. O trabalho não está concluído. Ele simplesmente não lembra de ter começado.
Um agente não trabalha em uma tarefa longa do jeito que você imagina. Ele trabalha em turnos.
Imagine um projeto de software com engenheiros trabalhando em turnos, onde cada novo chega sem memória do que aconteceu no turno anterior. Isso não é uma metáfora para como os agentes se sentem. É mecanicamente o que eles são. A janela de contexto é finita, a maioria dos trabalhos reais não cabe dentro dela, então o agente trabalha em sessões discretas — e cada nova sessão começa sem memória da anterior.
A Anthropic rodou exatamente esse experimento e publicou o que quebrou. Essa é a parte que vale a pena ler, porque não é um blogueiro dizendo que a ferramenta é fraca. É a equipe que constrói o Claude documentando onde o Claude falha.
Por que uma janela não consegue concluir o trabalho
Dê a um modelo de codificação de ponta um prompt de alto nível — "crie um clone do claude.ai" — coloque-o em um loop por várias janelas de contexto, e ele falha em produzir um aplicativo funcional. Não às vezes, mas de forma confiável. E isso é o Opus rodando na própria estrutura de agente da Anthropic, com compactação de contexto ativada, toda a configuração feita para mantê-lo funcionando.
Ele falha de duas maneiras específicas, e ambas são problemas de transferência de turno.
A primeira: o agente tenta fazer tudo de uma vez. Ele tenta criar o aplicativo inteiro em uma única janela, fica sem contexto no meio de uma funcionalidade, e a sessão termina com algo meio construído e sem documentação. O próximo turno chega, vê uma bagunça que não foi ele quem fez, e precisa adivinhar o que estava acontecendo. Então, gasta toda a sua sessão apenas tentando fazer o aplicativo básico funcionar de novo, em vez de avançar.
A segunda aparece mais tarde, depois que algumas funcionalidades existem. Um novo agente olha ao redor, vê que um progresso real foi feito, e decide que tudo está concluído. Mas não está — metade das funcionalidades nunca foram construídas, e ninguém anotou quais. O turno deu o trabalho por encerrado sem verificar a lista.
Ambas as falhas têm a mesma raiz. O turno que está saindo não deixou nada para trás, então o turno que chega está voando às cegas. A correção não é um modelo mais inteligente. É o que o turno escreve antes de bater o ponto.
O que o turno que está saindo escreve
A resposta em que a Anthropic chegou tem duas partes: um agente que configura o site antes de qualquer trabalho começar, e depois os trabalhadores de turno que aparecem sessão após sessão para fazer progresso.
O agente de configuração é executado uma vez, bem no início. O trabalho dele é deixar o ambiente em um estado onde todo turno futuro saiba como é o "pronto". A peça-chave que ele escreve é uma lista de funcionalidades — um arquivo estruturado detalhando cada coisa que o aplicativo final precisa fazer.
Para o clone do claude.ai, isso significou mais de 200 funcionalidades. Coisas como "um usuário pode abrir um novo chat, digitar uma consulta, pressionar Enter e ver uma resposta." Cada uma delas marcada como falha no início. Cada entrada era mais ou menos assim:
1{2 "description": "Botão de novo chat cria uma conversa fresca",3 "steps": ["clicar em Novo Chat", "verificar conversa fresca", "checar estado de boas-vindas"],4 "passes": false5}
Esse "passes": false em cada entrada é o ponto principal. É uma caixa não marcada, e são 200 delas.
Essa lista de falhas é o que impede um agente de declarar vitória cedo demais. Um turno não pode olhar ao redor e decidir que o trabalho está pronto, porque há um arquivo ali com 200 caixas não marcadas. O trabalho é definido antes de a primeira linha ser escrita.
Um pequeno detalhe que mostra o cuidado que foi necessário: eles usaram JSON para esse arquivo, não Markdown. A razão é que o modelo tem menos probabilidade de reescrever ou deletar silenciosamente um arquivo JSON do que um de Markdown. E as instruções ao redor são deliberadamente diretas — é inaceitável remover ou editar testes, porque deletar um teste é como uma funcionalidade desaparece silenciosamente. O turno pode marcar uma caixa. Não pode apagar uma.
O bilhete na mesa
Configurar o trabalho é metade do caminho. A outra metade é garantir que cada turno deixe o lugar limpo o suficiente para o próximo entrar.
Duas coisas fazem isso. O agente salva seu trabalho no Git com uma mensagem real descrevendo o que mudou, e escreve um arquivo de progresso simples — um registro contínuo do que foi feito. Esse registro, junto com o histórico do Git, é o que permite que um novo agente, começando do zero, entenda o estado das coisas em poucos minutos em vez de passar uma hora fazendo engenharia reversa.
O Git também faz outra coisa aqui. Quando um turno faz uma alteração ruim, o próximo pode reverter para a última versão funcional em vez de tentar desembaraçar o estrago. O arquivo de progresso diz onde estamos. O histórico de commits é o botão "desfazer".
E "limpo" tem um significado específico. Significa o tipo de código que você não se importaria em mesclar a um branch principal — sem grandes bugs, organizado, documentado. Não "tecnicamente eu fiz progresso". O padrão é: a próxima pessoa poderia começar uma nova funcionalidade sem primeiro limpar a sua bagunça.
Como o próximo turno bate o ponto
Coloque essas duas coisas no lugar e todo turno começa da mesma forma. Antes de tocar em qualquer coisa nova, o agente executa uma rotina de abertura fixa para se situar — a mesma coisa que um bom engenheiro faz ao chegar em um projeto que não vê há um tempo.
1execute pwd para ver em qual diretório você está — esse é o único lugar onde pode editar2leia o arquivo de progresso e o log do Git para ver o que aconteceu recentemente3leia a lista de funcionalidades e escolha a de maior prioridade que ainda não está pronta4inicie o aplicativo e execute uma verificação básica de que as funcionalidades principais ainda funcionam5só então, comece a construir
Esse quarto passo é mais importante do que parece. Antes de escrever uma única nova funcionalidade, o agente inicia o app e confirma que o básico ainda funciona — abre um chat, envia uma mensagem, recebe uma resposta. Se o turno anterior deixou algo quebrado, isso é pego imediatamente, antes que o novo turno empilhe trabalho novo em cima de uma base quebrada e piore as coisas.
Esse é o truque inteiro, e é quase entediante de tão simples. O turno que está saindo escreve o que fez e o que falta. O turno que chega lê isso antes de fazer qualquer coisa. A transferência é o jogo inteiro.
Suas tarefas longas também têm turnos
Nada disso é realmente sobre construir aplicativos web. A Anthropic testou isso em código porque código é fácil de verificar, mas a estrutura subjacente é a estrutura de toda tarefa longa que você entrega a um agente.
Qualquer coisa que não caiba em uma janela tem turnos. Escrever um relatório longo capítulo por capítulo. Conduzir um projeto de pesquisa em uma dúzia de chats. Trabalhar em uma análise grande ao longo de dias. Toda vez que você inicia uma nova sessão na mesma tarefa, um novo trabalhador está batendo o ponto sem memória do anterior — e se você não deixou uma transferência, ele começa adivinhando.
Então deixe uma. Antes de uma sessão longa terminar, peça ao modelo para escrever o que foi feito, o que ainda está aberto e o que a próxima sessão deve pegar primeiro. Mantenha essa nota em algum lugar que ele leia ao entrar. É a diferença entre um projeto que avança a cada sessão e um que fica reconstruindo a mesma coisa repetidamente.
O mesmo modelo hoje à noite e amanhã. A única coisa que muda é se a sessão de amanhã chega cega, ou chega lendo a nota da noite passada.
Nunca foi sobre o quão inteligente o turno é. É sobre o que ele deixa para o próximo que virá.
Mais análises como esta — https://t.me/+xYv1MgmIuds5YTli
