Pular para o conteúdo
← Voltar para o Skalablog

Artigo publicado

Como criar uma camada de memória para agentes?

Engenharia de Software

Uma camada de memória para agentes transforma o que o agente aprendeu em cada sessão em estado persistente, tipado e pesquisável. Janelas de contexto não guardam experiência: quando a sessão termina, o trabalho útil se perde e o próximo agente recomeça do zero.

Por que janelas de contexto e arquivos não são memória

Janela de contexto não é memória: ela é apenas a entrada da execução atual, sem persistência entre sessões. Quando um agente termina uma tarefa, tudo que ele sintetizou é descartado, e o próximo agente repete o mesmo trabalho, com mais custo, mais chance de alucinação e menos fidelidade.

Anders Swanson, desenvolvedor advocate do Oracle AI Database, apresentou essa tese na AI Engineer World's Fair de 2026, em São Francisco. Ele argumenta que memória de agente deve ser tratada como um problema de sistemas: formação, recuperação, armazenamento persistente e governança trabalhando juntos.

As soluções paliativas falham por razões previsíveis. Janelas maiores só acumulam tokens, e o sinal útil se perde entre informação irrelevante durante a compactação. Arquivos markdown e wikis ajudam, mas não oferecem recuperação governada nem escalam em ambientes multi-tenant. O grep encontra dados, mas não faz fusão de múltiplos sinais de busca. Seguindo essa estrada até o fim, você acaba implementando seu próprio banco de dados — e aí vale simplesmente usar um.

O padrão de quatro fases da camada de memória para agentes

A camada de memória para agentes que sistemas modernos estão convergindo em adotar implementa quatro fases: formação, recuperação, evolução e avaliação. Cada fase responde a uma pergunta diferente sobre o ciclo de vida do conhecimento do agente.

Na formação, memórias são experiências destiladas e fatos estruturados, nunca despejos de transcrições brutas. Na recuperação, a busca híbrida funde vários métodos de consulta. Na evolução, o sistema consolida duplicatas, resolve conflitos e aplica temporalidade: quando a memória foi criada, quando foi acessada e por quanto tempo ela continua válida. Na avaliação, um ciclo regular de feedback mede uso e utilidade — sem medir, tudo fracassa.

O fluxo completo é simples de visualizar. Uma sessão de agente lê documentos, executa consultas e sintetiza algo útil. Um fato é criado, redigido, enriquecido e salvo na camada de persistência. Numa sessão futura com contexto relacionado, esse fato é recuperado para reconstruir o cartão de contexto, e o feedback do uso ajusta a relevância da memória ao longo do tempo.

Arquiteturalmente, a memória é invocada como uma função pelo runtime do agente, por meio de hooks, MCP ou habilidades. A API expõe operações de leitura, escrita, feedback e administração, que conversam com a plataforma de armazenamento. Bancos multimodelo são especialmente úteis aqui, porque vetores, busca de texto completo, entidades relacionais e grafos ficam em um só lugar, com uma única conexão de consulta.

Memórias tipadas: os quatro tipos que você deve armazenar

O modelo de memória tipada, inspirado livremente na memória humana, divide o que o agente aprende em quatro categorias. A tipagem importa porque cada tipo pede técnicas de busca distintas: um fato pode exigir correspondência exata de ID, enquanto uma rotina se beneficia de similaridade semântica.

Tipo — O que guarda — Exemplo — — --- — --- — --- — — Episódica — Eventos passados e trechos de transcrição do trabalho do agente — Como uma falha foi reproduzida — — Semântica — Fatos sobre fluxos de trabalho, preferências e entidades — "Este projeto usa o gerador X" — — Procedural — Rotinas e regras reutilizáveis para tarefas semelhantes — Passos de build do projeto — — Estado de trabalho — Memória de curto prazo sobre a tarefa atual, com validade limitada — Rascunho em andamento, pode ser promovido

O estado de trabalho merece atenção especial. Ele vale apenas por uma janela de tempo e pode ser promovido a outro tipo quando o conteúdo se mostra durável. Essa distinção evita que o efêmero contamine o permanente.

Esquema de armazenamento: o que toda memória precisa ter

No esquema descrito na palestra, uma memória é um objeto tipado mais um caminho de busca. O objeto tem um ID como chave primária, conteúdo de texto, tags JSON, dados do documento e um vetor de embedding com índice vetorial para busca por similaridade.

Além do vetor, o esquema ideal inclui um índice de texto para busca por palavras-chave, links de grafo conectando memórias relacionadas, campos temporais de validade e último acesso, e eventos de auditoria. A auditoria registra quem criou a memória, para que ela foi usada e quais metadados acompanharam cada uso.

Os episódios complementam o objeto compacto: são os fragmentos de transcrição que originaram a memória, úteis para proveniência e contexto adicional. Você pode vinculá-los com relações diretas de banco de dados ou com grafos. O palestrante prefere grafos porque permitem uma busca mais ampla durante a recuperação.

Formação segura: redação antes de qualquer embedding

Boas memórias são intencionais. Antes de gravar, o ciclo de vida, o escopo, as relações e os metadados precisam estar decididos — e a redação vem primeiro, sempre.

