Memória de agente não é uma janela maior

A primeira coisa que se sente quando se começa a trabalhar a sério com agentes é o custo do arranque a frio. Abres o terminal, e a coisa não sabe quem és, em que projeto estás, o que decidiste na semana passada nem porquê. Passas quinze minutos a explicar. Fechas. No dia seguinte explicas outra vez.

A reação instintiva é pedir mais janela de contexto. Se coubesse tudo, não era preciso repetir nada. Trabalhei algum tempo com essa ideia e ela está errada por duas razões diferentes, e é a segunda que interessa.

A janela maior compra tempo, não resolve

A razão fácil é económica: mais contexto é mais tokens em cada pedido, e o custo cresce com a conversa. Mas essa ainda se aguenta com dinheiro.

A razão que não se resolve com dinheiro é que despejar tudo na janela degrada a qualidade da resposta. Um agente com quarenta ficheiros irrelevantes à frente escolhe pior do que um agente com três ficheiros certos. O contexto não é um depósito onde arrumar coisas por via das dúvidas — é a atenção do modelo, e atenção dividida é atenção gasta. Isto não é uma limitação de versão que passa com a próxima; é a forma como a coisa funciona.

O problema nunca foi quanto cabe. Foi o que entra, e quando.

O que fiz em vez disso

Construí a memória como um repositório de ficheiros de texto, com uma regra de leitura em cima. Não é sofisticado, e é precisamente por isso que funciona:

• Um ficheiro de perfil, curto e com limite de tamanho declarado, lido sempre. Quem sou, como quero as respostas, o que nunca se faz sem perguntar. Se ultrapassa cem linhas, alguma coisa lá dentro não era durável.
• Um índice, lido a seguir. Não contém conhecimento — contém ligações, cada uma com uma frase a dizer o que está do outro lado. É esta frase que permite ao agente decidir se precisa de abrir.
• Páginas de conhecimento, lidas só se o índice as apontar como relevantes. Cada afirmação durável cita a origem: o ficheiro de onde veio, ou a data em que eu a confirmei.
• Perfis de projeto, um por projeto, com o estado atual. O estado vive aqui e em mais lado nenhum, para não haver duas versões da verdade a divergir em silêncio.

A parte que mais me custou a aceitar foi a disciplina de escrita. É tentador deixar o agente escrever para a memória sempre que aprende alguma coisa. Faz-se isso duas semanas e o que se tem é uma pilha de notas contraditórias sem proveniência. A regra que ficou: só entra o que é durável, compacto e confirmado por mim. Uma decisão de arquitetura entra. O que fizemos ontem à tarde não entra — isso é histórico de Git, e o Git já o guarda melhor.

A distinção que faz o sistema funcionar

Se levares só uma coisa daqui, leva esta: há dois tipos de informação a circular numa sessão, e tratá-los da mesma maneira é o erro de origem.

Estado é o que muda: em que ponto vai o projeto, o que falta, o que está bloqueado. Vive nos ficheiros do projeto, é sobrescrito quando muda, e não interessa a ninguém daqui a um ano.

Conhecimento é o que não muda: porque é que se escolheu esta abordagem e não a outra, o que se aprendeu quando falhou, a regra que nasceu daí. Vive na wiki, acumula-se, e é isto que vale a pena carregar entre sessões.

Um sistema que mistura os dois enche-se de estado velho a fingir de conhecimento. Foi o que me aconteceu à primeira, e foi preciso deitar fora e recomeçar com a separação feita à cabeça.

O que isto tem de portátil

Nada do que descrevi depende da ferramenta que uso. É Markdown, ficheiros e uma convenção de leitura — corre em qualquer agente que saiba abrir um ficheiro. Foi decisão deliberada: as ferramentas desta área mudam de mês para mês, e um sistema de memória preso a uma delas é um sistema com data de validade.

Trabalho em duas máquinas. O contexto viaja entre elas num repositório Git, como código. É a parte mais aborrecida da solução e é a que a torna real: a memória só conta como memória quando sobrevive a fechar o portátil.