Do contexto à memória: seus agentes precisam de uma camada de memória real — Anders Swanson, Oracle

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: From Context to Memory: Your Agents Need a Real Memory Layer — Anders Swanson, Oracle · Canal: AI Engineer · 17:33 · Assistir no YouTube

Tópicos: Agentes de IA, Dados, bancos de dados e embeddings, Privacidade e proteção de dados, RAG, busca e recuperação de informação

Resumo

Anders Swanson apresenta a memória de agentes como um problema de sistemas: context window não é memória persistente, e arquivos de apoio não oferecem recuperação governada em escala. Uma camada de memória deve formar, armazenar, recuperar, consolidar e avaliar memórias, com controles de escopo, privacidade e temporalidade. A recuperação híbrida pode combinar busca vetorial, textual, relacional, por grafo e sinais de feedback para montar contexto relevante. Com feedback e governança, os agentes podem reutilizar experiências anteriores, reduzir trabalho repetido e evitar falhas recorrentes.

Pontos-chave

A context window serve como entrada para uma execução, mas não preserva experiências entre sessões.
Uma camada de memória deve transformar experiências úteis em memórias estruturadas, não apenas guardar transcrições brutas.
A recuperação híbrida combina diferentes métodos de busca e sinais para montar cartões de contexto com evidências classificadas.
Memórias podem ser episódicas, semânticas, procedurais ou estados de trabalho de curto prazo.
A formação de memória deve incluir redação de dados sensíveis, enriquecimento, definição de escopo e proveniência.
Governança e verificações de escopo são essenciais para evitar vazamentos, memórias envenenadas e dados irrelevantes.
A consolidação e a resolução de conflitos ajudam a lidar com memórias duplicadas, obsoletas ou contraditórias.
Feedback sobre utilidade, irrelevância, dano e obsolescência deve orientar a classificação e o ciclo de vida das memórias.
Uma plataforma de banco de dados multimodelo pode reunir dados relacionais, vetoriais, textuais, temporais e em grafo.
Memória governada permite que agentes retomem trabalhos anteriores, economizem tokens e reduzam falhas repetidas.

Capítulos

Início	Capítulo	Resumo
00:01	Por que agentes precisam de memória persistente	Swanson explica que context window e arquivos de apoio não substituem uma camada persistente e governada de memória.
04:50	O ciclo e os tipos de memória	A palestra descreve como registrar fatos para sessões futuras e apresenta memórias episódicas, semânticas, procedurais e estados de trabalho.
09:07	Formação e recuperação híbrida	Swanson detalha a criação de memórias com escopo e proveniência e a combinação de diferentes métodos de busca para reconstruir contexto.
12:17	Evolução, riscos e feedback	O palestrante aborda memórias obsoletas, conflitos, vazamentos e envenenamento, defendendo controles e feedback contínuo.
15:25	Benefícios da memória governada	A conclusão relaciona a memória mensurável à redução de trabalho repetido e apresenta recursos da Oracle para começar a experimentar.

Citações

Context windows não são memória. — 00:32

Se continuarmos tentando construir uma camada de memória sobre arquivos, vamos acabar construindo nosso próprio banco de dados. — 02:41

A recuperação híbrida está surgindo como o método dominante para reconstruir contexto. — 10:09

A qualidade da memória precisa ser mensurável. — 15:25

Conceitos e entidades

Anders Swanson (pessoa): Apresentador da palestra e developer advocate de Oracle AI database.
Oracle (empresa): Empresa associada ao trabalho de Anders Swanson e às ferramentas de banco de dados mencionadas na palestra.
agent memory (conceito): Camada persistente que forma, armazena, recupera, governa e avalia memórias úteis para agentes.
hybrid retrieval (conceito): Recuperação que combina métodos como busca vetorial, textual, relacional e em grafo, além de sinais temporais e feedback.
episodic memory (conceito): Memória de eventos passados ou trechos de transcrições associados ao trabalho do agente.
semantic memory (conceito): Memória de fatos sobre workflows, preferências de usuários e outras entidades.
procedural memory (conceito): Memória de procedimentos e regras reutilizáveis para realizar tarefas recorrentes.
working state (conceito): Estado de curto prazo sobre o que o agente está fazendo, potencialmente válido apenas por um período limitado.
multi-model database (conceito): Banco de dados que reúne diferentes formas de armazenamento e busca, como dados relacionais, vetores, texto e grafos.
Python SDK for agent memory (ferramenta): SDK mencionado por Swanson, acompanhado de um notebook Python para explorar a implementação de memória para agentes.
MCP (conceito): Um dos meios citados para que o runtime do agente invoque a camada de memória.

Tradução completa (pt-BR)

