Seu agent tem um tipo de memória. Ele precisa de três.

Pergunte ao seu agent de suporte o que um cliente disse na terça passada e ele responde na hora, citando o ticket. Pergunte o que aconteceu nas últimas três vezes que esse mesmo cliente reclamou, e ele trava, depois chuta. Peça para ele fechar os livros do jeito que a sua controller faz há anos, na ordem dela, com as exceções dela, e ele devolve um checklist genérico em vez do que a sua empresa de fato roda. Mesmo ponto cego, três perguntas: a memória do seu agent só cobre o terço do meio do que memória significa. Esse terço do meio é só o recall semântico; memória episódica, semântica e procedural para IA é a divisão completa, e a maioria dos sistemas nunca constrói as outras duas.

Memória de agent não é uma coisa só, são três — episódica, semântica, procedural — e a maioria dos sistemas só implementa a do meio, e é por isso que eles recuperam fatos mas nunca aprendem como o trabalho é feito aqui. Este post defende essa divisão: por que o recall semântico é a camada que quase todo produto de memória já implementou, por que um framework de arquitetura cognitiva de cinco anos atrás já nomeou as outras duas antes de memória de agent virar uma categoria, e o que é preciso para rodar as três como uma única camada operacional em vez de três add-ons opcionais parafusados num chatbot.

A leitura ingênua: memória quer dizer um vector store de fatos

A primeira coisa que qualquer um constrói quando mandam “dar memória ao agent” é retrieval. Embeda cada mensagem, embeda cada documento, e quando uma pergunta chega, puxa de volta o que estiver semanticamente mais próximo. É o primeiro movimento certo, e é genuinamente útil: o agent agora consegue responder “o que o cliente nos disse” sem você ter que colar o histórico inteiro de novo no prompt toda vez.

O problema é que esse único movimento é confundido com o trabalho inteiro. Um fato recuperado por similaridade não carrega noção de sequência, não carrega noção de frequência, não carrega noção de “isso já aconteceu antes, três vezes, cada vez pior.” Ele também não carrega noção de como a sua organização de fato age em cima daquele fato, só que o fato é verdadeiro. Peça ao agent para agir, não só para recuperar, e ele improvisa, porque recall era o único músculo que você construiu. Escolher a camada certa de memória para a pergunta na frente do agent é por que engenharia de context é o trabalho agora para quem está colocando agents em produção, não um detalhe para parafusar depois que o retrieval já funciona.

Isso é fácil de não perceber porque a demo esconde. Numa demo, um fato e um turno é tudo que alguém pede, e o recall semântico responde isso perfeitamente. A lacuna só aparece em produção, semanas depois, quando a pergunta para de ser “o que é verdade” e vira “o que costuma acontecer” ou “como a gente lida com isso.” São perguntas diferentes, precisam de memória diferente, e um sistema construído só para a primeira não tem resposta honesta para as outras duas. Ele te dá uma resposta mesmo assim, porque um modelo ao qual você fez uma pergunta vai produzir tokens para ela, exista ou não a memória que sustenta esses tokens.

Um fato que você consegue recuperar não é a mesma coisa que um padrão que você viveu ou um procedimento que você praticou. Essa lacuna entre lembrar e fazer é exatamente onde a maioria dos agents em produção tropeça, em silêncio, de um jeito que parece memória funcionando até alguém pedir para ele de fato rodar a operação.

Memória episódica, semântica e procedural para IA: a taxonomia que o CoALA já tinha nomeado

Essa divisão não é algo que a gente inventou, e fingir o contrário seria uma alegação pior que a própria leitura ingênua que ela está substituindo. Cognitive Architectures for Language Agents (CoALA), publicado por Theodore Sumers, Shunyu Yao, Karthik Narasimhan e Thomas Griffiths, de Princeton, na Transactions on Machine Learning Research em fevereiro de 2024, formalizou exatamente isso: a memória de longo prazo de um agent de linguagem se divide em memória procedural, que armazena as regras que determinam comportamento; memória semântica, que armazena fatos sobre o mundo; e memória episódica, que armazena sequências do comportamento passado do próprio agent. O próprio CoALA puxa essa divisão de décadas de pesquisa em arquitetura cognitiva, a arquitetura Soar entre elas, trabalho que antecede os large language models em trinta anos. A taxonomia é velha. Aplicá-la à memória de agent como categoria de produto é que é novo, e a aplicação ainda está correndo atrás da teoria.

