Memória de agente de IA: 4 tipos e quando usar cada um

Memória de agente de IA é a arquitetura que decide o que o agente sabe a cada momento, e ela se divide em quatro tipos: memória de trabalho, episódica, semântica e procedural. A maioria dos projetos precisa só da primeira no começo e adiciona as outras conforme o uso real mostra o que falta. Neste artigo eu explico cada tipo, quando usar e como isso aparece no dia a dia com o Claude Code.

Você monta um agente de IA, testa em sessão única e parece perfeito. Aí ele entra em produção e começa a esquecer contexto, repetir pergunta que o usuário já respondeu ou, pior, misturar informação de conversas diferentes. O agente estava tecnicamente funcionando, o problema era de memória. Memória em agente não é detalhe de implementação, é a diferença entre um assistente que parece útil e um que frustra na terceira mensagem.

Já passei por isso mais vezes do que gostaria de admitir. Agente em demo ao vivo perdendo o fio da meada por falta de estrutura, fluxo que funcionou em teste mas quebrou com usuário real porque ninguém pensou em persistência. Esse artigo é o que eu queria ter lido antes dessas situações, com os quatro tipos de memória, quando cada um faz sentido e quando adicionar mais complexidade só piora o problema.

O que é memória em agentes de IA e por que isso importa agora?

Quando se fala de memória em agente de IA, não estamos falando de um arquivo de texto guardando informação. Estamos falando da arquitetura que decide o que o agente sabe a cada momento. Isso inclui o que está disponível agora na janela de contexto, o que pode ser buscado de interações anteriores, o que foi aprendido sobre o domínio e quais regras guiam o comportamento. Cada uma dessas perguntas é um tipo de memória diferente, com custo e forma de recuperação próprios.

Um agente sem memória bem estruturada é como contratar alguém que esquece tudo entre cada reunião. Pode ser brilhante em cada interação isolada, só que na sequência é inútil. A boa notícia é que a maioria dos casos de uso não precisa dos quatro tipos ao mesmo tempo. O erro mais comum que eu vejo é exagerar desde o início, montando pipeline de memória para um agente que ainda não tem usuário.

Quais são os quatro tipos de memória em agentes de IA?

Memória de trabalho (working memory)

É o que o agente tem disponível agora, tudo que está dentro da janela de contexto ativa. Entram aí as mensagens da conversa atual, as instruções do sistema e os resultados de ferramentas chamadas no fluxo. Essa memória some quando a sessão termina, não há persistência nenhuma. O problema é que ela tem limite. Quanto maior a conversa, mais tokens consumidos e mais custo, e em algum ponto a informação anterior começa a ser descartada. É daí que vem aquele comportamento estranho do agente esquecer o que foi dito 20 mensagens atrás.

Memória episódica

Registra o histórico de interações. Quando uma conversa termina, as mensagens são salvas em algum armazenamento externo, e na próxima sessão o agente pode buscar conversas anteriores e retomar o contexto. Essa é a memória que faz um assistente parecer que lembra de você. Funciona bem quando o caso de uso envolve continuidade entre sessões: suporte técnico, acompanhamento de projeto, qualquer fluxo onde o usuário retorna. O risco é recuperar contexto irrelevante, porque busca imprecisa carrega conversa antiga que não ajuda e ainda ocupa espaço no contexto ativo.

Memória semântica

É o conhecimento sobre o domínio: documentos, FAQs, base de conhecimento, registros técnicos. O agente não guarda isso na janela de contexto o tempo todo, busca quando precisa, geralmente por similaridade, e é a memória que está por trás de qualquer implementação de RAG. O agente sabe que existe uma base de conhecimento e sabe como consultar. Onde errar: colocar muita coisa sem qualidade, porque documento ruim recuperado pelo agente gera resposta ruim, lixo entra e lixo sai.

Memória procedural