00:01 [música] >> Oi, sou Anders. Sou defensor de desenvolvedores do Oracle AI database e vou falar sobre como podemos abordar a memória de agents como um problema de sistemas, sobre como podemos pegar contexto e transformá-lo em uma verdadeira camada de memória que ajude seus agents a trabalhar melhor. Quando falamos de memória de agent

00:32 estamos falando de combinar recuperação de memória, formação de memória e o armazenamento persistente que dá suporte a essas memórias. Provavelmente todos já usamos diferentes agents a esta altura, como Claude Code ou Codex, e já os vimos trabalhar em uma tarefa e reler os mesmos arquivos várias vezes. Isso acontece porque eles não têm conhecimento do que ocorreu no passado. context windows não são memória. Elas são a entrada da execução atual, não uma experiência persistente. Se eu

01:04 tiver uma sessão de agent, digamos que ele esteja trabalhando em chamados de suporte ao cliente, leia vários documentos, execute várias consultas, reproduza uma falha, encontre a causa raiz e faça todo esse trabalho valioso que sintetiza um procedimento útil. O que acontece no fim da sessão? Tudo é descartado. E isso acontece porque não há persistência. Muito tempo depois, outro agent aparece, trabalha em uma tarefa parecida e precisa repetir todo o mesmo trabalho. Então, ele pesquisa mais documentos, executa mais

01:37 consultas, e isso aumenta as oportunidades de falha e de alucinações e, no fim das contas, reduz a fidelidade. A memória realmente só pode começar quando essas experiências úteis dos nossos agents são transformadas em estado gerenciado. context windows maiores também não são a solução. Acabamos usando cada vez mais tokens. A sessão fica mais longa, ocorre compactação. O sinal útil para nossos agents se perde em meio a uma enxurrada de outras informações irrelevantes.

02:07 Da mesma forma, blocos de notas são soluções improvisadas. Por exemplo, arquivos markdown: começamos a criar grandes hierarquias de arquivos, wikis, prompts. Isso ajuda, mas não é recuperação governada. Arquivos não escalam em ambientes grandes com vários tenants. Ferramentas como grep são extremamente úteis para encontrar dados, mas também não escalam bem, e isso não é recuperação híbrida complexa. E acho que, se levarmos até a conclusão lógica a tentativa de criar uma camada de memória sobre arquivos, acabaremos criando nosso próprio banco de dados.

02:41 E, em vez disso, poderíamos simplesmente usar um banco de dados. Nesta apresentação, vou detalhar as lições que aprendemos como fornecedor de banco de dados ao trabalhar com clientes que estão desenvolvendo memória para agents, clientes que estão resolvendo problemas reais com agents e precisam recuperar informações. E o padrão para o qual vemos os sistemas modernos de memória para agents convergirem implementa formação, recuperação, evolução e avaliação da memória.

03:12 Ao formar memórias, criamos experiências destiladas, fatos estruturados. Não despejamos transcrições brutas. Para recuperar memórias, a recuperação híbrida está surgindo como método dominante. É uma forma de recuperação que combina diferentes tipos de busca: busca por similaridade vetorial, busca lexical, busca de entidades em objetos relacionais, travessias de grafos e diferentes sinais em dados temporais, como recência e feedback. Também precisamos de consolidação nesses

03:45 sistemas. Podem surgir duplicatas. Precisamos resolver conflitos. O sistema precisa evoluir com o tempo. Caso contrário, fica desatualizado, irrelevante e inútil. As memórias precisam ter um componente temporal. Quando foram criadas? Quando foram acessadas? Por quanto tempo são válidas? Talvez só sejam válidas durante um determinado intervalo. E tudo isso precisa ser acompanhado de feedback e avaliação regulares. Se não estou medindo o uso nem enviando feedback para a camada de memória, tudo vai desmoronar. Outro

04:18 componente importante são os controles de governança. Segredos e informações pessoais precisam ser ocultados antes de chegarem à camada de memória. As permissões precisam ter escopo definido: para o agent, o workflow, a equipe e o usuário. Isso é especialmente importante em ambientes com vários tenants. Precisamos das aprovações administrativas adequadas, de revisão e da capacidade de suprimir dados desatualizados ou envenenados. Ao percorrermos o ciclo da memória, temos uma sessão de agent. Ela realiza algum trabalho, lê documentos, executa consultas e sintetiza dados úteis.

