Memory Types & Architecture

A primeira coisa que percebi: "memória" não é uma coisa só. O sistema de suporte precisava lembrar o que aconteceu nesta conversa (curto prazo), o que aconteceu em conversas passadas com este cliente (episódica), o que o sistema de cobrança realmente faz (semântica) e como executar um processo de reembolso (procedural). São quatro problemas distintos com quatro estratégias de armazenamento distintas.

graph TD
    A[Memória do Agente] --> B[Curto Prazo\nJanela de Contexto]
    A --> C[Episódica\nHistórico de Sessão]
    A --> D[Semântica\nFatos e Conhecimento]
    A --> E[Procedural\nHabilidades e Como Fazer]
    B --> F[Em memória, expira]
    C --> G[Armazenamento persistente, com timestamp]
    D --> H[Armazenamento persistente, indexado]
    E --> I[Config / definições de ferramentas]

Aqui está a taxonomia de trabalho em que cheguei:

• Curto prazo — a própria janela de contexto. Rápida, sempre disponível, desaparece quando a sessão termina.
• Episódica — um registro de sessões passadas: o que foi tentado, o que funcionou, o que falhou, quando.
• Semântica — fatos, conhecimento do produto, conceitos do domínio. O que é verdade sobre o mundo.
• Procedural — como fazer as coisas. Schemas de ferramentas, passos de runbook, caminhos de escalonamento.

Cada tipo mapeia para um mecanismo de armazenamento e padrão de recuperação diferente. Acertar a taxonomia antes de escrever qualquer código me poupou de construir uma "tabela de memória" monolítica que seria impossível de consultar efetivamente.

A memória de curto prazo é a janela de contexto — as mensagens que o modelo vê agora. É rápida, sem latência, e inerentemente sem estado: quando a chamada de API termina, o contexto desaparece.

O problema prático com a memória de curto prazo é capacidade. Uma conversa de suporte longa pode facilmente atingir 50.000+ tokens em múltiplas chamadas de ferramentas. A maioria dos modelos tem limites de contexto, e mesmo modelos com janelas grandes ficam mais lentos e caros à medida que o contexto cresce.

Os dois padrões comuns para gerenciar o tamanho da janela de contexto:

Janela deslizante — manter apenas as últimas N conversas. Simples de implementar, mas o agente "esquece" as conversas anteriores abruptamente.

Sumarização — usar o modelo para compactar conversas antigas em um resumo, depois substituí-las. Preserva a intenção mas perde detalhes. Custa uma chamada de modelo.

A memória episódica é um registro com timestamp de sessões passadas e seus resultados. Ela responde à pergunta: "O que aconteceu antes, com este usuário, neste contexto?"

No sistema de automação de suporte, a ausência de memória episódica causou uma falha específica e frustrante: um cliente abria uma nova sessão sobre um problema de cobrança, e o agente percorria os mesmos passos de diagnóstico que já havia executado com eles duas vezes antes. O cliente sabia disso; o agente não. A sessão começava do zero toda vez.

A correção era simples em conceito: persistir um registro de cada sessão — o que foi tentado, qual foi o resultado, quando aconteceu — e recuperá-lo no início de qualquer nova sessão com o mesmo cliente.

Recuperar esses dados no início da sessão permite que o agente comece com: "Vejo que analisamos este problema de cobrança duas vezes antes — em ambas as vezes o processador de cartão retornou um timeout. Desta vez vou verificar o status do processador primeiro."

A memória semântica armazena fatos que são verdadeiros sobre o mundo — documentação de produtos, regras do sistema de cobrança, políticas de escalonamento, bugs conhecidos. Ela não é específica para nenhuma sessão ou cliente; é conhecimento compartilhado que o agente precisa para raciocinar corretamente.

A distinção principal da memória episódica: a memória semântica responde "o que é verdade?" enquanto a memória episódica responde "o que aconteceu?"

No sistema de suporte, a memória semântica incluía coisas como:

• Como o processador de cobrança lida com a lógica de retry
• Quais códigos de erro mapeiam para quais modos de falha
• Quais tipos de conta são elegíveis para reembolsos automáticos

Armazenar a memória semântica separadamente do histórico de sessão significa que ela pode ser atualizada uma vez (quando uma política muda) e imediatamente afeta todas as consultas futuras, sem re-treinar nada.

A memória semântica viável mais simples é uma tabela de fatos com uma descrição de texto, consultada com busca por palavras-chave para começar e atualizada para busca vetorial quando a busca por palavras-chave falha:

Cada tipo de memória tem um encaixe natural. O erro que cometi cedo foi alcançar a memória episódica quando eu na verdade precisava de memória semântica, e vice-versa. Aqui está o guia de decisão que uso:

Comece com curto prazo. A janela de contexto é gratuita e instantânea. Só mova informações para memória persistente quando atingir um limite real: a sessão termina e você precisa dela novamente (→ episódica), o agente não tem conhecimento de domínio que não consegue inferir (→ semântica), ou um fluxo de trabalho é complexo demais para manter no contexto (→ procedural).

A confusão episódica vs. semântica é o erro mais comum. A regra: se a informação é sobre um evento passado específico ("o cartão deste cliente foi recusado às 14h na terça-feira"), é episódica. Se é um fato geral que seria verdadeiro para qualquer cliente ("nosso processador de cobrança tenta novamente cobranças com falha após 24 horas"), é semântica.

Não exagere na engenharia de memória procedural. Na maioria dos sistemas que construí, a memória procedural são apenas schemas de ferramentas e YAML de runbook, não um banco de dados separado. O agente lê a definição da ferramenta e sabe como usá-la. Só construa um armazenamento dinâmico de memória procedural se o conjunto de ferramentas mudar frequentemente em tempo de execução.