Gerente sênior de produtos de IA do Google Shubham Saboo transformou um dos problemas mais espinhosos no design de agentes em um exercício de engenharia de código aberto: memória persistente.
Esta semana, ele publicou um código aberto “Always On Memory Agent” no Github oficial do Google Cloud Platform página sob uma licença permissiva do MIT, permitindo uso comercial.
Ele foi construído com o Agent Development Kit do Google, ou ADK, lançado na primavera passada em 2025, e Gemini 3.1 Flash-Lite, um modelo de baixo custo que o Google lançou em 3 de março de 2026 como seu modelo da série Gemini 3 mais rápido e econômico.
O projeto serve como uma implementação de referência prática para algo que muitas equipes de IA desejam, mas poucas produziram de forma limpa: um sistema de agente que pode ingerir informações continuamente, consolidá-las em segundo plano e recuperá-las posteriormente, sem depender de um banco de dados vetorial convencional.
Para os desenvolvedores corporativos, o lançamento importa menos como um lançamento de produto do que como um sinal sobre o rumo que a infraestrutura do agente está tomando.
O repo traz uma visão de autonomia de longo prazo que é cada vez mais atraente para sistemas de suporte, assistentes de pesquisa, copilotos internos e automação de fluxo de trabalho. Também traz um foco mais nítido às questões de governança assim que a memória deixa de estar vinculada à sessão.
O que o repo parece fazer – e o que não afirma claramente
O repositório também parece usar uma arquitetura interna multiagente, com componentes especializados que lidam com ingestão, consolidação e consulta.
Mas os materiais fornecidos não estabelecem claramente uma afirmação mais ampla de que esta é uma estrutura de memória compartilhada para múltiplos agentes independentes.
Essa distinção é importante. O ADK como estrutura suporta sistemas multiagentes, mas este repositório específico é melhor descrito como um agente de memória sempre ativo, ou camada de memória, construído com subagentes especializados e armazenamento persistente.
Mesmo nesse nível mais restrito, ele aborda um problema central de infraestrutura no qual muitas equipes estão trabalhando ativamente.
A arquitetura favorece a simplicidade em relação a uma pilha de recuperação tradicional
De acordo com o repositório, o agente é executado continuamente, ingere arquivos ou entrada de API, armazena memórias estruturadas em SQLite e realiza consolidação de memória agendada a cada 30 minutos por padrão.
Uma API HTTP local e um painel Streamlit estão incluídos, e o sistema suporta ingestão de texto, imagem, áudio, vídeo e PDF. O repositório enquadra o design com uma afirmação intencionalmente provocativa: “Sem banco de dados de vetores. Sem incorporações. Apenas um LLM que lê, pensa e escreve memória estruturada”.
Essa escolha de design provavelmente chamará a atenção dos desenvolvedores que gerenciam custos e complexidade operacional. As pilhas de recuperação tradicionais geralmente exigem pipelines de incorporação separados, armazenamento de vetores, lógica de indexação e trabalho de sincronização.
O exemplo de Saboo, em vez disso, baseia-se no modelo para organizar e atualizar a memória diretamente. Na prática, isso pode simplificar protótipos e reduzir a expansão da infraestrutura, especialmente para agentes com memória pequena ou média. Ele também muda a questão do desempenho da sobrecarga de pesquisa vetorial para a latência do modelo, lógica de compactação de memória e estabilidade comportamental de longo prazo.
Flash-Lite dá ao modelo sempre ligado alguma lógica econômica
É aí que o Gemini 3.1 Flash-Lite entra na história.
O Google afirma que o modelo foi desenvolvido para cargas de trabalho de desenvolvedor de alto volume em escala e custa US$ 0,25 por 1 milhão de tokens de entrada e US$ 1,50 por 1 milhão de tokens de saída.
A empresa também afirma que o Flash-Lite é 2,5 vezes mais rápido que o Gemini 2.5 Flash no tempo para o primeiro token e oferece um aumento de 45% na velocidade de saída, mantendo qualidade semelhante ou melhor.
Nos benchmarks publicados pelo Google, o modelo registra uma pontuação Elo de 1.432 no Arena.ai, 86,9% no GPQA Diamond e 76,8% no MMMU Pro. O Google posiciona essas características como adequadas para tarefas de alta frequência, como tradução, moderação, geração de UI e simulação.
Esses números ajudam a explicar por que o Flash-Lite está emparelhado com um agente de memória de segundo plano. Um serviço 24 horas por dia, 7 dias por semana, que periodicamente relê, consolida e fornece memória precisa de latência previsível e custo de inferência baixo o suficiente para evitar tornar o “sempre ligado” proibitivamente caro.
A documentação do ADK do Google reforça a história mais ampla. A estrutura é apresentada como independente de modelo e de implantação, com suporte para agentes de fluxo de trabalho, sistemas multiagentes, ferramentas, alvos de avaliação e implantação, incluindo Cloud Run e Vertex AI Agent Engine. Essa combinação faz com que o agente de memória pareça menos uma demonstração única e mais um ponto de referência para uma estratégia mais ampla de tempo de execução do agente.
O debate empresarial é sobre governança, não apenas sobre capacidade
A reação do público mostra por que a adoção empresarial da memória persistente não dependerá apenas da velocidade ou do preço dos tokens.
Várias respostas sobre X destacaram exatamente as preocupações que os arquitetos corporativos provavelmente levantarão. Frank Abe chamou o Google ADK e a consolidação de memória 24 horas por dia, 7 dias por semana, de “saltos brilhantes para a autonomia contínua do agente”, mas alertou que um agente “sonhando” e polinizando memórias cruzadas em segundo plano sem limites determinísticos se torna “um pesadelo de conformidade”.
ELED fez uma observação relacionada, argumentando que o principal custo dos agentes sempre ativos não são os tokens, mas “desvios e loops”.
Essas críticas vão diretamente para a carga operacional dos sistemas persistentes: quem pode escrever na memória, o que é mesclado, como funciona a retenção, quando as memórias são excluídas e como as equipes auditam o que o agente aprendeu ao longo do tempo?
Outra reação, de Duvidosodesafiou o enquadramento “sem incorporação” do repositório, argumentando que o sistema ainda precisa fragmentar, indexar e recuperar memória estruturada e que pode funcionar bem para agentes de contexto pequeno, mas falha quando os armazenamentos de memória se tornam muito maiores.
Essa crítica é tecnicamente importante. A remoção de um banco de dados vetorial não remove o design de recuperação; muda onde mora a complexidade.
Para os desenvolvedores, a compensação tem menos a ver com ideologia do que com adequação. Uma pilha mais leve pode ser atraente para agentes de memória limitada e de baixo custo, enquanto implantações em maior escala ainda podem exigir controles de recuperação mais rígidos, estratégias de indexação mais explícitas e ferramentas de ciclo de vida mais fortes.
ADK amplia a história além de uma única demonstração
Outros comentaristas focaram no fluxo de trabalho do desenvolvedor. Um solicitou o repositório e a documentação do ADK e queria saber se o tempo de execução não tem servidor ou é de longa duração e se os ganchos de chamada de ferramenta e avaliação estão disponíveis imediatamente.
Com base nos materiais fornecidos, a resposta é efetivamente ambas: o próprio exemplo do agente de memória é estruturado como um serviço de longa execução, enquanto o ADK oferece suporte mais amplo a vários padrões de implantação e inclui ferramentas e recursos de avaliação.
O agente de memória sempre ativa é interessante por si só, mas a mensagem maior é que Saboo está tentando fazer com que os agentes pareçam sistemas de software implementáveis, em vez de prompts isolados. Nesse enquadramento, a memória torna-se parte da camada de tempo de execução, não apenas um recurso complementar.
O que Saboo mostrou – e o que ele não mostrou
O que Saboo ainda não mostrou é tão importante quanto o que publicou.
Os materiais fornecidos não incluem um benchmark direto do Flash-Lite versus Anthropic Claude Haiku para loops de agentes em uso em produção.
Eles também não estabelecem controles de conformidade de nível empresarial específicos para esse agente de memória, como: limites de políticas determinísticas, garantias de retenção, regras de segregação ou fluxos de trabalho formais de auditoria.
E embora o repositório pareça usar vários agentes especializados internamente, os materiais não provam claramente uma afirmação maior sobre a memória persistente compartilhada entre vários agentes independentes.
Por enquanto, o repositório parece um modelo de engenharia atraente, em vez de uma plataforma completa de memória corporativa.
Por que isso é importante agora
Ainda assim, o lançamento chega na hora certa. As equipes de IA empresarial estão indo além dos assistentes de turno único e entrando em sistemas que devem lembrar preferências, preservar o contexto do projeto e operar em horizontes mais longos.
O agente de memória de código aberto da Saboo oferece um ponto de partida concreto para a próxima camada de infraestrutura, e o Flash-Lite dá alguma credibilidade à economia.
Mas a conclusão mais forte da reacção em torno do lançamento é que a memória contínua será avaliada tanto pela governação como pela capacidade.
Essa é a verdadeira questão empresarial por trás da demonstração de Saboo: não se um agente consegue se lembrar, mas se ele consegue se lembrar de maneiras que permaneçam limitadas, inspecionáveis e seguras o suficiente para confiar na produção.