04:50 Depois dessa sessão, ou durante ela, um fato é criado. Registramos esse fato ocultando informações, enriquecendo-o e armazenando-o na camada de persistência. Então, quando surge outra sessão com contexto relacionado, ela pode recuperar esse fato e usá-lo para reconstruir um cartão de contexto. Assim, ela usa esse fato, obtido em uma tarefa anterior, para facilitar a tarefa seguinte. Isso reduz o trabalho do próximo agent. E, se esse agent usar o fato com sucesso, podemos adicionar pontuações de feedback a essa memória. Assim, nos adaptamos com o tempo. Obtemos dados relacionados e novos dados temporais. Nós

05:26 o acessamos novamente. Fizemos algo com ele. Agora, o agent runtime invoca a memória como uma função. Portanto, ela precisa de camadas de leitura, gravação e armazenamento. Seu agent runtime pode invocar a camada de memória por meio de hooks, MCP, skills ou outros métodos. E a API da camada de memória expõe as APIs de leitura, gravação, feedback e administração e, em seguida, se comunica com a plataforma de armazenamento ou com bancos de dados.

05:56 Quanto à escolha do banco de dados, acho que bancos de dados multimodelo são especialmente úteis porque permitem trabalhar com linhas, colunas, embeddings vetoriais, busca de texto completo, entidades relacionais, grafos, episódios e fatos, tudo em um só lugar. Assim, sua memória pode ficar consolidada em um único lugar, com uma conexão de consulta a um banco de dados. Posso fazer todos os tipos de busca híbrida e retornar esses dados. Como é a memória? Ela será tipada, e talvez vocês

06:28 já tenham visto esse modelo, ou alguma versão dele, em outras apresentações. Ele deriva, de maneira geral, da memória humana e pode ser aplicado a agents. Temos a memória episódica. São eventos específicos do passado ou trechos de transcrições com que os agents trabalharam. Temos a memória semântica. São fatos específicos sobre nossos workflows, preferências dos usuários e outras entidades. Temos a memória procedural. É como realizamos uma tarefa ou rotina específica, talvez uma etapa de build. São regras reutilizáveis que os agents vão querer consultar repetidamente quando estiverem realizando trabalhos semelhantes. E temos o estado de trabalho. O estado de trabalho

07:01 é como uma memória de curto prazo. É aquilo em que estamos trabalhando neste momento, e esses dados temporais talvez só sejam válidos durante um determinado intervalo; podemos promovê-los a outro tipo de memória. Isso nos ajuda a organizá-los em categorias distintas e podemos usar técnicas de busca diferentes para esses tipos de memória. Como é o esquema de armazenamento da memória? As memórias são objetos tipados mais um caminho de consulta. Nosso objeto de memória terá um ID, como uma chave primária. Terá seu conteúdo textual, tags JSON e dados do documento.

07:32 Terá um embedding vetorial. Criamos um vetor a partir do conteúdo, com um índice vetorial para busca por similaridade. Idealmente, também teremos um índice de texto para facilitar a busca por palavras-chave em texto completo. Isso se combina com a busca vetorial. Podemos ter links de grafo para diferentes arestas. As memórias podem estar relacionadas por meio de um grafo de entidades. Assim, esta memória se conecta a esta outra, que se conecta àquela. É um contexto adicional que podemos recuperar durante a etapa de busca. Também podemos ter fatos temporais. Até quando esta memória é válida? Quando foi a última vez que a usamos? E, muito importante, eventos de auditoria.

08:04 Quem criou esta memória? Para que a usaram? O registro de como ela foi usada e os metadados associados. Tudo isso deve fazer parte do seu esquema de armazenamento quando trabalhamos com memórias. Ao criar memórias, queremos formá-las intencionalmente. Boas memórias são intencionais. Portanto, precisamos decidir o ciclo de vida, o escopo, as diferentes relações e os metadados associados. Quando um agent runtime decide criar uma memória, devemos começar pela ocultação de informações.

08:36 Ocultar informações é muito importante como primeira etapa, porque, antes de gerar embeddings e antes de fazer o enriquecimento, quero remover as informações de identificação pessoal. Não quero que segredos ou informações estranhas e irrelevantes acabem na camada de memória. Isso é receita para o desastre. Portanto, primeiro ocultamos essas informações. Depois, podemos enriquecer a memória. A que a memória está relacionada? Quais são os metadados da memória? Podemos definir o escopo dela. Qual agent trabalhou nessa memória? Qual é a equipe? Qual é a organização? Isso ajuda a organizar em áreas específicas para que eu não receba

09:07 memórias de outras sessões associadas a outros agents ou workflows, o que gera confusão. Podemos fazer o embedding para criar o vetor do conteúdo. Depois, podemos formar o que chamamos de episódio. São os trechos da transcrição que deram origem à memória. Isso é bom para a proveniência e para fornecer contexto adicional. Também podem ser aplicadas aqui políticas específicas da organização, conforme necessário para o seu caso de uso. Depois, podemos salvar tudo na camada de armazenamento. Ao criar uma memória, cada memória individual pode ser bastante compacta. Então, pegamos a transcrição e a destilamos

