Você constrói um agente incrível, ele resolve a tarefa lindamente na demo — e no dia seguinte não lembra de absolutamente nada. Cada nova sessão começa do zero: o agente esquece quem é o usuário, o que já foi decidido e o que deu errado na última tentativa. Memória é o que separa um chatbot que responde perguntas de um agente que acompanha um objetivo ao longo do tempo. Neste artigo eu mostro os tipos de memória que importam, como eles se encaixam e como implementar isso na prática — sem transformar seu agente em um projeto de plataforma.

Contexto Modelos de linguagem são stateless: cada chamada à API é independente e o modelo não “lembra” da anterior. Toda a sensação de continuidade que você vê num agente é engenharia de memória por cima de um modelo sem estado.

O que é memória de agentes?

Memória de agente é a capacidade de capturar, armazenar e recuperar informação relevante entre turnos e entre sessões, injetando-a de volta no contexto no momento certo. Ela não vive dentro do modelo — vive na sua orquestração: você decide o que guardar, onde guardar e o que trazer de volta a cada chamada.

Diferente de simplesmente empilhar todo o histórico no prompt (caro e limitado pela janela de contexto), memória bem-feita é seletiva: guarda o que tem valor duradouro e recupera apenas o que é relevante para a tarefa atual.

O problema que ela resolve

Sem memória, você esbarra em três paredes:

1. Amnésia entre sessões — o agente não sabe nada do que aconteceu ontem. Nada de preferências, decisões ou contexto do usuário.
2. Estouro da janela de contexto — a saída óbvia (“mandar todo o histórico”) não escala: a janela é finita e cada token custa. Conversas longas simplesmente não cabem.
3. Custo e latência — reenviar dezenas de milhares de tokens a cada turno é caro e lento, mesmo com prompt caching.

Numa análise real de consumo, uma ferramenta agêntica acumulou ~195 milhões de tokens de entrada em 638 chamadas — mais de 300 mil tokens por chamada. Boa parte disso era histórico reenviado que poderia ter virado memória recuperável em vez de contexto bruto.

Curto prazo vive na sessão; longo prazo persiste entre sessões — ligados por um ciclo de retrieval e write-back.

Os tipos de memória que importam

Pense em duas camadas.

Curto prazo (dentro da sessão)

• Janela de contexto — o system prompt, as instruções e o histórico recente do turno atual. É volátil e limitada.
• Memória de trabalho — o “rascunho” da tarefa em andamento: estado intermediário, resultados de ferramentas, plano atual. Some quando a sessão termina.

Longo prazo (entre sessões)

• Episódica — o que aconteceu: eventos, interações passadas, “na última vez o deploy falhou por falta de RBAC”. Ótima para continuidade e personalização.
• Semântica — fatos e conhecimento: preferências do usuário, regras de negócio, documentação. É a base do RAG.
• Procedural — como fazer: skills, prompts reutilizáveis e procedimentos que o agente aprendeu a executar.

A regra prática: curto prazo é gerenciado pela janela; longo prazo vive em um vector store (busca por similaridade) muitas vezes combinado com um graph store (relações entre entidades).

Como funciona — passo a passo

O padrão é um ciclo de recuperar → usar → gravar:

1. Recupere (retrieval) — a cada turno, transforme a intenção do usuário em uma query e busque no armazenamento de longo prazo os top-k trechos mais relevantes (similaridade vetorial + filtros de recência/metadados).
2. Monte o contexto — injete o recuperado + a memória de trabalho + a pergunta atual na janela, mantendo o conteúdo estável no início (bom para prompt caching) e o variável no fim.
3. Raciocine e aja — o modelo responde ou chama ferramentas, atualizando a memória de trabalho.
4. Grave (write-back) — ao fim do turno/sessão, destile o que tem valor duradouro (resumos, fatos novos, resultado da tarefa) e persista como embeddings no store. Não grave tudo — grave o que você vai querer recuperar depois.
5. Esqueça de propósito — aplique políticas de expiração, deduplicação e sumarização para o store não virar um depósito infinito.

        [ Pergunta do usuário ]
                  |
                  v
        query -> retrieval (top-k) --------------------+
                  |                                    |
                  v                                    |
   [ Janela: system + recuperado + histórico curto ]  | (recupera)
                  |                                    |
                  v                                    |
        [ Modelo + ferramentas ]                       |
                  |                                    |
                  v                                    |
        [ Resposta ]                                   |
                  |                                    |
                  v                                    |
        destila (resumo/fatos) -> write-back ----> [ Vector + Graph store ]

Implementando no Microsoft Agent Framework

O Microsoft Agent Framework (e o Semantic Kernel) já trazem as abstrações de thread (curto prazo) e de memory store (longo prazo), então você não precisa reinventar o encanamento. A ideia é plugar um armazenamento vetorial e um componente que faz o ciclo de recuperar/gravar automaticamente.

