Agentes de código não precisam de mais memória — precisam de continuidade

Agentes de código não precisam de mais memória — precisam de continuidade

O diagnóstico parece óbvio: o agente de código perde o fio da meada entre uma sessão e outra porque a janela de contexto é pequena demais. A solução? Uma janela maior. Mais memória vetorial. Mais armazenamento de tudo que o agente já viu, tocou ou gerou.

Mas segundo Santi Santamaria Medel, desenvolvedor que passou meses iterando sobre uma camada de continuidade operacional para agentes de código, essa é a resposta errada para a pergunta certa. Em uma reflexão detalhada publicada no Level Up Coding, ele argumenta que o problema real não é memória — é continuidade.

“Contexto é o que o agente tem disponível agora. Continuidade é o que permite à próxima execução continuar de onde a anterior realmente parou. Não são a mesma coisa”, explica.

O problema do “lembrar de tudo”

A abordagem ingênua de memória para agentes — acumular resumos, notas e histórico de chat em uma base vetorial — funciona por um tempo. Depois começa a apodrecer. Suposições antigas se misturam com fatos verificados. Abordagens que falharam ficam lado a lado com as que funcionaram, com o mesmo peso visual. O agente recupera algo que “soa relacionado”, mas ninguém sabe se aquilo é atual, útil, contradito ou uma alucinação bem-educada de três sessões atrás.

O insight central de Medel é que a diferença entre um item de memória e um registro de continuidade é enorme. Uma memória fraca diz: “Provavelmente consertamos o parser mudando o tokenizador.” Um registro de continuidade forte diz:

• Tarefa: corrigir edge case do parser
• Arquivos editados: src/parser/tokenizer.py, tests/test_parser.py
• Comando executado: pytest tests/test_parser.py
• Resultado: passou
• Falha conhecida: suíte completa ainda não foi executada
• Próxima ação: rodar grupo completo de testes do parser
• Qualidade da evidência: parcial

O repositório é a fronteira natural

Medel defende que a continuidade deve viver no repositório, não em uma nuvem oculta ou em uma caixa-preta proprietária. Como artefatos locais e inspecionáveis, ela pode ser revisada pelo usuário, lida por qualquer agente compatível, limpa, corrigida ou ignorada. “Repositórios sobrevivem a chats”, resume.

O loop operacional que ele propõe é simples: retomar → trabalhar → finalizar → retomar. A cada ciclo, o agente parte de um estado delimitado, executa o trabalho e registra evidências factuais para a próxima execução.

Memória de falhas: o ponto de virada

Uma das descobertas mais importantes foi que lembrar falhas é mais útil que lembrar sucessos. Um agente de código desperdiça muito tempo repetindo erros plausíveis: abre o arquivo errado porque o nome parece certo, executa o mesmo comando que já falhou, tenta o mesmo fix porque a mensagem de erro parece familiar.

Uma camada de memória de falhas muda isso — não dizendo “nunca faça isso de novo”, mas informando: “Isso falhou antes. Aqui está o comando. Aqui está o erro. Aqui está a área. Aqui está se foi resolvido depois. Trate como contexto, não como verdade.”

Contratos de execução e MCP

Além da memória de falhas, Medel introduziu contratos de execução — guias compactos que moldam a próxima execução sem engessá-la. E o MCP (Model Context Protocol) emergiu como a interface ideal para expor essa camada de continuidade a agentes compatíveis, mantendo limites de segurança claros entre o que é estado local e o que pode ser compartilhado via Git.

A lição arquitetural central: menos memória genérica, mais continuidade operacional. Menos estado oculto, mais evidência inspecionável.