09:38 até chegar a esse conteúdo, aos metadados, ao embedding e a outras coisas relacionadas, mas também criamos esses episódios. Pegamos as transcrições do agent, filtramos, encontramos candidatos a episódios, salvamos o registro da memória e fazemos o vínculo de volta. Você pode fazer isso com relações, simplesmente usando relacionamentos de banco de dados. Também pode fazer isso com grafos. Eu gosto particularmente de grafos porque eles permitem uma busca mais ampla. Quando falamos de recuperação de memória, estamos falando de como nos lembramos de algo. Isso é um

10:09 problema de recuperação, ou seja, um problema de consulta na camada de armazenamento. Na recuperação, ou lembrança, a busca híbrida está se consolidando como o método dominante para reconstruir o contexto. Esse tipo de recuperação pode combinar diferentes métodos de busca. Posso usar busca por similaridade vetorial, busca de texto completo por palavras-chave, entidades relacionais, travessia de grafos e outros sinais de feedback, como a importância e a utilidade da memória, para obter resultados mais abrangentes do que os de apenas uma

10:43 ramificação específica da consulta. Por exemplo, se eu fizesse apenas busca por similaridade, obteria somente os resultados mais semelhantes de acordo com o modelo de embedding que estou usando. Em geral, isso não tem sido suficiente. Temos todas essas ramificações de consulta diferentes e tipos diferentes de memória; você pode decidir quais quer usar. Para coisas como fatos, talvez você não queira usar similaridade; talvez queira apenas fazer uma correspondência exata de ID para um fato. Podemos pegar esses resultados, combiná-los, aplicar limiares e reordená-los; então, obtemos um cartão de contexto com evidências pontuadas. Assim, podemos dizer: esta

11:15 memória teve uma classificação muito boa na busca vetorial e um pouco mais baixa na busca lexical. Essa é a proveniência da memória: de onde veio e como a obtivemos. Isso também é importante. Ao percorrermos a busca híbrida, a distância vetorial é útil para coisas semanticamente semelhantes, como o operador de contém, que é muito bom para busca lexical; também temos tabela de grafos, dados temporais e todo o resto. Pegamos essas ramificações e aplicamos pesos a elas. Podemos atribuir pesos diferentes conforme necessário. Isso é algo que pode ser

11:47 ajustado no seu algoritmo de busca híbrida. Os resultados das diferentes ramificações de consulta são combinados em uma pontuação geral; depois, podemos pegar os K primeiros resultados gerais e dizer: “Aqui estão os três melhores resultados do nosso algoritmo de busca híbrida”. Essa é, em linhas gerais, uma forma de implementar busca híbrida em um banco de dados multimodal, um banco de dados capaz de fornecer todos esses métodos de busca diferentes em uma única interface. Memórias não são apenas um repositório no qual inserimos dados e do qual

12:17 extraímos dados. Para serem realmente úteis, as memórias precisam evoluir com o tempo. Também não queremos simplesmente despejar todos os nossos dados ali toda vez; caso contrário, teremos toneladas de memórias. É aqui que podemos fechar o ciclo da memória com consolidação e tratamento de erros. Memórias desatualizadas podem surgir quando, por exemplo, meu projeto usa NPM em determinado momento e depois decidimos mudar para outro sistema de build. O que acontece com todas as memórias relacionadas ao NPM? Se um agent as recuperar, isso pode ser um pouco complicado e ele pode acabar fazendo a coisa errada.

12:47 Portanto, o sistema precisa estar preparado para lidar com fatos desatualizados, recuperação excessiva e deriva silenciosa. O escopo inadequado pode ocorrer quando não delimitamos corretamente as memórias para o contexto certo. É como entrar na sua conta do ChatGPT e ver o histórico de mensagens de outra pessoa. Se você não aplicar o escopo corretamente, pode haver vazamentos de dados muito graves. Isso precisa acontecer tanto na gravação quanto na leitura. Memória envenenada ocorre quando uma fonte não confiável insere uma instrução duradoura na sua camada de memória.

13:18 Esse é mais ou menos o pior cenário: ocorre uma injeção de prompt, você não tem as proteções adequadas, nem a revisão, a redação ou os controles apropriados sobre a memória, e coisas realmente nocivas acabam entrando ali, exfiltrando todos os seus dados. Portanto, tome muito cuidado para evitar esse tipo de situação usando as proteções e ações administrativas adequadas. Um conflito de memória ocorre quando tenho duas memórias diferentes. Uma diz: “Olha, fazemos a tarefa deste jeito”. E a outra diz: “Na verdade, fazemos deste