São as instruções de como o agente deve se comportar: regras de negócio, quais ferramentas usar em cada situação, limites de atuação. Fica no system prompt ou em regras que guiam as decisões ao longo do fluxo, e tecnicamente é o que menos muda. Só que quando muda, por alteração de política ou de escopo, precisa ser atualizada de forma consistente. Um agente seguindo instrução desatualizada é tão problemático quanto um sem memória nenhuma, com o agravante de errar com confiança.

Como esses quatro tipos aparecem no Claude Code?

O jeito mais fácil de entender os quatro tipos é olhar uma ferramenta que você já usa. No Claude Code, que eu uso todo dia, cada tipo tem um lugar concreto. A janela de contexto da sessão é a memória de trabalho e o CLAUDE.md é a memória procedural. A memória automática, que o próprio agente escreve a partir das correções que você dá, cobre a episódica e parte da semântica. Os números abaixo vêm da documentação oficial, e eles explicam por que instrução longa demais deixa de ser seguida.

O que essa tabela me ensinou na prática é que memória procedural tem teto, e o teto não é técnico, é de adesão. A própria documentação diz que arquivo maior consome mais contexto e reduz o quanto o agente segue a instrução. É por isso que no meu workspace o CLAUDE.md da raiz é curto e aponta para arquivos por setor. É assim que eu monto o fluxo de trabalho com Claude Code que descrevo no hub, com a regra de que instrução que não cabe em 200 linhas vira arquivo separado.

Quando cada tipo de memória faz sentido e quando é exagero?

Para a maioria dos casos simples, memória de trabalho resolve sozinha: uma sessão de chat, um fluxo de automação que roda e termina, uma tarefa de análise pontual. Se o usuário começa do zero em cada interação e não precisa de histórico, adicionar persistência é custo sem benefício real. Eu já vi projeto atrasar um mês montando banco vetorial para um agente que respondia pergunta única.

Memória episódica entra quando a continuidade entre sessões importa. Assistente de suporte onde o usuário retorna, acompanhamento de tarefa que dura dias, qualquer fluxo onde o agente precisa saber o que aconteceu antes sem o usuário repetir tudo. Memória semântica entra quando o agente precisa responder sobre um domínio que não está no treinamento do modelo. Documentação interna, base proprietária ou dado recente que o modelo nunca viu são os casos típicos, e aí vale o investimento em busca semântica.

Pra mim a regra é simples. Se o agente está errando porque não tem acesso a uma informação que existe em algum documento, o problema é de memória semântica. Se está errando porque esquece o contexto da conversa, é memória de trabalho ou episódica. Diagnosticar direito antes de escolher a solução economiza muito tempo, porque cada tipo tem uma correção diferente e nenhuma delas é "coloca tudo no prompt".

Qual é a diferença entre memória de agente e um banco de dados comum?

Um banco de dados guarda dados, e um sistema de memória de agente guarda dados de um jeito que o agente consegue recuperar de forma relevante para o contexto atual. A diferença está na recuperação. Em banco relacional você faz uma query precisa, em memória de agente você faz uma busca por similaridade ou relevância. O agente não sabe exatamente o que precisa buscar, então o sistema precisa devolver o que é relevante a partir de uma pergunta em linguagem natural.

Isso não substitui banco de dados tradicional, são camadas complementares que resolvem problemas diferentes. Na prática o agente que eu coloco em produção tem os dois. O banco relacional guarda o dado de negócio com integridade, e a camada de memória guarda o que o agente precisa lembrar entre conversas. O cuidado é nunca deixar a segunda virar fonte de verdade da primeira, porque memória de agente pode ser imprecisa por desenho.

O que esperar de um agente bem estruturado em memória?

Quatro comportamentos separam um agente com memória bem feita de um que só parece funcionar. Continuidade: retoma onde parou sem pedir que o usuário repita informação. Relevância: busca contexto quando precisa, não o tempo todo. Custo previsível: não explode a janela de contexto com o histórico inteiro em cada mensagem. Degradação graciosa: quando a memória não tem o que precisa, admite e pergunta em vez de inventar.

