Gerente senior de productos de IA en Google Shubham Saboo convirtió 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 código abierto “Agente Always On Memory” en el Github oficial de Google Cloud Platform página bajo una licencia permisiva del MIT, que permite el uso comercial.
Fue construido con Kit de desarrollo de agentes de Google o ADK introducido la primavera pasada de 2025, y Géminis 3.1 Flash-Lite, un modelo de bajo coste que Google lanzó el 3 de marzo de 2026 como su modelo de la serie Gemini 3 más rápido y económico.
El proyecto sirve como una implementación de referencia práctica para algo que muchos equipos de IA quieren pero pocos han producido de manera limpia: un sistema de agente 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 lanzamiento de producto que como señal sobre hacia dónde se dirige la infraestructura del agente.
Repo aporta una visión de autonomía a largo plazo que resulta cada vez más atractiva para sistemas de soporte, asistentes de investigación, copilotos internos y automatización del flujo de trabajo. También pone de relieve las cuestiones de gobernanza una vez que la memoria ya no está ligada a la sesión.
Lo que parece hacer el repositorio y lo que no indica claramente
El repositorio también parece utilizar una arquitectura interna de múltiples agentes, con componentes especializados que manejan la ingesta, la consolidación y las consultas.
Pero los materiales proporcionados no establecen claramente una afirmación más amplia de que se trata de una estructura de memoria compartida para múltiples agentes independientes.
Esta distinción es importante. ADK como marco admite sistemas multiagente, pero este repositorio en particular se describe mejor como un agente de memoria siempre activo, o capa de memoria, construido con subagentes especializados y almacenamiento persistente.
Incluso en este nivel más limitado, aborda un problema central de infraestructura en el que muchos equipos están trabajando activamente.
La arquitectura favorece la simplicidad frente a una pila de recuperación tradicional.
Según el repositorio, el agente se ejecuta continuamente, ingiere archivos o entradas de API, almacena memoria estructurada en SQLite y realiza una consolidación de memoria programada cada 30 minutos de forma predeterminada.
Se incluyen una API HTTP local y un panel Streamlit, y el sistema admite la ingesta de texto, imágenes, audio, video y PDF. El repositorio enmarca el diseño con una declaración intencionalmente provocativa: “Sin base de datos vectorial. Sin incrustaciones. Sólo 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 la complejidad y los costos operativos. Las pilas de recuperación tradicionales normalmente requieren canalizaciones de incorporación independientes, almacenamiento vectorial, lógica de indexación y trabajo de sincronización.
En cambio, el ejemplo de Saboo se basa en el modelo para organizar y actualizar la memoria directamente. En la práctica, esto puede simplificar la creación de prototipos y reducir la expansión de la infraestructura, especialmente para agentes con memoria pequeña o mediana. También traslada la cuestión del rendimiento de la sobrecarga de búsqueda vectorial a la latencia del modelo, la lógica de compresión de la memoria y la estabilidad del comportamiento a largo plazo.
Flash-Lite le da al modelo siempre activo cierta lógica económica
Ahí es donde entra en juego el Gemini 3.1 Flash-Lite.
Google dice que el modelo está diseñado para cargas de trabajo de desarrolladores de gran volumen a escala y cuesta 0,25 dólares por 1 millón de tokens de entrada y 1,50 dólares por 1 millón de tokens de salida.
La compañía también afirma que Flash-Lite es 2,5 veces más rápido que Gemini 2.5 Flash en tiempo hasta el primer token y ofrece un aumento del 45% en la velocidad de salida manteniendo una calidad similar o mejor.
En los puntos de referencia publicados por Google, el modelo registra una puntuación Elo de 1.432 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 traducción, moderación, generación de UI y simulación.
Estos números ayudan a explicar por qué Flash-Lite está emparejado con un intermediario de memoria en segundo plano. Un servicio 24 horas al día, 7 días a la semana que relee, consolida y entrega periódicamente memoria precisa con latencia predecible y un costo de inferencia lo suficientemente bajo como para evitar que “siempre activo” sea prohibitivamente costoso.
La documentación ADK de Google refuerza la historia más amplia. El marco se presenta como independiente del modelo y de la implementación, con soporte para agentes de flujo de trabajo, sistemas multiagente, herramientas, objetivos de evaluación e implementación, incluidos Cloud Run y Vertex AI Agent Engine. Esta 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 del agente más amplia.
El debate empresarial gira en torno a la gobernanza, no sólo a la capacidad
La reacción del público muestra por qué la adopción empresarial de la memoria persistente no dependerá sólo de la velocidad o el precio de los tokens.
Varias respuestas sobre X han resaltado exactamente las preocupaciones que probablemente plantearán los arquitectos empresariales. franco abe calificó a Google ADK y la consolidación de memoria 24 horas al día, 7 días a la semana como “saltos brillantes para una autonomía continua del agente”, pero advirtió que un agente “soñando” y polinizando recuerdos en segundo plano sin límites deterministas se convierte en “una pesadilla de cumplimiento”.
ELED hizo un comentario relacionado, argumentando que el costo principal de los agentes siempre activos no son los tokens, sino los “desvíos y bucles”.
Estas críticas van directamente a la carga operativa de los sistemas persistentes: ¿quién puede escribir en la memoria, qué se fusiona, cómo funciona la retención, cuándo se eliminan los recuerdos y cómo auditan los equipos lo que el agente ha aprendido con el tiempo?
Otra reacción, Dudosocuestionó el marco “sin incorporación” del repositorio, argumentando que el sistema aún necesita fragmentar, indexar y recuperar la memoria estructurada y que puede funcionar bien para agentes de contexto pequeño, pero falla cuando 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 donde vive la complejidad.
Para los desarrolladores, la compensación tiene menos que ver con la ideología que con la idoneidad. Una pila más liviana puede resultar atractiva para agentes de bajo costo y con memoria limitada, mientras que las implementaciones a mayor escala aún pueden requerir 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 extiende la historia más allá de una sola demostración
Otros comentaristas se centraron en el flujo de trabajo del desarrollador. Uno solicitó el repositorio y la documentación de ADK y quería saber si el tiempo de ejecución no tiene servidor o es de larga duración y si los enlaces de invocación y evaluación de la herramienta están disponibles de fábrica.
Según los materiales proporcionados, la respuesta es efectivamente ambas: la muestra del agente de memoria en sí está estructurada como un servicio de larga duración, mientras que el ADK admite más ampliamente múltiples patrones de implementación e incluye herramientas y capacidades de evaluación.
El agente de memoria siempre activo es interesante por derecho propio, pero el mensaje más importante es que Saboo está tratando de hacer que los agentes se sientan como sistemas de software desplegables en lugar de indicaciones aisladas. En este marco, la memoria se convierte en parte de la capa de tiempo de ejecución, no sólo en un recurso complementario.
Lo que Saboo mostró y lo que no mostró
Tan importante es lo que Saboo aún no ha mostrado como lo que ha publicado.
Los materiales proporcionados no incluyen una comparación directa de Flash-Lite versus Anthropic Claude Haiku para bucles de agentes en uso de producción.
Tampoco establecen controles de cumplimiento a nivel empresarial específicos para este agente de memoria, como: límites de políticas deterministas, garantías de retención, reglas de segregación o flujos de trabajo de auditoría formales.
Y aunque el repositorio parece utilizar varios agentes especializados internamente, los materiales no prueban claramente una afirmación más amplia sobre la memoria persistente compartida entre múltiples agentes independientes.
Por ahora, el repositorio parece un modelo de ingeniería atractivo en lugar de una plataforma de memoria empresarial completa.
Por qué esto importa ahora
Aun así, el lanzamiento llega en el momento adecuado. Los equipos de IA empresarial están yendo más allá de los asistentes de un solo turno y hacia sistemas que deben recordar preferencias, preservar el contexto del proyecto y operar en horizontes más largos.
El agente de memoria de código abierto de Saboo ofrece un punto de partida concreto para la siguiente capa de infraestructura, y Flash-Lite le da cierta credibilidad a la economía.
Pero la conclusión más importante de la reacción en torno al lanzamiento es que la continuidad de la memoria se medirá tanto por la gobernanza 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 siga siendo limitada, inspeccionable y lo suficientemente segura como para confiar en la producción.