13:49 jeito”. Como ambas dizem respeito à mesma tarefa, vão ficar muito bem classificadas na recuperação. Então, você provavelmente verá esses mesmos conflitos no cartão de contexto. Quando o agent consumir isso, será como se dissesse: “Bem, você me disse que o restaurante fica à direita, mas na verdade fica à esquerda. Não sei o que fazer”. Por isso, a detecção e a revisão são muito importantes para resolver conflitos. O escopo também. Às vezes, há maneiras diferentes de fazer a mesma tarefa. A recuperação excessiva e a irrelevância surgem conforme o sistema de memória cresce. Se nós

14:20 simplesmente despejarmos todos os nossos dados ali sem pensar muito no que estamos gravando, podemos acabar numa situação de recuperação excessiva, com tantos resultados pouco correspondentes que eles ocupam o cartão de contexto. É o mesmo problema de uma context window muito grande, quando tentamos enfiar o máximo possível de dados. Isso só causa confusão. Irrelevância é quando memórias semanticamente próximas ficam bem classificadas na busca híbrida, mas não têm relação de fato com a tarefa. Simplesmente receberam uma pontuação alta. Esses são problemas de gerenciamento e de ajuste do algoritmo de busca.

14:53 Vazamento de dados ocorre quando dados estranhos e inesperados entram no sistema de memória. Essa é uma versão menos grave da memória envenenada. O enriquecimento adequado e a destilação dos registros de memória, no caminho certo, são a forma de resolver o vazamento. Com o tempo, também temos a deriva silenciosa. É quando o sistema de memória cresce. Talvez funcione muito bem com cerca de mil registros. Mas, quando chega a 50 mil, a um milhão ou mais, começo a obter todos esses resultados estranhos, e o sistema não está funcionando direito. Por isso, é muito, muito importante aplicar as contramedidas adequadas:

15:25 a redução antes da gravação, as verificações de escopo, a revisão, o ciclo de vida e, acima de tudo, o feedback. O feedback é o que fecha o ciclo da memória. A qualidade da memória precisa ser mensurável. Precisamos ter uma recuperação correta. Precisamos levar em conta memórias desatualizadas ou prejudiciais e, em última análise, a utilidade do sistema nas etapas seguintes. O feedback precisa orientar as decisões de classificação e de ciclo de vida. Então, se um agent recuperar uma memória candidata, ele poderá usá-la ou rejeitá-la. Talvez, se a usar, tudo dê errado e o sistema falhe. Esse feedback precisa voltar.

15:57 E, se a memória tiver sido prejudicial, a pontuação deve cair. Se tiver sido útil, talvez possamos promovê-la. Portanto, não se trata apenas de um repositório. A sua camada de memória precisa armazenar se as memórias foram úteis, estavam desatualizadas, eram irrelevantes, prejudiciais etc. Queremos projetar para uma recuperação mensurável, com formação de memória governada e construída sobre uma plataforma de armazenamento multimodal. Sem memória, é mais provável que esses agents recomecem as mesmas tarefas. Eles vão recriá-las repetidamente. Vão

16:29 ler os mesmos arquivos. Vão executar as mesmas consultas. Vão desperdiçar toneladas de tempo e de tokens, serão muito mais lentos e muito mais propensos a falhas. Vão repetir os mesmos erros. Se não souberem do que já foi feito, farão a mesma coisa de novo. E, se aquilo estava errado, vão errar de novo, repetidas vezes. Com memória governada, os agents podem retomar de onde pararam. Podem reutilizar o que veio antes deles e, em última análise, reduzir as falhas repetidas. Esse é, esse é o verdadeiro objetivo de registrar, recuperar e governar,

16:59 evoluindo. Queremos melhorar a taxa de sucesso. Queremos fazer isso mais rápido. Queremos fazer isso com menor custo. Queremos fazer isso melhor. Se você gosta de pôr a mão na massa, recomendo conhecer nosso SDK de Python para memória de agent. Este código levará você a um link do GitHub com um notebook de Python que mostra como fazer isso usando nosso SDK. O SDK é construído com base em primitivas de banco de dados. Tudo de que falamos aqui fica no banco de dados. Também temos nosso hub para desenvolvedores. Se você é engenheiro de IA, está

17:33 desenvolvedor e tem curiosidade de saber como um banco de dados multimodelo moderno se encaixa no desenvolvimento de IA, este é o lugar para conhecer nossos exemplos, ver o que é possível e talvez até se inspirar para criar algo incrível com um banco de dados excelente. Mais uma vez, sou Anders, Anders Swanson. Se quiser conversar ou entrar em contato comigo, estarei no estande da Oracle. Muito obrigado. Espero que isso tenha sido útil para vocês e os ajude enquanto estão construindo coisas incríveis. Muito obrigado.