1. Curto prazo — o thread carrega o histórico da sessão:

from agent_framework import ChatAgent

agent = ChatAgent(chat_client=client, instructions="Você é um arquiteto de soluções.")
thread = agent.get_new_thread()  # mantém o histórico do turno atual

await agent.run("Vamos desenhar a arquitetura de ingestão.", thread=thread)
await agent.run("E como fica o custo?", thread=thread)  # lembra do turno anterior

2. Longo prazo — conecte um vector store como provedor de contexto:

from agent_framework import ChatAgent
from agent_framework.mem0 import Mem0Provider  # provedor de memória de longo prazo

agent = ChatAgent(
    chat_client=client,
    instructions="Arquiteto de soluções com memória entre sessões.",
    context_providers=Mem0Provider(user_id="eron"),  # recupera + grava automático
)

# Sessão de hoje: o provider recupera memórias do usuário e injeta no contexto,
# e ao final grava fatos novos ("prefere Databricks para batch") para amanhã.
await agent.run("Continue de onde paramos no projeto de lakehouse.")

3. Store no Azure — para produção, use um armazenamento vetorial gerenciado: Azure AI Search (busca híbrida: vetorial + palavra-chave + semantic ranker), Cosmos DB com busca vetorial, ou o vector search do Databricks quando o conhecimento já vive no Lakehouse. Gere embeddings com um modelo do catálogo (ex.: text-embedding-3-large) e guarde metadados (usuário, timestamp, fonte) para filtrar na recuperação.

Estratégias de recuperação (onde a qualidade é ganha ou perdida)

• Relevância vetorial + recência — combine similaridade semântica com um boost por tempo; o que é recente costuma importar mais.
• Busca híbrida — vetorial + palavra-chave evita perder termos exatos (nomes, códigos, SKUs).
• Sumarização progressiva — em vez de guardar transcrições inteiras, destile a sessão em um resumo curto; recupere o resumo, não o bruto.
• Filtros por metadados — escopo por user_id, projeto ou tenant é o que mantém a memória segura e relevante em cenários multiusuário.

Boas práticas para produção

• Grave com parcimônia — memória não é log. Persista fatos e resumos com valor de reuso, não cada mensagem.
• Esqueça de propósito — TTL, deduplicação e compactação evitam que o store cresça sem limite e polua a recuperação.
• Isole por identidade — sempre filtre a recuperação por user_id/tenant. Memória vazando entre usuários é um incidente de segurança, não um bug de UX.
• Governe o que entra — aplique content safety e evite persistir dados sensíveis (PII) sem necessidade e sem base legal.
• Meça a recuperação — avalie precision/recall do retrieval como você avaliaria um sistema de busca; memória ruim é pior que memória nenhuma.
• Estável no início do prompt — mantenha o conteúdo fixo no começo para casar com prompt caching e cortar custo.

Perguntas frequentes (FAQ)

Memória de agente é a mesma coisa que RAG?

Não exatamente. RAG é uma técnica de recuperação de conhecimento (tipicamente memória semântica, sobre uma base de documentos). Memória de agente é mais amplo: inclui também episódica (o que aconteceu) e procedural (como fazer), além do estado de curto prazo da sessão.

Preciso de um banco vetorial dedicado?

Para começar, não. Um thread em memória já resolve o curto prazo. Para longo prazo em produção, um store vetorial gerenciado (Azure AI Search, Cosmos DB, Databricks Vector Search) entrega escala, filtros e busca híbrida sem você manter infraestrutura.

Como evito que a memória “envenene” o agente com informação velha?

Com políticas de esquecimento: TTL, sumarização e deduplicação, além de boost por recência na recuperação. Trate a memória como um dataset que precisa de curadoria — não como um log append-only.

Onde a memória de curto prazo termina e a de longo prazo começa?

Curto prazo é o que cabe e faz sentido na janela de contexto da sessão atual. Quando a sessão termina (ou o histórico fica grande demais), você destila o que importa e promove para o longo prazo.

Conclusão

Memória é o que transforma um agente reativo em um parceiro que evolui com o usuário. O segredo não é guardar tudo — é guardar o certo, recuperar o relevante e esquecer o irrelevante, tudo dentro de um ciclo simples de retrieval e write-back. Frameworks como o Microsoft Agent Framework já entregam as abstrações; o seu trabalho de arquitetura é escolher os tipos de memória, o store e as políticas de recuperação e esquecimento.

👉 Se você está desenhando agentes que precisam lembrar — especialmente em cenários multiusuário e regulados —, memória é a decisão de arquitetura que separa a demo do produto. Quer trocar ideia sobre memória e recuperação em agentes? Me chama no LinkedIn.