o problema
Um agente que trabalha por horas ou dias não trabalha continuamente. Ele trabalha em sessões discretas, e cada sessão nova começa sem memória da anterior. A analogia do próprio texto é boa: um projeto de software tocado por engenheiros em turnos, onde cada engenheiro que entra não lembra de nada do turno passado. Como a janela de contexto é limitada e projeto complexo não cabe numa janela, alguém precisa fazer a ponte entre um turno e outro.
A resposta óbvia é compactação — resumir o contexto antes de estourar e seguir em frente. Não basta. Rodando o Claude Agent SDK em loop com Opus 4.5 e um prompt de alto nível, tipo “construa um clone do claude.ai”, a Anthropic viu duas falhas. A primeira: o agente tenta fazer o app inteiro de uma vez, estoura o contexto no meio da implementação e deixa a feature pela metade e sem documentação — a sessão seguinte gasta o tempo dela adivinhando o que aconteceu e tentando fazer o básico voltar a funcionar. A segunda aparece mais tarde no projeto: já existe código funcionando, o agente olha em volta, vê progresso e declara o trabalho concluído.
a ideia
Se o problema é que a memória some, pare de confiar na memória. O estado que importa vai para o disco, em formato que a próxima sessão consegue ler em poucos tokens: uma lista de features com status, um arquivo de progresso e o histórico do git.
Isso divide o trabalho em dois prompts. O primeiro, do agente inicializador, roda uma vez e monta o ambiente. Os demais, do agente de codificação, pedem sempre a mesma coisa: entenda onde as coisas estão, avance uma feature, deixe o ambiente limpo. “Limpo” tem definição operacional — o código que você mandaria para a main: sem bug grave, organizado, documentado, sem sujeira que o próximo tenha que arrumar antes de começar. Vale registrar que “dois agentes” é um jeito de falar: só o prompt inicial de usuário muda, o system prompt, as ferramentas e o harness são os mesmos.
como funciona
O inicializador escreve três coisas: um init.sh que sobe o servidor de desenvolvimento, um claude-progress.txt que serve de log das sessões, e um commit inicial do git. Escreve também o artefato central — um arquivo de requisitos que expande o prompt do usuário em features end-to-end. No clone do claude.ai foram mais de duzentas, no nível de “o usuário abre um chat novo, digita uma pergunta, aperta enter e vê uma resposta”. Todas nascem marcadas como falhando, para que o agente seguinte veja o tamanho real do que falta.
O formato é JSON, com category, description, uma lista de steps e um booleano passes. A escolha do JSON foi empírica: o modelo mexe indevidamente menos em JSON do que em Markdown. Aos agentes de codificação é permitido editar só o campo passes, com instrução deliberadamente dura no prompt — remover ou editar teste é inaceitável, porque esconde funcionalidade quebrada.
Toda sessão começa com uma rotina de orientação: rodar pwd, ler o arquivo de progresso e o git log, ler a lista de features, escolher a de maior prioridade que ainda não passa. Antes de escrever qualquer código, sobe o servidor com o init.sh e roda um teste básico — no clone, abrir um chat, mandar mensagem, receber resposta. Se o app está quebrado, conserta antes; começar feature nova em cima de estado quebrado só piora. No fim, commit com mensagem descritiva e atualização do arquivo de progresso. O git também vira mecanismo de recuperação: dá para reverter mudança ruim e voltar a um estado que funcionava.
A verificação usa ferramenta de browser automation — Puppeteer via MCP, com screenshot. Sem essa instrução explícita, Claude testava com unit test e curl contra o servidor, e não percebia que a feature não funcionava para um humano.
o que isso custou
O texto é honesto sobre onde a receita vaza. A verificação por browser esbarra nos limites da visão do modelo e da ferramenta: Claude não enxerga modal nativo de alerta do navegador pelo Puppeteer MCP, e as features que dependem desses modais ficaram mais bugadas. O que não é observável não é testado, e o que não é testado é marcado como pronto.
A lista de features protege contra declarar vitória cedo, mas depende de o inicializador ter enumerado bem — o que sobra fora da lista simplesmente não existe para as sessões seguintes. E há a lentidão embutida: uma feature por sessão, com ritual de orientação e commit em cada uma.
Duas questões ficam abertas por escrito. Não se sabe se um agente de codificação geral é melhor que uma arquitetura multiagente com papéis especializados — testes, qa, limpeza de código. E a demonstração inteira é otimizada para desenvolvimento de app web full-stack; generalizar para pesquisa científica ou modelagem financeira é hipótese, não resultado.
onde isso aparece hoje
É a aplicação concreta do princípio que a Anthropic vinha formulando em Effective context engineering for AI agents: tratar contexto como recurso escasso e externalizar estado. O harness descrito roda sobre o Claude Agent SDK, e a rotina de arquivo de progresso, commit descritivo e teste antes de codar ecoa o que já estava em Claude Code: Best practices for agentic coding.
A ferramenta de teste chega pelo Model Context Protocol — o Puppeteer é um servidor MCP, e é ele que transforma “o código compila” em “o usuário consegue usar”. A pergunta que o texto deixa aberta sobre agentes especializados é exatamente o terreno de How we built our multi-agent research system, que resolveu essa divisão para pesquisa, não para código.