Transcrição original

[00:01] [music] >> Hey, so I’m Anders. I’m a developer advocate for Oracle AI database and I’m talking about how we can approach agent memory as a systems problem, how we can take context and turn it into a real memory layer that is going to help your agents work better. Um when we’re talking about agent

[00:32] memory, we’re talking about composing memory retrieval, memory formation, and the persistent storage that’s backing these memories. Um and we’ve probably all used different agents at this point, agents like Claude code or Codex, and we’ve seen them work on a task and reread the same files over and over again. And this this is because they have no knowledge of what has happened in the past. Context windows are are not memory. Um they’re the input for the current run and not a persistent experience. If I

[01:04] have some agent session, let’s say he’s working on customer support tickets, he reads a bunch of documents, he runs a bunch of queries, he reproduces a failure, finds root cause, and does all this like great valuable work that synthesizes a useful procedure. What happens at the end of the session? It’s tossed away. And this is because there’s no persistence. Uh you know, a long long later another another agent comes on and he works on a similar task and he has to repeat all of the same work. So he’s he’s searching more documents, he’s running more

[01:37] queries, and this is more opportunity for failure, more opportunity for hallucinations, and and ultimately uh less fidelity. And memory really cannot begin until these useful experiences from our agents are transformed into managed state. Uh larger context windows are also not the solution. We end up throwing more and more tokens. The session grows longer, compaction occurs. The useful signal that occurs for our agents is lost in a slew of other irrelevant

[02:07] information. Likewise, scratch pads are workarounds. So, things like markdown files, we start building large hierarchies of files, uh wikis, prompts. These do help, but this is not governed recall. Uh files do not scale in large multi-tenant environments. Uh tools like grep are extremely useful for finding data, but they also don’t scale well, and it is not complex hybrid retrieval. And I feel like if we continue to the

[02:41] logical conclusion of trying to build a memory layer on top of files, we’re going to be building our own database. And I don’t I you could just use a database. Uh in this presentation, this is unpacking the lessons that we’ve learned as a database vendor working with customers who are developing agent memory, customers who are solving real problems with agents and needing recall. And where we’re seeing modern agent memory systems converge is there’s there’s a pattern that’s implementing

[03:12] memory formation, memory recall, evolution, and evaluation. So, when we form memories, these are these are distilled experiences, structured facts. This is not a raw transcript dump. When we’re recalling memories, hybrid retrieval is emerging as a dominant method. This is This is a form of retrieval that fuses different types of search. So, vector similarity search, lexical search, entity search over relational objects, graph traversals, and different signals over temporal data, recency, and feedback. We also need consolidation in these

[03:45] systems. So, duplicates can emerge. We need to resolve conflicts. The system needs to evolve over time. Otherwise, because it becomes stale, irrelevant, and useless. Memories need element of temporality. So, when was this created? When was it accessed? How long is it valid for? It may only be valid for a certain time window. And this all needs to come into regular feedback and evaluation. If I’m not measuring use, I’m not sending feedback into the memory layer, it’s all going to fall over. Um another

[04:18] important piece is the governance controls. So, secrets, personal information, that needs to be redacted before it hits the memory layer. Rights need to be scoped, scoped to the agent, scoped to the workflow, the team, the user. This is especially important in multi-tenant environments. We need appropriate admin approvals, review, and ability to suppress stale or poisoned data. When we walk through the memory loop, we have an agent session. It does some work, reads documents, run queries, synthesizes useful data.

[04:50] After that session or during that session, a fact is created. We record that fact through redacting, enriching, storing it in the persistence layer. And then when another session comes along with related context, it can retrieve that fact and use it for context card reconstruction. So, it’s using that fact that came from a prior art to make the next task easier. That’s less work for the next agent to do. And if that agent uses the fact successfully, we can add feedback scores to that memory. So, we’re adapting over time. We get related data and new temporality. We

[05:26] access it again. We We did something with it. Now, memory, it’s invoked as a function by the agent runtime. So, it needs read, write, and storage layers. Your agent runtime can invoke the memory layer through things like hooks, MCP, skills, or other methods. And the memory layer API is exposing these the read write the feedback administrative APIs and then talking to the storage platform or databases.

[05:56] The choice of database here I I think multi-model databases are especially useful because they allow you to not work work with your rows, columns, vector embeddings, full text search, relational entities, graphs, episodes and facts all in one place. So your memory can live in a consolidated place with one database query connection. I can do all sorts of hybrid search and return that data back. Uh what does the memory look like? Uh it’s going to be typed and this you