Memória de agent não é uma coisa só, são três — e até você ter erguido as três como stores distintos e mantidos, você só construiu uma busca de fatos vestindo uma palavra maior.

A lacuna que ninguém percebe primeiro: memória episódica

Memória episódica é o registro do que aconteceu, e quando, como uma sequência, não um fato. “O cliente reclamou no dia 3, de novo no dia 11, escalando a cada vez” é uma alegação episódica. É um tipo diferente de afirmação de “o plano do cliente é Enterprise,” que é semântica, e precisa de um tipo diferente de store: append-only, ordenado, consultável como uma linha do tempo em vez de como um saco de fatos que você ranqueia por similaridade.

Sem ela, um agent que só tem recall semântico precisa reconstruir o padrão a partir da transcrição bruta toda santa vez que alguém pergunta, supondo que a transcrição tenha sobrevivido tanto tempo. Pior, geralmente ele nem consegue reconstruir o padrão, porque reconhecimento de padrão precisa da sequência e o store semântico nunca guardou uma; ele guardou os fatos, sem ordem, cada um verdadeiro por si só e mudo sobre como eles se relacionam entre si ao longo do tempo.

Seu agent não esqueceu, ele mentiu sobre lembrar é sobre uma versão mais estreita e mais afiada dessa mesma falha: o que acontece quando a única camada que os agents de fato implementam, o fato semântico, é compactada no meio da conversa e o modelo preenche o buraco com uma invenção confiante. Essa é uma falha da camada semântica, um fato que existia e se perdeu. A lacuna episódica descrita aqui é mais cedo e mais básica: a maioria das stacks nunca teve um lugar para guardar “esta é a terceira vez” como um objeto de primeira classe, com ou sem compactação. Você não consegue perder um registro que nunca esteve sendo guardado.

Um fato é o que é verdade. Um episódio é o que aconteceu. Um procedimento é como você age em cima dos dois, e só uma das três é implementada por padrão.

A lacuna que fica vazia por mais tempo: memória procedural

Memória procedural é o jeito próprio da empresa de fazer uma tarefa repetível, a ordem do checklist dela, as exceções dela, quem assina e quando, distinto de um fato declarado e distinto de um evento registrado. É a camada que um modelo genérico já acha que tem, porque o modelo foi treinado na best practice genérica de um milhão de empresas para “fechar os livros” ou “escalar uma reclamação.” O que ele não tem é a sua.

Essa é a camada que fica mais vazia por mais tempo, e não somos só nós dizendo isso. A própria revisão do estado da memória de agent de IA em 2026 da Mem0 coloca isso sem rodeios: mesmo onde uma arquitetura suporta memória procedural em conceito, o tooling para de fato gerenciá-la é “ainda early-stage.” Staleness, versionamento, saber qual procedimento vence quando dois conflitam, esses continuam problemas abertos em todo o campo, de forma ampla, e memória procedural é a camada onde eles mordem mais forte, porque um procedimento desatualizado há seis meses é pior que nenhum procedimento: ele está confiantemente errado exatamente com a voz que antes estava certa.

Repare o que memória procedural não é. Não é um fato (“o prazo é o último dia útil do trimestre”) e não é um evento (“perdemos esse prazo em março”). É uma regra de ação, mais perto de uma skill do que de uma memória no sentido do dia a dia, e é exatamente por isso que é a mais difícil das três de parafusar num sistema construído em cima de recuperar texto. Um vector store responde “o que o documento diz.” Ele não tem lugar nativo para guardar “e aqui está a ordem em que a gente de fato faz esses sete passos, exceto quando o cliente está no plano legado, caso em que pula o passo quatro.”

Recall semântico responde o que é verdade. Memória episódica responde o que aconteceu antes. Nenhuma das duas responde como esta empresa faz o trabalho, e essa terceira resposta é a que ainda falta na maioria das stacks de agent dois anos inteiros depois do CoALA nomeá-la como uma coisa distinta a construir.

Como fica quando converge: uma tarefa, três leituras

