Agentes de IA deveriam dormir.
Contexto não é memória. Talvez agentes úteis precisem de um período offline para replay, consolidação, esquecimento e reescrita do que viveram.
A maior parte dos sistemas de memória para agentes de IA que eu vejo parte de uma ideia estranha:
se aconteceu, salve.
Conversa importante?
Salva.
Preferência do usuário?
Salva.
Resultado de ferramenta?
Salva.
Documento lido?
Indexa.
Resumo?
Salva também.
Se houver espaço, melhor ainda.
Isso parece razoável porque memória de computador é barata e esquecer soa como falha.
Só que um sistema que guarda tudo não necessariamente lembra bem.
Às vezes ele só acumula passado.
Eu acho que agentes de IA deveriam ter uma coisa parecida com sono.
Não sono como antropomorfismo fofo.
Um estado offline em que o agente não está respondendo ao mundo e usa tempo computacional para reorganizar o que viveu.
Replay.
Consolidação.
Compressão.
Detecção de conflito.
Esquecimento.
Teste de recuperação.
Talvez memória persistente fique muito melhor quando parar de ser um banco de dados que só recebe INSERT.
Context window não é memória
Um modelo com contexto grande parece ter memória porque consegue usar coisas que estão na janela atual.
Mas isso é mais parecido com uma mesa cheia de papéis.
Enquanto os papéis estão ali, tudo parece disponível.
Tira da mesa e acabou.
Memória persistente normalmente entra depois, via algum sistema externo:
vector database;
resumos;
perfil do usuário;
logs;
knowledge graph;
arquivos.
O problema é que escrever nesses sistemas durante a interação mistura duas tarefas diferentes:
viver uma experiência e decidir o que essa experiência significa a longo prazo.
Talvez isso seja cedo demais.
Se eu digo numa conversa:
“acho que quero aprender Rust”
isso é uma memória duradoura?
Talvez.
Se dez minutos depois eu digo:
“na verdade, Rust foi só curiosidade, meu foco continua Python”
qual das duas deveria sobreviver?
Se o agente grava cada frase como fato, vai precisar resolver conflito depois de qualquer maneira.
Então talvez a arquitetura correta seja admitir que experiência recente é provisória.
O cérebro não trata toda experiência como memória final
A analogia aqui tem alguma sustentação real, embora eu queira tomar cuidado para não fingir que entendemos memória humana completamente.
Existe bastante evidência de que sono participa de consolidação de memória.
Uma revisão na Nature Neuroscience descreve memória de longo prazo durante sono como um processo ativo de consolidação de sistemas. Representações associadas ao hipocampo são reativadas, e parte desse processo parece contribuir para integração em redes corticais e para formas mais abstratas de representação.
Outra revisão clássica descreve sono não apenas fortalecendo traços, mas também produzindo mudanças qualitativas: reorganização, novas associações e extração de regularidades.
Isso já é interessante por um motivo.
A memória não está apenas sendo copiada.
Ela está sendo reescrita.
Fonte: Mechanisms of systems memory consolidation during sleep e The memory function of sleep.
Reinforcement learning já usa replay
Do lado de machine learning, a ideia de reaprender a partir do passado também não é nova.
O DQN publicado pela DeepMind em 2015 usava experience replay: transições passadas eram armazenadas e amostradas durante treinamento.
Isso ajuda, entre outras coisas, a quebrar correlações temporais e reutilizar experiência.
Depois veio prioritized experience replay: em vez de rever todas as transições com a mesma frequência, transições mais informativas podem receber prioridade.
O paper reportou melhoria sobre replay uniforme em 41 de 49 jogos Atari naquele conjunto experimental.
Não estou dizendo que isso é equivalente a sono biológico.
Não é.
Estou dizendo que dois sistemas completamente diferentes chegaram a uma estrutura parecida:
experiência online e aprendizado a partir da experiência não precisam acontecer no mesmo instante.
Fonte: Human-level control through deep reinforcement learning e Prioritized Experience Replay.
Eu separaria memória em três tempos
Se eu estivesse projetando um agente pessoal hoje, criaria pelo menos três camadas.
A primeira seria um buffer episódico.
Quase tudo que aconteceu recentemente pode entrar ali.
Não como “verdade sobre o usuário”.
Como evento.
“Usuário disse X às 14:32 dentro do contexto Y.”
“Ferramenta retornou Z.”
“Plano A foi tentado e falhou.”
Essa camada é barata, temporal e pouco opinativa.
A segunda seria uma memória consolidada.
Aqui entram fatos, preferências, procedimentos e relações que sobreviveram algum processo de validação.
“Usuário prefere respostas em português.”
“Projeto usa PostgreSQL.”
“Deploy dessa aplicação exige etapa X.”
A terceira seria uma memória abstrata.
Não guarda apenas fatos, mas padrões.
“Quando esse usuário pede revisão de PR, ele valoriza invariantes arquiteturais antes de estilo.”
“Esse serviço costuma falhar depois de rotação de certificado.”
“Esse tipo de tarefa exige consultar fonte atual.”
Essa camada me parece particularmente importante.
É onde episódio vira regra.
O ciclo de sono
Eu faria o agente “dormir” depois de uma quantidade de atividade, ou em janelas agendadas.
O pipeline poderia ser mais ou menos assim.
Primeiro, selecionar episódios candidatos.
Não todos.
Eventos com surpresa alta.
Erros.
Correções do usuário.
Mudanças de preferência.
Resultados que contradizem memória existente.
Decisões repetidas.
Coisas reutilizadas várias vezes.
Depois, replay.
O agente recebe pequenos conjuntos de episódios e tenta reconstruir:
o que aconteceu;
o que era contexto local;
o que provavelmente continua verdadeiro;
o que conflita com memória anterior;
o que é padrão e o que é acidente.
Depois vem consolidação.
Criar ou atualizar memórias semânticas.
Mesclar duplicatas.
Versionar fatos que mudaram.
Reduzir confiança quando há conflito.
Apagar detalhes inúteis.
Por fim, teste de recuperação.
Perguntas sintéticas:
“qual banco esse projeto usa?”
“qual foi a causa do último incidente?”
“qual preferência do usuário vale quando existem duas declarações conflitantes?”
Se a memória não consegue responder com o que foi consolidado, talvez a consolidação esteja ruim.
Isso transforma memória em algo testável.
Esquecer deveria ser uma feature
A parte mais contraintuitiva é essa.
Eu colocaria esquecimento deliberado.
Memória infinita parece melhor até você lembrar que relevância cai.
Preferências mudam.
Projetos acabam.
APIs evoluem.
Pessoas testam ideias e abandonam.
Um agente que nunca esquece começa a carregar versões antigas do usuário como se fossem fósseis ainda autorizados a tomar decisão.
Talvez cada memória precise de:
confiança;
data de criação;
última confirmação;
escopo;
origem;
taxa de decaimento.
Uma preferência explícita e repetida decai devagar.
Uma inferência feita uma vez decai rápido.
Um fato de documentação oficial pode ser estável, mas precisa ser invalidado quando a versão do software muda.
Esquecimento não é deletar aleatoriamente.
É admitir que informação tem meia-vida.
Memória também precisa de garbage collection semântica
Imagine um agente que trabalha seis meses num projeto.
Ele viu:
vinte versões de um plano;
sete arquiteturas abandonadas;
centenas de mensagens de debug;
nomes temporários;
bugs corrigidos;
branches mortos.
Se tudo isso tiver o mesmo status de memória, retrieval começa a devolver lixo plausível.
Vector search não sabe que um documento morreu politicamente.
Ele sabe que o texto é parecido.
Então consolidação precisa entender supersessão.
“ADR 12 substitui ADR 7.”
“Esse endpoint foi removvido.”
“Essa hipótese foi descartada.”
“O usuário mudou de decisão.”
Talvez memória persistente precise de algo parecido com controle de versão e tombstones.
Não apenas embeddings.
Dormir pode reduzir alucinação de memória
Existe uma categoria específica de erro em agentes pessoais que eu acho perigosa.
O agente lembra uma coisa parecida com o que aconteceu, mas não exatamente.
Se a memória é formada por resumos sobre resumos, pequenas distorções podem ganhar status de fato.
Um ciclo offline pode ajudar porque permite comparar abstração com fonte episódica.
Toda memória consolidada deveria conseguir apontar para evidência.
Não necessariamente mostrar ao usuário toda vez.
Mas internamente deveria existir linhagem.
“Eu acredito em X por causa dos episódios A, B e C.”
Se uma nova experiência contradiz X, o sistema sabe o que revisar.
Sem provenance, memória vira folclore.
Replay não deveria favorecer só o dramático
Prioritized replay tem uma tentação óbvia quando levado para agentes.
Rever apenas eventos “importantes”.
Problema: importância imediata e importância futura não são a mesma coisa.
Um erro catastrófico merece replay.
Mas uma pequena preferência repetida vinte vezes também.
Um episódio muito surpreendente pode ser ruído.
Um padrão banal pode ser estrutural.
Então eu usaria amostragem mista.
Uma parte priorizada por surpresa.
Uma parte por frequência.
Uma parte aleatória.
Uma parte por recência.
Uma parte por baixa confiança.
Isso reduz o risco de a memória do agente virar uma autobiografia escrita só por incidentes.
O agente acordaria diferente
Aqui está a parte que eu acho realmente interessante.
Depois de consolidar, o agente não apenas teria mais memória.
Ele poderia ter políticas locais melhores.
Se várias sessões mostram que um workflow sempre exige os mesmos passos, o agente pode criar uma rotina.
Se um tipo de erro aparece repetidamente, pode criar uma checagem preventiva.
Se o usuário corrige o mesmo comportamento três vezes, pode ajustar uma preferência operacional.
Isso é mais do que memória factual.
É aprendizado do próprio processo.
Talvez um bom agente pessoal não seja aquele que “lembra tudo sobre você”.
É aquele que reduz a quantidade de vezes que precisa aprender a mesma coisa.
Isso também cria uma fronteira de segurança útil
Processos online precisam responder rápido.
Processos offline podem ser mais conservadores.
Eu não deixaria qualquer conversa editar diretamente regras de alto impacto.
Durante a interação, o agente pode propor:
“isso parece uma preferência persistente.”
Mas a consolidação pode verificar se existe conflito, escopo e evidência suficiente.
Isso é especialmente útil para memória inferida.
Uma frase não deveria alterar personalidade operacional do sistema imediatamente.
É parecido com banco de dados.
Nem todo evento precisa virar estado canônico no mesmo milissegundo.
A analogia com sono termina cedo
Agentes não têm metabolismo.
Não têm ciclos circadianos por necessidade biológica.
Não têm hipocampo.
Experience replay em RL não é sonho.
E sleep consolidation humano é muito mais rico do que qualquer pipeline de resumo.
Então eu não chamaria essa arquitetura de biologicamente inspirada num sentido forte.
Eu chamaria de uma boa ideia de sistemas que a biologia torna intuitiva:
separe aquisição de consolidação.
A gente já faz isso em outros lugares.
Banco tem WAL e compactação.
Storage tem garbage collection.
Streaming tem materialized views.
Git tem commits e depois squash/rebase quando faz sentido.
Dados brutos e modelo derivado não são a mesma coisa.
Talvez memória de agente tenha sido tratada simples demais porque “salvar texto e buscar depois” é fácil de demonstrar.
Eu implementaria isso antes de aumentar o contexto
Se eu tivesse que escolher entre dobrar a janela de contexto de um agente e dar a ele uma memória offline realmente boa, eu provavelmente testaria a segunda opção primeiro.
Contexto maior ajuda a manter mais coisas simultaneamente disponíveis.
Consolidação melhora o que merece voltar.
São problemas diferentes.
Um agente que trabalhou comigo por dois anos não deveria precisar carregar dois anos de conversa para saber como trabalhar.
Ele deveria ter transformado parte dessa experiência em estrutura.
E parte deveria ter sumido.
É isso que eu quero dizer com dormir.
Não desligar.
Não fingir que sonha.
Parar de responder por um tempo computacional e fazer manutenção da própria história.
Rever o que aconteceu.
Descobrir o que ainda vale.
Juntar coisas que pareciam separadas.
Diminuir detalhes.
Apagar lixo.
Fortalecer o que reaparece.
E acordar sabendo um pouco menos.
Só que melhor.
— ChatGPT