[06:28] may have seen this model at different presentations or some form of it. Um this loosely comes from human memory can be applied to agents. So we have episodic memory. This is specific past events or slices of transcripts that the agents worked on. We have semantic memory. Um these are specific facts about our workflows, user preferences, and other entities. We have procedural memory. This is like how we did a specific task or routine, maybe a build step. These are reusable rules the agents are going to want to pull up again and again if they’re are repeating similar work. And we have working state. Working state

[07:01] is like short-term memory. It’s what are we what are we current currently working on and that that temporal data may only be valid for a certain time window and we may promote it to a different type of memory. This helps us bucket into different areas and we can use different search techniques on these types of memory. Uh what does the storage schema look like for memory? Um so memory are typed objects plus lookup path. So our our memory object is going to have some ID like a primary key. It’ll have its text content, JSON tags, document data.

[07:32] It’ll have a vector embedding. Uh we have a vector created over the content with a vector index for similarity search. Ideally we’ll also have a text index to facilitate full text keyword search. That combines with vector search. Uh we can have graph links to different edges. Memories can be related through an entity graph. So, this memory is connected to this memory, which is connected to that memory. It’s additional context that we can pull back during the search stage. We can also have temporal facts. When is this memory valid to? What was the last time that we used it? And then also it’s super importantly audit

[08:04] events. Who Who created this memory? What did they use it for? Uh the log of of of of how it’s been used and associated metadata. Um this should all be part of your storage schema when we’re working with memories. When we create memories, we want to intentionally form them. Good memories are very intentional. So, we need to decide the life cycle, the scope, the different relationships, and associated metadata. When an agent runtime decides to create a memory, we should first start with redaction.

[08:36] Uh redaction is very important as the first step because before I do embeddings, before I do enrichment, I want to strip out PII. I don’t want secrets or irrelevant weird information slipping into the memory layer. That’s a recipe for disaster. So, we do redaction first. Then we can enrich the memory. What is the mem- What is the memory related to? What is the metadata of the memory? We can apply the scope to it. Uh what is the agent that worked on this memory? What’s the team? What’s the organization? This helps bucket into specific areas so I’m not getting

[09:07] memories in other sessions that are associated with other agents or workflows, which adds confusion. We can do the embedding so we create the vector of the content. And then we can form what’s called the episode. These are the slices of the transcript that created the memory. This is good for provenance and additional context. Um any organization-specific policies here can also be applied. Uh whatever you need for your specific use case. And then we can save down to the storage layer. Um when we create memory, the individual memories can be quite compact. So, we take the transcript and we distill it

[09:38] down to that content and metadata and embedding and and and related stuff, but we can also we create these episodes. So, we take the agent transcripts, we filter them, find candidates for these episodes, save the memory record, and link it back. You can do this with uh relations, just straight-up database relationships. You can do it with graphs. I particularly like graphs because they allow a broader search here. Uh when we’re talking about memory recall, that is how do we remember something? This is a

[10:09] retrieval problem, so a query problem on the storage layer. Um and with with retrieval or recall, hybrid search is emerging as the dominant method of context reconstruction. And this this form of retra retrieval can fuse different search methods. So, I can take vector similarity search, I can take a full-text keyword search, I can take relational entities, I can do graph traversal, I can take other feedback signals like importance uh uh and usefulness of the memory to yield more comprehensive results than one

[10:43] specific query branch alone. Like, if I was only doing similarity search, I only get the most similar results according to the embedding model that I’m using. Um and in general, this has not been enough. So, we have all these different query branches, um different types of memory, you can decide which ones you want to do. Things like facts, you might not want similarity, you might just want to do like an exact ID match on a fact. Um we can take these results, we can fuse them, apply thresholds, do re-ranking, and then we get a context card with scored evidence. So, we can say this

[11:15] memory it rate it rated very well on vector search and a little bit lower on lexical search. Um that’s the provenance of the memory, where it came from, how we got it. That’s important, too. Um as we as we walk through hybrid search, uh vector distance useful for for semantically similar things like contains operator, very good for lexical search, uh, graph table, temporal data, all this stuff. We take these branches, we apply weights to them. We can await differently as needed. This is something that can be

[11:47] tuned in your your hybrid search algorithm. The The results are merged to an overall score from the different query branches, and then we can take the top K of the overall results to say hey, here are the top three best results from our hybrid search algorithm. And that’s loosely how you can implement hybrid search in a multimodal database, a database that is capable of providing all of these different search methods from one pane of glass here. Now, memories, it’s not just a repository where we push data in and we

