Um agente que "lembra" colando todo o seu histórico no próximo prompt não tem memória. Tem uma conta crescente, um teto rígido de tokens, e uma curva de latência que piora a cada turno. Memória de verdade é uma decisão de armazenamento: o que você persiste, onde você coloca, e como você busca de volta apenas a fatia relevante no momento da inferência. Isso é um problema de banco de dados, e tratá-lo como um problema de prompt é como agentes que se saem bem em demo desmoronam na segunda semana.

A parte sedutora de empilhar contexto é que funciona no começo. No início de uma sessão o histórico é curto, tudo cabe, e o agente parece que lembra. Depois a conversa cresce, o prompt cresce junto, e três coisas acontecem ao mesmo tempo: o custo sobe porque você reenvia tudo a cada turno, a latência sobe porque o modelo lê mais a cada vez, e eventualmente você bate no limite da janela de contexto e fatos antigos caem silenciosamente da frente. A falha não é um bug que você pode corrigir com um patch. É a arquitetura.

Dois tipos de memória, dois tipos de armazenamento

"Memória" na verdade são duas necessidades diferentes, e confundi-las é onde os designs dão errado.

Memória de sessão e de trabalho: um key-value store

Os turnos recentes, o estado atual da tarefa, as preferências de curto prazo do usuário, essas coisas são buscadas por uma chave conhecida: um ID de sessão, um ID de usuário, um ID de thread. Você quer leituras e escritas rápidas naquela chave e um time-to-live para que sessões obsoletas expirem sozinhas. Isso é uma tabela do DynamoDB, não uma busca vetorial. Particione por sessão ou usuário, mantenha o estado corrente como um item, defina um TTL, e leia de volta no início de cada turno. Sem embeddings, sem similaridade, apenas uma busca rápida por chave de "onde estávamos".

Memória semântica de longo prazo: um vector store

Os fatos que um agente deve lembrar entre sessões, decisões anteriores, preferências aprendidas, trocas passadas relevantes, não são buscados por chave. São buscados por significado: "o que eu sei que é relevante para essa nova mensagem". Isso é busca semântica sobre embeddings, que é para o que serve um vector store. Na AWS, a escolha pragmática é Aurora Serverless v2 com pgvector: seus embeddings vivem ao lado de dados relacionais, você os consulta com SQL, e não precisa levantar um banco especializado separado para isso.

O padrão: buscar, não acumular

Uma vez que a memória é um banco de dados, cada turno para de anexar e passa a consultar. O loop se torna:

on each turn:
  1. read session state by key      (DynamoDB: where were we)
  2. embed the new user message
  3. semantic search long-term store (pgvector: what is relevant)
  4. assemble a bounded prompt:
       system + tools
       + top-k retrieved memories
       + recent turns from session state
       + new message
  5. call the model
  6. write new facts back to the stores

O prompt agora é limitado não importa quão longa seja a relação com o usuário. Uma conversa no seu turno de número mil envia um prompt do mesmo tamanho que no décimo, porque você busca o punhado relevante de memórias em vez de carregar todas elas. Custo e latência ficam estáveis em vez de subir. É a mesma disciplina de busca que faz o RAG funcionar, aplicada ao próprio histórico do agente em vez de a um corpus de documentos.

O que você precisa decidir, que um prompt esconde

Mover a memória para um banco de dados força escolhas que empilhar contexto deixava você ignorar, e essas escolhas são a engenharia de verdade:

  • O que vale a pena lembrar. Nem todo turno é uma memória. Escreva fatos e decisões duráveis, não conversa fiada, ou seu armazenamento enche de ruído que a busca depois traz à tona.
  • Quando esquecer. TTLs no estado de sessão, e uma política para envelhecer ou substituir fatos de longo prazo, para que uma preferência antiga não sobreponha uma corrigida.
  • Quanto buscar. Top-k é um ajuste. Pouco demais e o agente esquece; demais e você volta a um prompt inchado com o passo de busca sem adicionar valor.
  • Consistência entre os dois armazenamentos. Memória de sessão e semântica podem discordar. Decida qual vence quando isso acontece.

A conclusão

Empilhar contexto não é memória, é adiar uma decisão de armazenamento até que a conta de tokens e o teto de contexto a tomem por você. Divida o problema: estado de sessão rápido por chave no DynamoDB, recall semântico de longo prazo no pgvector sobre Aurora, e um passo de busca por turno que monta um prompt limitado a partir dos dois. No momento em que a memória vira um banco de dados com um passo de busca em vez de um prompt sempre crescente, o custo e a latência param de escalar com o comprimento da conversa, e você passa a decidir o que o agente lembra em vez de deixar a janela decidir o que ele esquece.

Leia isso a seguir

Para o lado de banco de dados e infraestrutura de rodar Aurora e DynamoDB em escala, as notas de campo sobre cloud estão em ercan.cloud, e o hub está em ercanermis.com.