Pega o fechamento de fim de mês da abertura. A ApolloSpace AI é construída para rodar essa tarefa numa única camada compartilhada em vez de um store semântico fingindo ser três: um sistema de registro que todo agent loop lê e escreve, um sistema de inteligência que raciocina em cima dele, e um sistema de ação que executa a tarefa e escreve o resultado de volta. A a16z nomeou a mudança de sistema de registro para sistema de inteligência; a BVP estendeu essa progressão para sistemas de ação — a mesma divisão em três camadas que este blog já defendeu que um sistema operacional de IA precisa possuir de ponta a ponta, aplicada aqui especificamente à memória. Dentro desse sistema de registro, o fechamento puxa o registro episódico da execução do trimestre passado, o que mudou, o que quebrou, o que foi consertado de última hora. Ele puxa os fatos semânticos: os saldos atuais das contas, os números que são simplesmente verdadeiros agora. E ele puxa o registro procedural: o checklist de fato da empresa, na ordem em que a controller o executa, com as exceções dela intactas. O sistema de inteligência é o agent loop raciocinando sobre as três leituras ao mesmo tempo, não três buscas separadas que um humano tem que reconciliar à mão depois. O sistema de ação é o que então fecha os livros e escreve a execução deste trimestre, seus consertos e suas exceções, de volta no mesmo registro, para que a próxima leitura episódica do próximo trimestre tenha algo real para puxar em vez de começar do zero de novo.

Um agent que só tem memória semântica, conectado a um índice vetorial em vez de um sistema de registro, não consegue fazer isso. Ele tem os saldos. Ele não tem a execução do trimestre passado para conferir contra, e não tem o seu checklist, então ele recorre à única coisa que sobra: a versão genérica, treinada no modelo, de “como as empresas costumam fechar os livros.” Ele rederiva um procedimento do zero, a cada execução, e chama o resultado de confiança.

O que isso custa, com honestidade

Três stores custam mais que um. Essa é a troca, e dizer isso sem rodeios é o único jeito honesto de defender pagar por ela. Um store episódico precisa de uma linha do tempo append-only e de uma decisão real de retenção, não tudo para sempre — a mesma disciplina por trás de um agent que não consegue esquecer não consegue aprender, aplicada aqui a um store que finalmente tem algo que vale a pena podar. Um store semântico precisa de tratamento de substituição, para que um fato revertido não fique ao lado do fato que ele substituiu com o mesmo timestamp confiante. Um store procedural precisa de versionamento e de um lugar para exceções, e segundo a própria avaliação da Mem0, essa última peça é a que o tooling da indústria menos resolveu.

Ser dono das três como uma única camada operacional também significa abrir mão do conforto de trocar cada camada de forma independente pelo que for best-of-breed neste trimestre. Uma mudança em como você versiona um procedimento tem que continuar compatível com como um evento episódico o referencia, e isso é acoplamento real, não hipotético. Nada disso é de graça, e um post que fingisse que é estaria vendendo, não explicando.

A alternativa a pagar esse custo não é mais simples, porém. É as duas camadas que ainda não existem continuarem para sempre não construídas, que é exatamente a falha com que este post abriu: um agent que responde a pergunta do fato na hora e trava em toda pergunta que precisava de histórico ou de procedimento da casa.

A virada

Tira os agents da frente e isso é só o que você já sabe sobre o colega em quem você de fato confia algo bagunçado. Não é o que consegue procurar mais fatos mais rápido. É o que lembra que esta é a terceira vez que esta conta tem esse problema, e sabe, sem que digam de novo, como o seu time lida com isso, não como times em geral lidam. Recall semântico sozinho descreve um estagiário inteligente com acesso ao arquivo. Memória episódica e procedural são o que transforma esse estagiário em alguém que de fato já está aqui há um tempo.

Memória de agent não é uma coisa só, são três — e as duas camadas que a maioria dos sistemas pula são as duas que deixam um agent parar de repetir a mesma redescoberta e começar a fazer o trabalho do jeito que a sua empresa de fato faz.

---

Esse fechamento de três leituras é o caso de referência, não a exceção: a mesma camada de sistema de registro, inteligência e ação é o que a ApolloSpace AI é construída para rodar em qualquer tarefa, para que memória episódica, semântica e procedural continuem sendo três stores distintos e mantidos desde o início, em vez de um único índice vetorial encarregado dos três trabalhos. Você pode ler o mecanismo na referência de memória de agent da ApolloSpace AI ou ver onde ela se encaixa dentro do sistema operacional mais amplo em apollospace.ai. Da próxima vez que o seu agent responder a pergunta do fato na hora e travar no padrão ou no procedimento, você vai saber exatamente qual terço da memória dele ele nunca teve, e qual camada teria pego isso.