Dê ao Claude uma tarefa grande o suficiente e ele vai parar no meio do caminho, convencido de que terminou. O trabalho não está completo. Ele simplesmente não se 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 fez 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 Única Janela Não Consegue Finalizar o Trabalho
Dê a um modelo de codificação de ponta um prompt de alto nível - "construa um clone do claude.ai" - coloque-o em um loop através de 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 agentes 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 executar o aplicativo inteiro em uma única janela, fica sem contexto no meio de uma funcionalidade, e a sessão termina com algo pela metade e sem documentação. O próximo turno chega, vê uma bagunça que não fez, e precisa adivinhar o que estava acontecendo. Então, gasta toda a sua sessão apenas tentando fazer o aplicativo básico funcionar novamente, em vez de avançar.
A segunda aparece depois, quando algumas funcionalidades já 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 considerou a tarefa concluída sem verificar a lista.
Ambas as falhas têm a mesma raiz. O turno que sai não deixou nada para trás, então o turno que chega está voando às cegas. A solução não é um modelo mais inteligente. É o que o turno anota antes de bater o ponto.
O que o Turno que Sai Anota
A resposta que a Anthropic encontrou tem duas partes: um agente que configura o site antes de qualquer trabalho começar, e então os trabalhadores de turno que aparecem sessão após sessão para fazer progresso.
O agente de configuração roda uma vez, bem no início. Todo o seu trabalho é deixar o ambiente em um estado onde todos os turnos futuros saibam como é o "concluído". A peça-chave que ele escreve é uma lista de funcionalidades - um arquivo estruturado que detalha cada coisa que o aplicativo finalizado 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": "O botão Novo Chat cria uma conversa nova",3 "steps": ["clicar em Novo Chat", "verificar conversa nova", "verificar estado inicial"],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 é a coisa que impede um agente de declarar vitória cedo. Um turno não pode olhar ao redor e decidir que o trabalho está feito, porque há um arquivo ali com 200 caixas não marcadas. O trabalho é definido antes da primeira linha ser escrita.
Um pequeno detalhe que mostra o quão cuidadoso isso precisava ser: eles usaram JSON para aquele arquivo, não Markdown. A razão é que o modelo tem menos probabilidade de reescrever ou deletar silenciosamente um arquivo JSON do que um Markdown. E as instruções em torno disso são diretas de propósito - é inaceitável remover ou editar testes, porque deletar um teste é como uma funcionalidade desaparece silenciosamente. O turno pode marcar uma caixa. Ele 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 commita 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 alguns minutos, em vez de passar uma hora fazendo engenharia reversa.
O git faz algo mais aqui também. 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 de desfazer.
E "limpo" tem um significado específico. Significa o tipo de código que você ficaria tranquilo em mesclar em uma 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 Assume
Coloque essas duas coisas no lugar e todo turno começa da mesma forma. Antes de tocar em algo novo, o agente executa uma rotina de abertura fixa para se situar - a mesma coisa que um bom engenheiro faz ao entrar 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 você 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 foi concluída4inicie o aplicativo e execute uma verificação básica para confirmar que as funcionalidades principais ainda funcionam5só então, comece a construir
Esse quarto passo é mais importante do que parece. Antes de escrever uma única funcionalidade nova, o agente inicia o aplicativo e confirma que o básico ainda funciona - abre um chat, envia uma mensagem, recebe uma resposta. Se o último turno deixou algo quebrado, isso é detectado imediatamente, antes que o novo turno empilhe trabalho novo sobre uma base quebrada e piore a situação.
Este é o truque todo, e é quase chato de tão simples. O turno que sai anota 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á assumindo sem memória do anterior - e se você não deixou uma instrução de transferência, ele começa adivinhando.
Então deixe uma. Antes de uma sessão longa terminar, peça ao modelo para anotar o que foi feito, o que ainda está pendente, e o que a próxima sessão deve pegar primeiro. Mantenha essa nota em algum lugar onde ele a 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.
Mesmo modelo hoje à noite e amanhã. A única coisa que muda é se a sessão de amanhã entra cega, ou entra lendo o bilhete da noite passada.
Nunca foi sobre o quão inteligente é o turno. É sobre o que ele deixa para o próximo que vem.
Mais análises como esta - https://t.me/+xYv1MgmIuds5YTli
