Agentes que lembram: Cloudflare lança o Agent Memory para dar memória persistente a agentes de IA
🧠 Memória é uma das palavras mais simples do dicionário, mas quando o assunto são agentes de inteligência artificial, ela se torna um dos desafios mais complexos da engenharia moderna.
Pensa assim: de que adianta um agente de IA incrivelmente capaz se ele esquece tudo que aprendeu assim que a conversa termina? Você treina, ajusta, configura comportamentos, define personalidade, e na próxima sessão o agente age como se nunca tivesse te visto antes. É frustrante para o usuário e é um problema real para qualquer produto que dependa de continuidade e contexto acumulado ao longo do tempo.
Esse é exatamente o problema que a Cloudflare decidiu encarar de frente com o lançamento do Agent Memory, agora em beta privada. O serviço é uma solução gerenciada que extrai informações de conversas de agentes e as disponibiliza no momento certo, sem precisar jogar tudo dentro da janela de contexto de uma vez. Mas antes de entrar nos detalhes técnicos de como isso funciona na prática, vale entender por que isso importa tanto agora.
Mesmo com janelas de contexto chegando a 1 milhão de tokens, um fenômeno chamado context rot ainda assombra os desenvolvedores que trabalham com agentes mais sofisticados. Quanto mais informação você empurra para dentro do contexto, pior fica a qualidade das respostas do modelo. É uma tensão clássica: manter tudo e ver o desempenho cair, ou podar agressivamente e correr o risco de perder exatamente o que o agente vai precisar depois. O Agent Memory chega propondo um caminho diferente, com uma API bem definida, arquitetura baseada em recuperação e um conjunto de operações pensadas para o ciclo de vida real de um agente em produção. 🚀
O problema real com contexto em agentes de IA
Quando falamos de agentes de inteligência artificial em produção, o contexto não é apenas um detalhe técnico. Ele é a espinha dorsal de qualquer interação que precise fazer sentido ao longo do tempo. Um agente que ajuda um usuário a planejar projetos, gerenciar tarefas ou tomar decisões complexas precisa, necessariamente, lembrar o que foi dito antes, o que foi decidido, quais preferências foram expressas e como as coisas evoluíram desde o começo da conversa. Sem isso, cada sessão começa do zero, e o usuário fica preso num loop eterno de reexplicações que desgastam qualquer experiência.
O desafio se torna ainda mais agudo quando você considera que os modelos de linguagem de grande escala, os famosos LLMs, não têm memória persistente por natureza. Eles processam o que está na janela de contexto no momento da inferência e pronto. Tudo que ficou fora dali simplesmente não existe para o modelo. Essa limitação arquitetural gerou uma corrida entre os laboratórios de IA para aumentar cada vez mais o tamanho da janela de contexto, chegando hoje a modelos capazes de processar até um milhão de tokens de uma vez. Parece muito, e é. Mas isso não resolve o problema tão elegantemente quanto parece à primeira vista.
O context rot é exatamente isso: a degradação progressiva da qualidade das respostas conforme o contexto cresce demais. Pesquisas como o LongMemEval, o LoCoMo e o BEAM ajudam a medir esse fenômeno, e experimentos práticos mostram que modelos tendem a dar menos atenção a informações que estão no meio de um contexto muito longo, favorecendo o que aparece no início e no fim. Então, mesmo que você tecnicamente caiba tudo dentro da janela, o modelo pode simplesmente ignorar ou subponderar informações críticas que estão enterradas no meio de milhares de tokens. Para agentes que operam em conversas longas e complexas, isso é um risco real que compromete diretamente a utilidade do sistema.
O cenário atual de memória para agentes
Memória para agentes é uma das áreas que mais se movimenta dentro da infraestrutura de IA neste momento. Novas bibliotecas open-source, serviços gerenciados e protótipos de pesquisa surgem quase semanalmente, cada um com abordagens diferentes sobre o que armazenar, como recuperar informações e para quais tipos de agentes eles foram projetados.
As diferenças de arquitetura entre essas soluções são significativas. Algumas são serviços gerenciados que cuidam da extração e da recuperação em segundo plano. Outras são frameworks auto-hospedados onde o desenvolvedor precisa operar todo o pipeline de memória por conta própria. Algumas expõem APIs limitadas e com propósito específico, mantendo a lógica de memória fora do contexto principal do agente. Outras dão ao modelo acesso direto a um banco de dados ou sistema de arquivos e deixam que ele próprio monte suas consultas, o que acaba queimando tokens com estratégia de armazenamento e recuperação em vez de focar na tarefa real.
Há ainda soluções que tentam encaixar tudo dentro da janela de contexto, distribuindo a carga entre múltiplos agentes quando necessário, enquanto outras usam recuperação para trazer à tona apenas o que é relevante para aquele momento. Cada abordagem tem seus méritos, mas a Cloudflare fez uma escolha deliberada ao posicionar o Agent Memory como um serviço gerenciado com uma API bem definida e arquitetura baseada em recuperação, argumentando que pipelines de ingestão e recuperação mais controlados são superiores a dar ao agente acesso direto ao sistema de arquivos.
Como o Agent Memory da Cloudflare funciona na prática
A abordagem da Cloudflare com o Agent Memory é bastante direta: em vez de tentar resolver o problema de contexto empurrando mais tokens para dentro do modelo, o serviço propõe uma camada intermediária inteligente que gerencia o que entra no contexto e quando isso acontece. A ideia central é que nem toda informação precisa estar presente o tempo todo. O que um agente precisa é ter acesso à informação certa, no momento certo, de forma eficiente e sem desperdício de tokens.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
O Agent Memory organiza memórias dentro de um conceito chamado perfil, que é endereçado por nome. Um perfil oferece várias operações ao desenvolvedor:
- Ingest — a via principal de ingestão em massa, chamada tipicamente quando o harness do agente compacta o contexto
- Remember — permite que o modelo armazene algo importante na hora, de forma explícita
- Recall — executa o pipeline completo de recuperação e retorna uma resposta sintetizada
- List — lista as memórias armazenadas
- Forget — marca uma memória específica como não mais relevante ou verdadeira
Na prática, isso significa que o agente não precisa mais fazer a gestão manual de o que lembrar e o que esquecer. Essa lógica é delegada para a camada de memória, que usa recuperação baseada em similaridade semântica para trazer à tona o que é mais relevante para o momento atual da conversa. Se um usuário retoma um assunto que foi discutido semanas atrás, o agente consegue recuperar aquele contexto de forma natural, sem que o desenvolvedor precise implementar manualmente toda essa lógica de busca, indexação e ranqueamento.
O Agent Memory pode ser acessado via binding a partir de qualquer Cloudflare Worker ou via API REST para agentes que rodam fora do ambiente Workers. Quem já usa o Cloudflare Agents SDK encontra uma integração nativa, já que o serviço funciona como implementação de referência para a parte de memória da Sessions API. 🔧
O pipeline de ingestão por dentro
A ingestão de memória é onde mora grande parte da complexidade que o Agent Memory abstrai para o desenvolvedor. Quando uma conversa chega para ser processada, ela passa por um pipeline de múltiplos estágios que extrai, verifica, classifica e armazena as memórias.
O primeiro passo é a geração determinística de IDs. Cada mensagem recebe um ID baseado em conteúdo, um hash SHA-256 do ID da sessão, do papel (role) e do conteúdo, truncado para 128 bits. Se a mesma conversa for ingerida duas vezes, cada mensagem resolve para o mesmo ID, tornando a reingestão idempotente. Isso evita duplicatas e garante consistência.
Em seguida, o extrator roda duas passadas em paralelo. Uma passada completa divide as mensagens em blocos de aproximadamente 10 mil caracteres, com sobreposição de duas mensagens, processando até quatro blocos de forma concorrente. Cada bloco recebe um transcrito estruturado com rótulos de papel, datas relativas resolvidas para absolutas (por exemplo, ontem se torna 2026-04-14) e índices de linha para rastreabilidade. Para conversas mais longas com nove ou mais mensagens, uma passada de detalhe roda em paralelo, usando janelas sobrepostas focadas especificamente em extrair valores concretos como nomes, preços, números de versão e atributos de entidades que a extração mais ampla tende a generalizar ou perder.
O próximo passo é a verificação. Cada memória extraída é confrontada contra o transcrito original da conversa. O verificador executa oito checagens que cobrem identidade de entidade, identidade de objeto, contexto de localização, precisão temporal, contexto organizacional, completude, contexto relacional e se fatos inferidos são de fato suportados pela conversa. Cada item é aprovado, corrigido ou descartado.
Classificação em quatro tipos de memória
Depois da verificação, o pipeline classifica cada memória verificada em um dos quatro tipos:
- Fatos — representam o que é verdadeiro agora, conhecimento atômico e estável como o projeto usa GraphQL ou o usuário prefere dark mode
- Eventos — capturam o que aconteceu em um momento específico, como um deploy ou uma decisão
- Instruções — descrevem como fazer algo, como procedimentos, workflows e runbooks
- Tarefas — rastreiam o que está sendo trabalhado no momento, e são efêmeras por design
Fatos e instruções recebem chaves normalizadas por tópico. Quando uma nova memória tem a mesma chave de uma já existente, a antiga é supersedida em vez de deletada, criando uma cadeia de versões com um ponteiro da memória antiga para a nova. Tarefas são excluídas do índice vetorial para mantê-lo enxuto, mas continuam descobríveis via busca full-text.
Por fim, tudo é gravado no armazenamento usando INSERT OR IGNORE, de forma que duplicatas baseadas em conteúdo são silenciosamente ignoradas. Após retornar a resposta ao harness, a vetorização roda de forma assíncrona em background. O texto usado para embedding prepende de 3 a 5 consultas de busca geradas durante a classificação ao conteúdo da memória, fazendo uma ponte entre como as memórias são escritas de forma declarativa e como são buscadas de forma interrogativa. 🧩
O pipeline de recuperação
Quando um agente busca uma memória, a consulta passa por um pipeline de recuperação separado e bastante sofisticado. Durante o desenvolvimento, a equipe da Cloudflare descobriu que nenhum método único de recuperação funciona melhor para todos os tipos de consulta. Por isso, eles rodam vários métodos em paralelo e fazem a fusão dos resultados.
O primeiro estágio executa análise da consulta e embedding de forma concorrente. O analisador de consulta produz chaves de tópico ranqueadas, termos de busca full-text com sinônimos e um HyDE (Hypothetical Document Embedding), que é uma declaração formulada como se fosse a resposta para a pergunta. A consulta bruta também é embeddada diretamente, e ambos os embeddings são usados nas etapas seguintes.
No segundo estágio, cinco canais de recuperação rodam em paralelo:
- Busca full-text com Porter stemming — para precisão de palavras-chave quando você sabe o termo exato mas não o contexto ao redor
- Busca exata por chave de fato — retorna resultados onde a consulta mapeia diretamente para uma chave de tópico conhecida
- Busca em mensagens brutas — consulta as mensagens originais da conversa via full-text, funcionando como rede de segurança para detalhes que o pipeline de extração pode ter generalizado
- Busca vetorial direta — encontra memórias semanticamente similares usando o embedding da consulta
- Busca vetorial HyDE — encontra memórias similares ao que a resposta se pareceria, o que frequentemente traz resultados que a busca direta não encontra, especialmente para consultas abstratas ou multi-hop
No terceiro estágio, os resultados de todos os cinco canais são mesclados usando Reciprocal Rank Fusion (RRF), onde cada resultado recebe uma pontuação ponderada baseada na sua posição dentro de cada canal. Correspondências exatas por chave de fato recebem o maior peso. Busca full-text, vetores HyDE e vetores diretos são ponderados de acordo com a força do sinal. Mensagens brutas entram com peso baixo como rede de segurança. Empates são desfeitos por recência, com resultados mais novos ranqueados mais alto.
O pipeline então passa os melhores candidatos para o modelo de síntese, que gera uma resposta em linguagem natural para a consulta original. Alguns tipos específicos de consulta recebem tratamento especial. Computação temporal, por exemplo, é tratada de forma determinística via regex e aritmética, não pelo LLM. Os resultados são injetados no prompt de síntese como fatos pré-computados, já que modelos são notoriamente pouco confiáveis para coisas como cálculos de data. 📊
A infraestrutura por baixo dos panos
A Cloudflare construiu o Agent Memory usando seus próprios produtos, e isso é um ponto interessante. Sob o capô, o serviço é um Cloudflare Worker que coordena vários sistemas:
- Durable Objects — armazena as mensagens brutas e as memórias classificadas, com SQLite como backend, garantindo isolamento forte entre tenants
- Vectorize — fornece busca vetorial sobre memórias embeddadas
- Workers AI — roda os LLMs e modelos de embedding usados no pipeline
Cada contexto de memória mapeia para sua própria instância de Durable Object e índice Vectorize, mantendo dados completamente isolados entre contextos diferentes. Isso também permite escalar facilmente conforme a demanda cresce.
A escolha dos modelos
Um achado interessante do desenvolvimento foi que um modelo maior e mais poderoso nem sempre é melhor. A equipe optou por usar o Llama 4 Scout (17B parâmetros, MoE com 16 experts) para extração, verificação, classificação e análise de consultas, e o Nemotron 3 (120B MoE, 12B parâmetros ativos) para síntese. O Scout lida bem com tarefas de classificação estruturada de forma eficiente, enquanto a maior capacidade de raciocínio do Nemotron melhora a qualidade das respostas em linguagem natural. A síntese foi o único estágio onde jogar mais parâmetros no problema consistentemente ajudou. Para todo o resto, o modelo menor atingiu um equilíbrio superior de custo, qualidade e latência.
O que dá pra construir com isso
O Agent Memory foi projetado para funcionar com uma ampla variedade de arquiteturas de agentes, e os casos de uso são bem diversos:
Memória para agentes individuais. Não importa se você está usando agentes de código como Claude Code ou OpenCode com um humano no loop, frameworks auto-hospedados como OpenClaw ou Hermes agindo em seu nome, ou serviços gerenciados como os Managed Agents da Anthropic. O Agent Memory pode servir como camada de memória persistente sem exigir mudanças no loop central do agente.
Memória para harnesses customizados de agentes. Muitos times estão construindo sua própria infraestrutura de agentes, incluindo agentes de background que rodam autonomamente sem supervisão humana. Empresas como Ramp, Stripe e Spotify já descreveram publicamente sistemas desse tipo. Esses harnesses podem se beneficiar enormemente de memória que persiste entre sessões e sobrevive a reinícios.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Memória compartilhada entre agentes, pessoas e ferramentas. Um perfil de memória não precisa pertencer a um único agente. Um time de engenharia pode compartilhar um perfil para que o conhecimento aprendido pelo agente de código de uma pessoa fique disponível para todos: convenções de código, decisões arquiteturais, conhecimento tribal que normalmente vive apenas na cabeça das pessoas ou se perde quando o contexto é podado. Um bot de code review e um agente de código podem compartilhar memória para que feedback de revisões influencie a geração futura de código. O conhecimento que seus agentes acumulam para de ser efêmero e se torna um ativo durável do time. 🤝
Como a Cloudflare está usando internamente
A equipe já usa o Agent Memory internamente como campo de testes e fonte de ideias para os próximos passos.
No fluxo de agentes de código, eles usam um plugin interno do OpenCode que conecta o Agent Memory ao loop de desenvolvimento. O benefício menos óbvio, mas talvez o mais valioso, foi a memória compartilhada entre o time. Com um perfil compartilhado, o agente sabe o que outros membros do time já aprenderam, o que significa que ele para de fazer perguntas que já foram respondidas e de cometer erros que já foram corrigidos.
Na revisão de código agentica, o resultado mais interessante foi que o revisor aprendeu a ficar quieto. Ele agora lembra que um comentário específico não foi relevante em uma revisão passada, ou que um padrão foi sinalizado e o autor escolheu mantê-lo por um bom motivo. As revisões ficam menos ruidosas ao longo do tempo, não apenas mais inteligentes.
Em chatbots, a memória foi conectada a um bot interno que ingere histórico de mensagens e depois fica observando e lembrando novas mensagens. Quando alguém faz uma pergunta, o bot consegue responder com base em conversas anteriores.
Seus dados são seus
Conforme agentes se tornam mais capazes e mais profundamente integrados a processos de negócio, a memória que eles acumulam se torna genuinamente valiosa. Não apenas como estado operacional, mas como conhecimento institucional que custou trabalho real para ser construído. A Cloudflare reconhece a preocupação crescente de clientes sobre o que significa amarrar esse ativo a um único fornecedor.
O posicionamento é claro: o Agent Memory é um serviço gerenciado, mas os dados pertencem ao cliente. Toda memória é exportável, e a empresa se compromete a garantir que o conhecimento acumulado pelos agentes na plataforma possa sair junto se as necessidades mudarem. A filosofia declarada é que a melhor forma de construir confiança de longo prazo é tornar fácil a saída e continuar construindo algo bom o suficiente para que ninguém queira ir embora.
O que vem por aí
A equipe continua testando e refinando o Agent Memory internamente, melhorando o pipeline de extração, ajustando a qualidade da recuperação e expandindo capacidades de processamento em background. Uma analogia interessante que a própria Cloudflare usa é com o cérebro humano: assim como nosso cérebro consolida memórias durante o sono ao replaying e fortalecer conexões, eles enxergam oportunidades para o armazenamento de memória melhorar de forma assíncrona e já estão implementando e testando várias estratégias nessa direção.
O Agent Memory ainda está em beta privada, então o acesso é limitado por enquanto. Desenvolvedores interessados em acesso antecipado podem entrar na lista de espera diretamente no site da Cloudflare. O lançamento em si já sinaliza uma direção importante para onde o ecossistema de desenvolvimento de agentes está caminhando: menos infraestrutura manual, mais primitivas de alto nível, e uma aposta clara de que memória gerenciada vai ser uma peça tão fundamental quanto banco de dados ou filas de mensagens são hoje para qualquer aplicação séria em produção. 💡
