Ideia principal

Normalmente organizamos o que queremos reter por tema: um arquivo por assunto, uma pasta por domínio. A memória de um agente não se divide assim. Ela se divide pelo tempo durante o qual cada coisa continua verdadeira.

Três camadas, e cada uma tem uma regra de escrita diferente. O imediato é o que a sessão atual tem à mão, e desaparece com ela. O log diário registra o que aconteceu hoje — um bug encontrado, uma correção tentada, um ponto que ficou em aberto — e perde o interesse em poucos dias. A memória longa, em um long_memory.md mantido atualizado, guarda só o que ainda valerá daqui a seis meses: um fato técnico estabelecido, uma regra do projeto, uma decisão estruturante.

A mesma informação, portanto, não é escrita no mesmo lugar dependendo do momento. "A extração do transcript estava falhando hoje de manhã" pertence ao log do dia; "o hook precisa ser chamado a partir de /tmp" pertence à memória longa. Confundir as duas produz ou um diário que ninguém relê, ou uma memória longa diluída em anedota.

Por que isso importa

O critério de organização decide o que dá para recarregar. Uma memória por assunto obriga a reler tudo para saber em que pé está o trabalho; uma memória por tempo de vida permite dizer "me dá a memória longa e os dois últimos dias" e obter exatamente o necessário para retomar.

É também o que torna possível uma política de esquecimento. Uma camada que sabemos que vai vencer pode ser arquivada sem discussão.

Nuances e limites

O tempo de vida de uma informação é julgado no momento em que ela é escrita, ou seja, no pior momento possível: uma decisão tomada hoje de manhã parece estruturante, e seis semanas depois não passa de um detalhe de implementação abandonado.

E as camadas vazam: um log diário sempre contém um fato duradouro que ninguém promoveu.

Questões em aberto

• Por qual sinal reconhecemos que uma linha do log do dia pertencia, na verdade, à memória longa?