El gerente de producto de IA senior de Google, Shubham Saboo, ha convertido uno de los problemas más espinosos en el diseño de agentes en un ejercicio de ingeniería de código abierto: la memoria persistente.
Esta semana, publicó un “Always On Memory Agent” de código abierto en la página oficial de Github de Google Cloud Platform bajo una licencia MIT permisiva, lo que permite su uso comercial.
Fue construido con el Agent Development Kit (ADK) de Google, introducido la primavera de 2025, y Gemini 3.1 Flash-Lite, un modelo de bajo costo que Google introdujo el 3 de marzo de 2026 como el modelo más rápido y eficiente de la serie Gemini 3.
El proyecto sirve como una implementación de referencia práctica para algo que muchos equipos de IA desean, pero pocos han logrado implementar de manera limpia en producción: un sistema de agentes que pueda ingerir información continuamente, consolidarla en segundo plano y recuperarla más tarde sin depender de una base de datos vectorial convencional.
Para los desarrolladores empresariales, el lanzamiento importa menos como un lanzamiento de producto que como una señal de hacia dónde se dirige la infraestructura de agentes.
El repositorio ofrece una visión de la autonomía a largo plazo que es cada vez más atractiva para sistemas de soporte, asistentes de investigación, copilotos internos y automatización de flujos de trabajo. También pone en un enfoque más nítido las cuestiones de gobernanza tan pronto como la memoria deja de estar ligada a la sesión.
Lo que parece hacer el repositorio — y lo que no afirma claramente
El repositorio también parece utilizar una arquitectura interna multiagente, con componentes especializados que se encargan de la ingestión, la consolidación y la consulta.
Sin embargo, los materiales proporcionados no establecen claramente una afirmación más amplia de que se trata de un marco de memoria compartida para múltiples agentes independientes.
Esta distinción es importante. ADK como marco admite sistemas multiagente, pero este repositorio específico se describe mejor como un agente de memoria siempre activo, o capa de memoria, construido con subagentes especializados y almacenamiento persistente.
Incluso a este nivel más estrecho, aborda un problema central de infraestructura con el que muchos equipos están trabajando activamente.
La arquitectura favorece la simplicidad sobre una pila de recuperación tradicional
Según el repositorio, el agente se ejecuta continuamente, ingiere archivos o entradas de API, almacena memorias estructuradas en SQLite y realiza una consolidación de memoria programada cada 30 minutos de forma predeterminada.
Se incluye una API HTTP local y un panel Streamlit, y el sistema admite la ingestión de texto, imágenes, audio, video y PDF. El repositorio enmarca el diseño con una afirmación intencionalmente provocativa: “No hay base de datos vectorial. No hay incrustaciones. Solo un LLM que lee, piensa y escribe memoria estructurada”.
Esta elección de diseño probablemente llamará la atención de los desarrolladores que gestionan el costo y la complejidad operativa. Las pilas de recuperación tradicionales a menudo requieren canalizaciones de incrustación separadas, almacenamiento vectorial, lógica de indexación y trabajo de sincronización.
El ejemplo de Saboo, en cambio, se basa en el modelo para organizar y actualizar la memoria directamente. En la práctica, esto puede simplificar los prototipos y reducir la proliferación de infraestructura, especialmente para agentes de memoria pequeños o medianos. También desplaza la cuestión del rendimiento de la sobrecarga de la búsqueda vectorial a la latencia del modelo, la lógica de compactación de la memoria y la estabilidad del comportamiento a largo plazo.
Flash-Lite le da lógica económica al modelo siempre activo
Aquí es donde entra en juego Gemini 3.1 Flash-Lite.
Google dice que el modelo está diseñado para cargas de trabajo de desarrolladores de gran volumen y se ofrece a un precio de $0.25 por 1 millón de tokens de entrada y $1.50 por 1 millón de tokens de salida.
La compañía también dice que Flash-Lite es 2.5 veces más rápido que Gemini 2.5 Flash en el tiempo hasta el primer token y ofrece un aumento del 45% en la velocidad de salida manteniendo una calidad similar o mejor.
En las pruebas comparativas publicadas por Google, el modelo obtiene una puntuación Elo de 1432 en Arena.ai, 86.9% en GPQA Diamond y 76.8% en MMMU Pro. Google posiciona estas características como adecuadas para tareas de alta frecuencia como la traducción, la moderación, la generación de UI y la simulación.
Estos números ayudan a explicar por qué Flash-Lite se combina con un agente de memoria de fondo. Un servicio 24/7 que periódicamente vuelve a leer, consolida y sirve memoria necesita una latencia predecible y un costo de inferencia lo suficientemente bajo como para evitar que “siempre activo” sea prohibitivamente caro.
La documentación de ADK de Google refuerza la historia más amplia. El marco se presenta como agnóstico del modelo y agnóstico del despliegue, con soporte para agentes de flujo de trabajo, sistemas multiagente, herramientas, evaluación y destinos de despliegue que incluyen Cloud Run y Vertex AI Agent Engine. Esa combinación hace que el agente de memoria se sienta menos como una demostración única y más como un punto de referencia para una estrategia de tiempo de ejecución de agentes más amplia.
El debate empresarial se centra en la gobernanza, no solo en la capacidad
La reacción pública muestra por qué la adopción empresarial de la memoria persistente no dependerá únicamente de la velocidad o el precio de los tokens.
Varias respuestas en X destacaron exactamente las preocupaciones que probablemente plantearán los arquitectos empresariales. Franck Abe calificó a Google ADK y la consolidación de memoria 24/7 como “brillantes avances para la autonomía continua del agente”, pero advirtió que un agente “soñando” y cruzando memorias en segundo plano sin límites deterministas se convierte en “una pesadilla de cumplimiento”.
ELED argumentó en la misma línea, afirmando que el costo principal de los agentes siempre activos no son los tokens, sino “la deriva y los bucles”.
Estas críticas se dirigen directamente a la carga operativa de los sistemas persistentes: ¿quién puede escribir memoria, qué se fusiona, cómo funciona la retención, cuándo se eliminan las memorias y cómo los equipos auditan lo que el agente aprendió con el tiempo?
Otra reacción, de Iffy, desafió la formulación “sin incrustaciones” del repositorio, argumentando que el sistema aún tiene que fragmentar, indexar y recuperar memoria estructurada, y que puede funcionar bien para agentes de pequeño contexto, pero fallar una vez que los almacenes de memoria se vuelven mucho más grandes.
Esta crítica es técnicamente importante. Eliminar una base de datos vectorial no elimina el diseño de recuperación. cambia dónde reside la complejidad.
Para los desarrolladores, el intercambio es menos sobre ideología que sobre ajuste. Una pila más ligera puede ser atractiva para agentes de memoria limitada y de bajo costo, mientras que las implementaciones a mayor escala aún pueden exigir controles de recuperación más estrictos, estrategias de indexación más explícitas y herramientas de ciclo de vida más sólidas.
ADK amplía la historia más allá de una sola demostración
Otros comentaristas se centraron en el flujo de trabajo del desarrollador. Uno preguntó por el repositorio y la documentación de ADK y quiso saber si el tiempo de ejecución es sin servidor o de larga duración, y si las llamadas a herramientas y los ganchos de evaluación están disponibles de forma predeterminada.
Según los materiales proporcionados, la respuesta es efectivamente ambas: el ejemplo del agente de memoria en sí está estructurado como un servicio de larga duración, mientras que ADK admite más ampliamente múltiples patrones de despliegue e incluye herramientas y capacidades de evaluación.
El agente de memoria siempre activo es interesante por sí solo, pero el mensaje más amplio es que Saboo está tratando de hacer que los agentes se sientan como sistemas de software implementables en lugar de indicaciones aisladas. En ese marco, la memoria se convierte en parte de la capa de tiempo de ejecución, no solo en una función adicional.
Lo que Saboo ha mostrado — y lo que no
Lo que Saboo aún no ha mostrado es tan importante como lo que ha publicado.
Los materiales proporcionados no incluyen una prueba comparativa directa de Flash-Lite versus Anthropic Claude Haiku para bucles de agentes en uso de producción.
Tampoco establecen controles de cumplimiento de nivel empresarial específicos para este agente de memoria, como límites de política deterministas, garantías de retención, reglas de segregación o flujos de trabajo de auditoría formales.
Y, si bien el repositorio parece utilizar múltiples agentes especializados internamente, los materiales no demuestran claramente una afirmación más amplia sobre la memoria persistente compartida entre múltiples agentes independientes.
Por ahora, el repositorio se lee como una plantilla de ingeniería convincente en lugar de una plataforma de memoria empresarial completa.
Por qué esto es importante ahora
Aún así, el lanzamiento llega en el momento adecuado. Los equipos de IA empresariales están pasando de los asistentes de un solo turno a los sistemas que se espera que recuerden las preferencias, conserven el contexto del proyecto y operen en horizontes más amplios.
El agente de memoria de código abierto de Saboo ofrece un punto de partida concreto para esa siguiente capa de infraestructura, y Flash-Lite le da credibilidad a la economía.
Pero la conclusión más importante de la reacción ante el lanzamiento es que la memoria continua se juzgará por la gobernanza tanto como por la capacidad.
Esa es la verdadera pregunta empresarial detrás de la demostración de Saboo: no si un agente puede recordar, sino si puede recordar de manera que se mantenga limitada, inspeccionable y lo suficientemente segura como para confiar en ella en producción.
