Memória em agentes: episódica, semântica e procedural

Quando você constrói um assistente conversacional para e-commerce ou catálogo de produtos, a pergunta sobre persistência é técnica: latência, custo, TTL.

Quando você faz o mesmo para um banco ou gestora de investimentos, a pergunta muda de natureza. Ela passa a ser ao mesmo tempo técnica, arquitetural e regulatória, e a resposta errada aparece não num benchmark, mas numa auditoria.

No início tratava tudo como uma coisa só, mas não é. Com a experiência prática aprendi que um assistente financeiro em produção precisa de pelo menos cinco camadas distintas, cada uma com propósito, tecnologia e ciclo de vida diferentes. E antes de falar em camadas, é preciso entender a taxonomia.

A taxonomia

A psicologia cognitiva distingue três tipos de memória humana. Quando comecei a mapear o que o assistente precisava "lembrar", percebi que a mesma classificação se aplica, e que confundir os três tipos é onde os projetos bancários com LLM erram estruturalmente.

Mapeando para a infraestrutura real, cada tipo tem sua camada, seu ciclo de vida e, no setor bancário, seu impacto regulatório:

Memória Episódica: o diário de cada conversa

É a memória de eventos sequenciais: o que aconteceu, em que ordem, com que resultado. Para o assistente, é o histórico de mensagens, as tool calls executadas, os checkpoints de estado do grafo.

Uso o Redis Checkpointer do LangGraph como backend de curto prazo:

A escolha do Redis aqui não é aleatória. Para memória episódica de curto prazo, o que importa é velocidade de leitura e escrita, pois o grafo consulta o estado a cada nó. Redis em memória entrega latência sub-milissegundo, sem o overhead de I/O de disco do PostgreSQL.

O que essa memória guarda na prática:

Ciclo de vida: expurgo após 30-60 dias. Só sessões ativas precisam estar aqui. O que foi encerrado migra para as outras camadas via evento Kafka.

A analogia é o que você lembra do que fez hoje. Detalhado, sequencial, mas não fica na cabeça para sempre.

Memória Semântica: o que o agente sabe sobre o cliente

É a memória de fatos e relacionamentos: quem é esse cliente, o que ele já demonstrou preferir, qual o perfil de risco anterior vs atual, quais produtos já consultou. Não é o evento em si, é o conhecimento destilado dos eventos.

A diferença crítica para o domínio de investimentos: a memória semântica carrega o suitability. O agente não começa uma sessão sobre fundos do zero, ele já sabe que esse cliente tem perfil Moderado (a consulta é feita on-time também para saber se o perfil mudou), que já consultou FIDC antes, e que a última vez que viu uma rentabilidade acima de 15% a.a. demonstrou interesse mas não aplicou.

Isso não é só UX. É conformidade: a Resolução CVM 30 exige que a adequação ao perfil seja verificada antes de qualquer apresentação de produto (e caso o cliente não queira fazer a análise do perfil, também é permitido que seja tratado como perfil "Conservador"). Se a memória semântica está populada corretamente, o agente não precisa perguntar o perfil de risco a cada sessão, a tool de prateleira filtra com base nisso antes de gerar qualquer resposta.

A analogia é o que você sabe sobre um amigo de anos (não o que falaram ontem, mas quem ele é).

Memória Procedural: como o agente age

É a memória de habilidades e regras: não o que aconteceu nem o que o agente sabe, mas como ele deve se comportar. Para um assistente de investimentos, isso inclui os prompts otimizados pelo DSPy, os patterns de validação regulatória, os critérios de roteamento compilados.

A memória procedural é a única das três que não muda durante a execução. Ela é carregada na inicialização e fica estável durante o ciclo de vida do processo. Quando o DSPy é recompilado com novos exemplos ou quando uma resolução da CVM muda um pattern de validação, você atualiza a memória procedural via deploy, não via runtime.

A analogia é como andar de bicicleta. Você não pensa, o corpo já sabe. O agente não delibera sobre cada regra de compliance, o critique_node simplesmente executa.

Como os três tipos se conectam na prática

Sem memória semântica, o agente começa do zero toda sessão.

Sem memória procedural atualizada, o critique_node usa regras desatualizadas.

Sem memória episódica, o agente não consegue resolver anáforas. Perguntas como "esse produto" não tem referência.

As duas camadas que servem ao regulador, não ao agente

As três memórias acima servem ao agente em tempo de execução. As duas camadas a seguir existem para outra finalidade, e são igualmente obrigatórias.

Analytics responde perguntas que nenhuma memória operacional resolve bem: "Quais clientes fizeram mais de 3 resgates acima de R$ 50.000 nos últimos 45 dias?", "Todos os casos onde o guardrail bloqueou uma resposta por Violação CVM 30 no último trimestre."

O arquivo legal é o cofre. Uma vez gravado, ninguém modifica. Nem o DBA sênior. Nem o usuário root da conta AWS (se você configurar em Compliance Mode no S3 Object Lock, não em Governance Mode). A diferença importa: no Governance Mode um admin pode sobrescrever com permissão especial. No Compliance Mode o prazo de retenção é inviolável. É a única configuração que satisfaz uma auditoria do Banco Central.

A tabela de execucao_ferramentas_subagentes no analytics é especialmente crítica: o campo parametros_payload guarda os argumentos exatos que o LLM injetou na tool call. Quando o cliente reclama que "o assistente aplicou R$ 10.000 mas eu disse R$ 1.000", esse campo é a prova irrefutável de que o modelo não alucionou (ou de que alucionou, e você precisa saber disso antes do regulador).

Sempre pense no pior cenário

Guardar bem é necessário. Mas não é suficiente.

Mesmo com as cinco camadas no lugar certo, o sistema ainda tem um problema não resolvido: o LLM pode gerar uma resposta que viola a CVM ou o Código ANBIMA antes de qualquer coisa ser gravada. O arquivo legal guarda a evidência do que foi entregue ao cliente, mas se o que foi entregue já era uma violação, guardar não ajuda.

É por isso que existe o critique_node: o compliance officer do grafo. E é sobre ele que falo na semana que vem: as quatro violações regulatórias que o LLM comete naturalmente, como o Circuit Breaker protege quando o guardrail semântico falha, e o paradoxo entre o direito ao esquecimento da LGPD e a obrigação de guarda do Banco Central.