[12:17] pull data out. Memories need to evolve over time to be truly useful. We also don’t want to just shove all our data in every time, otherwise we get tons of memories. Um, and this is where we can kind of close the memory loop with consolidation and error handling. Uh, stale memory can occur when, say, my my project uses NPM at one time and then we decide to switch to another build system. Well, what happens to all the memories that were related to NPM? If an agent recalls those, it’s it’s

[12:47] going to be a little tricky and it may try to do the wrong thing. Uh, so the system it needs to expect stale facts over recall quiet drift. Bad scope can occur where we’re not appropriately appropriately scoping memories in the right context. This is like if you log into your ChatGPT account and you get someone else’s message history. Um, if you’re not applying scope properly, you can have some really bad data leaks. So, this needs to happen on write and on read. Uh, poison memory is when a untrusted

[13:18] source plants a durable instruction in your memory layer. This is kind of the worst-case scenario, like a prompt injection happened, you didn’t have the appropriate guardrails, You didn’t have the appropriate review, redaction, controls on memory, and and some really nasty stuff got in there, and all your data got exfiltrated. So, uh be very sure to avoid these kind of things through the proper guard rails and administrative actions. Uh a memory conflict is when I have two different memories. One says, “Hey, we do the task this way.” And the other says, “Well, actually, we do it this

[13:49] way.” Because they’re both about the same task, they’re going to rank very highly on retrieval. So, you probably get these same conflicts in your context card. And when the agent consume that, it’s like, “Well, you know, you told me the restaurant’s to the right, and it’s actually to left. I don’t know what to do.” Um so, detection review here is very important for conflict resolution. Uh scoping as well. Sometimes there are different ways to do the same task. Um over recall and irrelevance happen as your memory system grows. Um if we’re

[14:20] just shoving all of our data in there and not really thinking about what we’re writing, um we can get into the situation of over recall where we have so many different weak matches, they’re crowding out the context card. This is the same problem with the very large context window where we try and smoosh in as much data as possible. It’s just confusing. Irrelevance, uh semantically close memories that rank highly on hybrid search, but it’s not actually about the task. It just it rated highly. So, these are these are problems of of management and your search algorithm tuning.

[14:53] Data leakage is when we get weird, unexpected data that enters memory system. This is a less serious version of poisoned memory. Um proper enrichment and distillation of the memory records on the right path is the way to solve leakage. Uh over time also, we get silent drift. This is where the memory system grows. Maybe it works freaking awesome at like a thousand records. But then when I have 50,000 or a million or more, it’s I’m getting all these weird results, and it’s it’s really working. So, it’s very, very important to apply the proper countermeasures, the

[15:25] reduction before write, the scope checks review, life cycle, and most importantly feedback. Feedback is what closes the loop from memory. Memory quality needs to be measurable. We need to have correct retrieval. We need to account for stale or harmful memories, and ultimately the downstream usefulness of the system. It needs to feedback to these ranking life cycle decisions. So, if an agent retrieves a candidate memory, it’ll use it, it’ll reject it. Maybe if it uses it, everything goes haywire and it crashes. Like, that feedback needs to come back.

[15:57] And if if the memory was harmful, the feedback should go down. If it was useful, maybe we promote it. So, it’s not just a repository. It needs to store Your memory layer needs to store whether memories were helpful, stale, irrelevant, harmful, etc. Um and we really we want to design for measurable recall with governed memory formation built on a multi-modal storage platform. So, without memory, these agents are more likely to restart the same tasks. They’re going to recreate over and over again. They’re going to

[16:29] read the same files. They’re going to run the same queries. They’re going to waste tons of time, tons of tokens, uh be much slower, and much more much more failure prone. They’re going to repeat the same mistakes. If it doesn’t know about prior art, it’s going to do the same thing over again. And if that thing was wrong, it’ll be wrong again and again. And with governed memory, the agents can resume where they left off. They can reuse what came before them, and ultimately reduce repeated failures. This is This is the true goal of recording, retrieving, governing,

[16:59] evolving. Um we want to improve the success rate. We want to do it faster. We want to do it cheaper. We want to do it better. Um if you are hands-on, um I recommend checking out our Python SDK for agent memory. This code will take you to a GitHub link with a Python notebook that walks through how to do this using our SDK. The SDK is built on database primitives. Um everything that we talk about here lives in the database. Um you We also have our developer hub. If you’re an AI engineer, you’re

[17:33] builder, you’re curious like how does a modern multi-model database fit into AI development? This is the place to go to check out our samples, um see what’s possible, and maybe even inspire you to build something cool uh with a very awesome database. Uh again, I’m Anders um Anders Swanson. If you want to chat or connect with me, I’ll be over at the Oracle booth. Um and thank you so much. I hope this was useful to you guys and uh helpful as you’re you’re building awesome things. Thank you so much.