O próximo salto dos agentes de IA pode ser memória, não inteligência

Essa mudança está deixando de ser promessa e começando a aparecer em infraestrutura
real. Esta semana, durante a Agents Week 2026, a Cloudflare anunciou um conjunto de
primitivas focadas exatamente nesse problema: dar aos agentes uma camada
de memória persistente que sobrevive além de uma única conversa.

O problema que ninguém gosta de admitir

Todo agente de IA que você usa hoje, seja um assistente no seu editor de código, um
chatbot de suporte ou um sistema de automação, sofre do mesmo problema estrutural:
amnésia por design.

Cada vez que uma nova sessão começa, o agente parte do zero. Não sabe quem você é.
Não lembra do que conversou ontem. Não tem ideia do que aprendeu na semana passada.
Se você pediu para ele usar uma determinada biblioteca, adotar um estilo específico
de código ou evitar um padrão que não funciona no seu projeto, precisa repetir tudo
isso toda vez.

Isso é uma consequência direta de como os modelos de linguagem funcionam: eles são,
por natureza, sem estado (stateless). Processam uma entrada, produzem uma saída,
e quando a janela de contexto fecha, tudo vai embora.

O workaround atual é incluir o máximo de contexto possível no prompt inicial:
histórico de conversas, instruções, preferências, documentos relevantes. Mas isso
tem um custo crescente: tokens usados custam dinheiro, aumentam a latência e, no
limite, chegam no teto da janela de contexto.

A solução que estava faltando não é uma janela maior. É memória de verdade.

O que a Cloudflare está construindo

No projeto Project Think, anunciado em 15 de abril de 2026, a Cloudflare apresentou
o que chama de “a próxima geração do Agents SDK”, um conjunto de primitivas voltadas
para agentes de longa duração que precisam persistir, raciocinar e agir ao longo do
tempo, não apenas durante uma única sessão.

A peça central dessa arquitetura é a Session API, que fornece a camada de
memória para agentes construídos na infraestrutura da empresa. Ela gerencia dois tipos
distintos de memória, cada um com um propósito diferente.

O primeiro é a memória de conversa: o histórico de mensagens, chamadas de
ferramentas e resultados que formam o registro de uma sessão. Esse histórico é
armazenado em SQLite, sobrevive à hibernação do agente e fica disponível quando ele
volta ao ar. Não importa se o laptop fechou, se o servidor reiniciou ou se passaram
dias desde a última interação, o agente acorda e encontra tudo lá.

O segundo tipo é a memória de contexto: blocos de informação persistente
injetados no prompt do sistema a cada nova interação. É aqui que mora a identidade do
agente, suas instruções, fatos que ele aprendeu sobre o usuário e bases de conhecimento
relevantes. Esses blocos podem ser de leitura apenas, escrita livre ou vinculados a um
banco de dados vetorial para busca semântica.

O visual que a documentação da Cloudflare apresenta é revelador: o prompt do sistema é
estruturado com seções claras e indicadores de capacidade. Um bloco de memória aparece
assim:

MEMORY (Fatos importantes aprendidos durante a conversa) [45% — 495/1100 tokens] [escrita]

O usuário prefere dark mode.

O projeto usa React e TypeScript.

O destino de deploy é Cloudflare Workers.

Isso não é apenas armazenamento. É uma camada de conhecimento ativa que o agente pode
ler, modificar e usar a cada turno, sem precisar incluir o histórico completo de uma
conversa de três horas só para que ele “lembre” de detalhes básicos.

A virada: de ferramenta para infraestrutura

Existe uma distinção importante que o próprio blog da Cloudflare articula com clareza:
um agente que morre quando você fecha o laptop é uma ferramenta. Um agente que
persiste, que pode ser acordado por uma mensagem, um evento ou um horário agendado, e
que carrega consigo o estado de tudo o que aconteceu antes, essa é a
infraestrutura.

Essa distinção muda completamente a economia de se usar agentes em escala. Em vez de
manter um agente caro e sempre ativo para cada usuário, é possível ter um agente por
cliente, por tarefa, por thread de e-mail. O custo marginal de criar um novo agente cai
a praticamente zero, porque ele hiberna quando não está sendo usado e acorda sob
demanda.

A Cloudflare usa Durable Objects para dar a cada agente uma identidade, um banco de
dados SQLite próprio e capacidade de responder a eventos. Quando algo acontece — uma
requisição HTTP, uma mensagem via WebSocket, um alarme programado, um e-mail recebido,
a plataforma acorda o agente, carrega seu estado e entrega o evento. O agente faz seu
trabalho e volta a dormir.

Memória que evolui com o uso

Mas há algo ainda mais interessante acontecendo. O Project Think também inclui um sistema
chamado ExtensionManager, que permite ao agente escrever novas ferramentas para si
mesmo em tempo de execução.

O fluxo funciona assim: o usuário pede ao agente algo que ele ainda não sabe fazer,
digamos, criar um pull request no GitHub. O agente reconhece a lacuna, escreve o código
de uma nova ferramenta, carrega esse código em um ambiente isolado (um Dynamic Worker) e
registra a nova capacidade. Da próxima vez que a tarefa aparecer, a ferramenta já está
disponível e persiste no armazenamento do Durable Object.

É um loop de autoaperfeiçoamento. Não via fine-tuning ou retreinamento, mas por código.
O agente expande suas próprias capacidades, em TypeScript auditável e revogável, dentro
de um sandbox seguro.

Por que isso importa para quem não é desenvolvedor de infraestrutura

É fácil ler sobre Durable Objects e SQLite e pensar que isso é assunto de plataforma,
relevante para quem constrói o agente, mas não para quem usa.

Mas o impacto é mais imediato do que parece. Quando agentes com memória real começam a
chegar a produtos, algumas coisas mudam na experiência do usuário:

Onboarding some. Você não precisa mais explicar suas preferências toda vez que abre
uma nova sessão. O agente sabe onde você mora no ecossistema de ferramentas que usa.

Tarefas longas se tornam viáveis. Hoje, pedir para um agente executar um projeto que
vai levar horas ou dias é impraticável, ele vai “esquecer” o que estava fazendo. Com
memória persistente e execução durável, tarefas de longa duração se tornam um caso de
uso legítimo.

Personalização real, não só configuração. O agente aprende com o padrão das suas
interações. Se você sempre rejeita um certo tipo de sugestão, ele para de fazê-la, não
porque foi programado para isso, mas porque registrou o feedback.

Custo cai. Memória bem gerenciada significa menos tokens por requisição. Em vez de
carregar 50 páginas de histórico toda vez, o agente busca apenas o que é relevante para a
tarefa atual.

Conclusão

Ainda estamos no início. A Session API da Cloudflare está em desenvolvimento ativo, e
vários dos recursos mais sofisticados, como busca vetorial na memória de contexto e
compactação inteligente do histórico, chegam em versões futuras.

Mas o sinal é claro. A infraestrutura para agentes com memória está sendo construída
agora, por algumas das maiores empresas de plataforma do mundo, com urgência e foco que
não existiam há um ano.

A pergunta que vale fazer não é mais “os agentes vão ter memória?” — a resposta é sim,
e está acontecendo. A pergunta é: quando a memória virar padrão, quais categorias de
software vão existir que hoje simplesmente não existem?

Essa é a pergunta que os builders mais interessantes estão respondendo agora.