A ordem de formação segue estes passos:

  1. Redigir o conteúdo, removendo PII e segredos antes de qualquer embedding ou enriquecimento. Fazer o contrário é receita para desastre. 2. Enriquecer a memória com metadados e relações: a que ela se conecta. 3. Aplicar escopo: agente, equipe, organização — sem isso, memórias de outros fluxos vazam para sessões alheias. 4. Gerar o embedding do conteúdo. 5. Formar o episódio com os fragmentos de transcrição de origem. 6. Aplicar políticas da organização e salvar na camada de armazenamento, com link de volta ao episódio.

A redação como primeiro passo é o detalhe que mais separa um sistema de memória sério de um repositório de transcrições. Nada que escapou da redação deve alcançar o vetor, o índice ou o grafo.

Recuperação com busca híbrida: fundindo múltiplos sinais

A busca híbrida está emergindo como o método dominante de reconstrução de contexto. A ideia é fundir ramificações de consulta diferentes e combinar os resultados em uma pontuação única.

Cada ramificação cobre um tipo de sinal: distância vetorial para similaridade semântica, busca lexical com operadores de texto para palavras-chave, entidades relacionais, travessia de grafos e sinais de feedback como importância e utilidade. Só a similaridade vetorial costuma ser insuficiente, porque devolve apenas o que o modelo de embedding considera próximo.

Os pesos entre ramificações são ajustáveis no seu algoritmo de busca. Os resultados são mesclados, limitados e reclassificados, produzindo um cartão de contexto com evidências pontuadas: você sabe que uma memória foi forte na busca vetorial e fraca na lexical. Essa proveniência — de onde o resultado veio e como foi obtido — faz parte do produto final.

A escolha do tipo de busca também depende do tipo de memória. Para fatos, uma correspondência exata de ID pode fazer mais sentido que similaridade. É esse direcionamento por tipo que a tipagem da seção anterior viabiliza.

Modos de falha e o papel do feedback

Memória mal gerenciada falha de formas reconhecíveis. Conhecer cada modo de falha é o que permite desenhar as contramedidas certas antes do desvio silencioso tomar conta do sistema.

Memórias obsoletas

O projeto migrou do NPM para outro sistema de build, e as memórias antigas continuam lá. Se o agente as recuperar, ele fará a coisa errada. O sistema precisa prever fatos obsoletos em vez de deixá-los contaminar a recuperação.

Escopo ruim e vazamento

Sem escopo aplicado na gravação e na leitura, você recebe memórias de outro usuário — como logar na sua conta e ver o histórico de outra pessoa. O vazamento de dados é a versão menos grave; a destilação adequada dos registros resolve.

Memória envenenada

Uma fonte não confiável insere uma instrução durável na camada de memória, o pior cenário: uma injeção de prompt sem salvaguardas pode resultar em exfiltração de dados. Revisão, redação e ações administrativas são as defesas.

Conflito e excesso de recuperação

Duas memórias sobre a mesma tarefa dizem coisas opostas, ambas ranqueiam alto e o agente fica paralisado. Já o excesso de recuperação acontece quando tantas correspondências fracas se acumulam que sobrecarregam o cartão de contexto — o mesmo problema de uma janela gigante.

O feedback fecha o ciclo. Se o agente usou a memória com sucesso, ela é promovida; se foi prejudicial, sua relevância cai. A qualidade da memória precisa ser mensurável: recuperação correta, detecção de memórias obsoletas ou prejudiciais e utilidade a jusante. Com cerca de mil registros tudo funciona, mas aos 50 mil ou um milhão os resultados estranhos aparecem — e é o feedback, a redação prévia e a verificação de escopo que seguram o sistema.

FAQ sobre camada de memória para agentes

  • Janela de contexto maior resolve o problema de memória? Não. Uma janela maior só adiciona tokens à execução atual e o sinal útil se perde na compactação. Memória exige persistência, tipagem e governança fora da janela.
  • Por que não guardar memórias em arquivos markdown? Arquivos ajudam em escala pequena, mas não oferecem recuperação governada nem funcionam bem em ambientes multi-tenant. Sem índices e escopo, você acaba reimplementando um banco de dados sobre arquivos.
  • O que é busca híbrida em memória de agentes? É a fusão de várias ramificações de consulta — similaridade vetorial, busca lexical, entidades relacionais, travessia de grafos e sinais de feedback — em uma pontuação combinada, com reclassificação e proveniência dos resultados.
  • Por que redigir antes de gerar o embedding? Porque depois do embedding o conteúdo já está no índice vetorial. PII e segredos redigidos apenas depois podem persistir na memória e vazar em recuperações futuras.
  • O que é memória envenenada? É quando uma fonte não confiável insere uma instrução durável na camada de memória, funcionando como uma injeção de prompt persistente. As defesas são redação, revisão e controles administrativos antes da escrita.

Da palestra ao artigo: transforme o vídeo em texto

A palestra de Anders Swanson destila uma lição valiosa: memória útil é conhecimento destilado, tipado e governado, não transcrição bruta. O mesmo vale para conteúdo técnico — a conversa original vira valor quando alguém a transforma em texto estruturado e pesquisável. Esta cobertura foi produzida pelo Skala Blog, projeto de Gustavo Dev Doido, criador do Bootcamp do Dev Doido e da formação Crazystack Typescript, disponível em crazystack.com.br.

Se você tem conhecimento valioso em vídeos — aulas, entrevistas, opiniões, demonstrações —, o Skala Blog converte a transcrição do YouTube em um artigo bem estruturado. Visite skalablog.com, cole a URL do vídeo e gere seu artigo.

Source video