Esse último ponto é o que mais falta nas implementações que eu vejo. Agente que alucina quando não encontra contexto é pior do que agente que simplesmente diz que não tem a informação. Alucinação com confiança é o pior tipo de falha, porque o usuário acredita, age em cima e só descobre o erro depois. Tem uma relação direta entre memória e os guardrails do agente: memória mal estruturada torna as regras mais difíceis de aplicar, porque o agente não tem o contexto certo para segui-las.

Qual é o impacto de não pensar em memória desde o início?

Refatorar memória em produção é um dos trabalhos mais chatos que eu já fiz. Você precisa decidir o que migrar, como indexar o histórico existente, como garantir que o agente não confunda memória antiga com nova e ainda manter o sistema funcionando durante a transição. Começar sem pensar em memória é uma dívida técnica que cobra juros rápido, e o problema aparece justamente quando o agente está sendo usado de verdade, não em teste.

Na minha visão, antes de colocar qualquer agente em produção, a pergunta de memória precisa estar respondida: qual tipo, onde armazenar, como recuperar, o que descartar. Isso não é burocracia, é o que separa um projeto que escala de um que quebra em três semanas, e a resposta cabe numa página de decisão que leva uma tarde para escrever e evita um mês de refatoração depois.

Quais são as dúvidas mais comuns sobre memória em agentes de IA?

O agente de IA tem memória por padrão?

Não. Por padrão, LLMs são stateless, cada chamada é independente, e memória é algo que você adiciona na arquitetura ao redor do modelo, não algo que o modelo fornece sozinho. Isso surpreende muita gente que começa a trabalhar com agentes. A interface de chat esconde essa mecânica ao reenviar o histórico inteiro a cada mensagem, e é exatamente isso que faz o custo crescer com o tamanho da conversa.

Qual é a diferença entre memória e RAG?

RAG é uma implementação de memória semântica, não são sinônimos. RAG é a técnica de buscar documentos relevantes e colocar no contexto antes de gerar a resposta, e memória é o conceito mais amplo que inclui os quatro tipos descritos acima. Todo RAG usa memória semântica, nem toda memória semântica é RAG, e o artigo sobre RAG na prática mostra como conectar um LLM aos seus próprios dados sem exagerar na infraestrutura.

Preciso de banco vetorial para ter memória?

Depende do tipo. Para memória de trabalho, não. Para episódica simples, um banco relacional comum resolve, com uma tabela de sessões e mensagens. Para semântica com busca por similaridade, faz sentido usar banco vetorial ou extensão vetorial em banco existente, como o pgvector no Postgres. Não é uma decisão binária, e entender quando embeddings e busca semântica fazem sentido ajuda a tomar essa decisão com mais segurança antes de contratar mais um serviço.

Como saber se o agente está lembrando do jeito certo?

Teste com conversas longas, sessões que retomam depois de dias e perguntas sobre contexto que só existia em interação anterior. Se o agente lembra o que deve e esquece o que deve, a estrutura está certa, e se lembra coisas erradas ou mistura contextos, o problema é de recuperação, não de armazenamento. A documentação oficial de memória do Claude Code é uma boa referência de como um agente de produção separa instrução fixa de aprendizado acumulado.

Por onde continuar?

Memória em agentes de IA não é funcionalidade avançada reservada para caso complexo, é decisão de arquitetura que impacta todo agente que vai além de uma única sessão. Os quatro tipos, de trabalho, episódica, semântica e procedural, cobrem a maioria dos cenários reais. A maioria dos projetos começa com memória de trabalho e adiciona os outros conforme a necessidade aparece. Esse é o caminho certo, começar com tudo é a receita para over-engineering sem ganho proporcional.

Se você quer continuar no tema, vale entender como o MCP conecta ferramentas externas ao agente sem sobrecarregar a memória. Dado que pode ser buscado sob demanda não precisa morar no contexto, e a janela de contexto define o que cabe na memória de trabalho. E se quer ver isso aplicado num fluxo real de código, o hub de Claude Code mostra como eu organizo instrução, memória e skills no dia a dia.