Agentes que recuerdan: Cloudflare lanza Agent Memory para dar memoria persistente a agentes de IA
🧠 Memoria es una de las palabras más simples del diccionario, pero cuando hablamos de agentes de inteligencia artificial, se convierte en uno de los desafíos más complejos de la ingeniería moderna.
Piénsalo así: ¿de qué sirve un agente de IA increíblemente capaz si olvida todo lo que aprendió en cuanto la conversación termina? Lo entrenas, ajustas, configuras comportamientos, defines personalidad, y en la siguiente sesión el agente actúa como si nunca te hubiera visto antes. Es frustrante para el usuario y es un problema real para cualquier producto que dependa de continuidad y contexto acumulado a lo largo del tiempo.
Ese es exactamente el problema que Cloudflare decidió enfrentar de lleno con el lanzamiento de Agent Memory, ahora en beta privada. El servicio es una solución gestionada que extrae información de conversaciones de agentes y la pone a disposición en el momento adecuado, sin necesidad de meter todo dentro de la ventana de contexto de una sola vez. Pero antes de entrar en los detalles técnicos de cómo funciona en la práctica, vale la pena entender por qué esto importa tanto ahora.
Incluso con ventanas de contexto llegando a 1 millón de tokens, un fenómeno llamado context rot sigue atormentando a los desarrolladores que trabajan con agentes más sofisticados. Cuanta más información metes dentro del contexto, peor se vuelve la calidad de las respuestas del modelo. Es una tensión clásica: mantener todo y ver cómo el rendimiento cae, o podar agresivamente y correr el riesgo de perder exactamente lo que el agente va a necesitar después. Agent Memory llega proponiendo un camino diferente, con una API bien definida, arquitectura basada en recuperación y un conjunto de operaciones pensadas para el ciclo de vida real de un agente en producción. 🚀
El problema real con el contexto en agentes de IA
Cuando hablamos de agentes de inteligencia artificial en producción, el contexto no es solo un detalle técnico. Es la columna vertebral de cualquier interacción que necesite tener sentido a lo largo del tiempo. Un agente que ayuda a un usuario a planificar proyectos, gestionar tareas o tomar decisiones complejas necesita, necesariamente, recordar lo que se dijo antes, lo que se decidió, qué preferencias se expresaron y cómo las cosas evolucionaron desde el comienzo de la conversación. Sin eso, cada sesión empieza desde cero, y el usuario queda atrapado en un bucle eterno de reexplicaciones que desgastan cualquier experiencia.
El desafío se vuelve aún más agudo cuando consideras que los modelos de lenguaje a gran escala, los famosos LLMs, no tienen memoria persistente por naturaleza. Procesan lo que está en la ventana de contexto en el momento de la inferencia y listo. Todo lo que quedó fuera simplemente no existe para el modelo. Esta limitación arquitectónica generó una carrera entre los laboratorios de IA para aumentar cada vez más el tamaño de la ventana de contexto, llegando hoy a modelos capaces de procesar hasta un millón de tokens de una vez. Parece mucho, y lo es. Pero eso no resuelve el problema tan elegantemente como parece a primera vista.
El context rot es exactamente eso: la degradación progresiva de la calidad de las respuestas conforme el contexto crece demasiado. Investigaciones como LongMemEval, LoCoMo y BEAM ayudan a medir este fenómeno, y experimentos prácticos muestran que los modelos tienden a prestar menos atención a información que está en el medio de un contexto muy largo, favoreciendo lo que aparece al principio y al final. Entonces, aunque técnicamente quepa todo dentro de la ventana, el modelo puede simplemente ignorar o subponderar información crítica que está enterrada en medio de miles de tokens. Para agentes que operan en conversaciones largas y complejas, esto es un riesgo real que compromete directamente la utilidad del sistema.
El panorama actual de memoria para agentes
Memoria para agentes es una de las áreas que más se mueve dentro de la infraestructura de IA en este momento. Nuevas bibliotecas open-source, servicios gestionados y prototipos de investigación surgen casi semanalmente, cada uno con enfoques diferentes sobre qué almacenar, cómo recuperar información y para qué tipos de agentes fueron diseñados.
Las diferencias de arquitectura entre estas soluciones son significativas. Algunas son servicios gestionados que se encargan de la extracción y la recuperación en segundo plano. Otras son frameworks auto-hospedados donde el desarrollador necesita operar todo el pipeline de memoria por su cuenta. Algunas exponen APIs limitadas y con propósito específico, manteniendo la lógica de memoria fuera del contexto principal del agente. Otras dan al modelo acceso directo a una base de datos o sistema de archivos y dejan que él mismo construya sus consultas, lo que termina quemando tokens con estrategia de almacenamiento y recuperación en vez de enfocarse en la tarea real.
Hay también soluciones que intentan meter todo dentro de la ventana de contexto, distribuyendo la carga entre múltiples agentes cuando es necesario, mientras otras usan recuperación para traer a la superficie solo lo que es relevante para ese momento. Cada enfoque tiene sus méritos, pero Cloudflare hizo una elección deliberada al posicionar Agent Memory como un servicio gestionado con una API bien definida y arquitectura basada en recuperación, argumentando que pipelines de ingestión y recuperación más controlados son superiores a dar al agente acceso directo al sistema de archivos.
Cómo funciona Agent Memory de Cloudflare en la práctica
El enfoque de Cloudflare con Agent Memory es bastante directo: en vez de intentar resolver el problema de contexto metiendo más tokens dentro del modelo, el servicio propone una capa intermedia inteligente que gestiona qué entra en el contexto y cuándo eso sucede. La idea central es que no toda la información necesita estar presente todo el tiempo. Lo que un agente necesita es tener acceso a la información correcta, en el momento correcto, de forma eficiente y sin desperdicio de tokens.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Agent Memory organiza memorias dentro de un concepto llamado perfil, que se direcciona por nombre. Un perfil ofrece varias operaciones al desarrollador:
- Ingest — la vía principal de ingestión masiva, llamada típicamente cuando el harness del agente compacta el contexto
- Remember — permite que el modelo almacene algo importante en el momento, de forma explícita
- Recall — ejecuta el pipeline completo de recuperación y devuelve una respuesta sintetizada
- List — lista las memorias almacenadas
- Forget — marca una memoria específica como ya no relevante o verdadera
En la práctica, esto significa que el agente ya no necesita hacer la gestión manual de qué recordar y qué olvidar. Esa lógica se delega a la capa de memoria, que usa recuperación basada en similitud semántica para traer a la superficie lo que es más relevante para el momento actual de la conversación. Si un usuario retoma un tema que se discutió semanas atrás, el agente consigue recuperar ese contexto de forma natural, sin que el desarrollador necesite implementar manualmente toda esa lógica de búsqueda, indexación y ranking.
Agent Memory puede accederse vía binding desde cualquier Cloudflare Worker o vía API REST para agentes que corren fuera del entorno Workers. Quien ya usa el Cloudflare Agents SDK encuentra una integración nativa, ya que el servicio funciona como implementación de referencia para la parte de memoria de la Sessions API. 🔧
El pipeline de ingestión por dentro
La ingestión de memoria es donde reside gran parte de la complejidad que Agent Memory abstrae para el desarrollador. Cuando una conversación llega para ser procesada, pasa por un pipeline de múltiples etapas que extrae, verifica, clasifica y almacena las memorias.
El primer paso es la generación determinística de IDs. Cada mensaje recibe un ID basado en contenido, un hash SHA-256 del ID de sesión, del rol (role) y del contenido, truncado a 128 bits. Si la misma conversación se ingesta dos veces, cada mensaje resuelve al mismo ID, haciendo la reingestión idempotente. Esto evita duplicados y garantiza consistencia.
A continuación, el extractor ejecuta dos pasadas en paralelo. Una pasada completa divide los mensajes en bloques de aproximadamente 10 mil caracteres, con solapamiento de dos mensajes, procesando hasta cuatro bloques de forma concurrente. Cada bloque recibe un transcrito estructurado con etiquetas de rol, fechas relativas resueltas a absolutas (por ejemplo, ayer se convierte en 2026-04-14) e índices de línea para trazabilidad. Para conversaciones más largas con nueve o más mensajes, una pasada de detalle corre en paralelo, usando ventanas solapadas enfocadas específicamente en extraer valores concretos como nombres, precios, números de versión y atributos de entidades que la extracción más amplia tiende a generalizar o perder.
El siguiente paso es la verificación. Cada memoria extraída se confronta contra el transcrito original de la conversación. El verificador ejecuta ocho chequeos que cubren identidad de entidad, identidad de objeto, contexto de ubicación, precisión temporal, contexto organizacional, completitud, contexto relacional y si hechos inferidos están efectivamente respaldados por la conversación. Cada ítem es aprobado, corregido o descartado.
Clasificación en cuatro tipos de memoria
Después de la verificación, el pipeline clasifica cada memoria verificada en uno de los cuatro tipos:
- Hechos — representan lo que es verdadero ahora, conocimiento atómico y estable como el proyecto usa GraphQL o el usuario prefiere dark mode
- Eventos — capturan lo que sucedió en un momento específico, como un deploy o una decisión
- Instrucciones — describen cómo hacer algo, como procedimientos, workflows y runbooks
- Tareas — rastrean en qué se está trabajando en el momento, y son efímeras por diseño
Hechos e instrucciones reciben claves normalizadas por tema. Cuando una nueva memoria tiene la misma clave que una ya existente, la anterior es reemplazada en vez de eliminada, creando una cadena de versiones con un puntero de la memoria antigua a la nueva. Las tareas son excluidas del índice vectorial para mantenerlo ligero, pero siguen siendo descubribles vía búsqueda full-text.
Finalmente, todo se graba en el almacenamiento usando INSERT OR IGNORE, de forma que duplicados basados en contenido son silenciosamente ignorados. Después de devolver la respuesta al harness, la vectorización corre de forma asíncrona en segundo plano. El texto usado para embedding antepone de 3 a 5 consultas de búsqueda generadas durante la clasificación al contenido de la memoria, tendiendo un puente entre cómo las memorias se escriben de forma declarativa y cómo se buscan de forma interrogativa. 🧩
El pipeline de recuperación
Cuando un agente busca una memoria, la consulta pasa por un pipeline de recuperación separado y bastante sofisticado. Durante el desarrollo, el equipo de Cloudflare descubrió que ningún método único de recuperación funciona mejor para todos los tipos de consulta. Por eso, ejecutan varios métodos en paralelo y hacen la fusión de los resultados.
La primera etapa ejecuta análisis de la consulta y embedding de forma concurrente. El analizador de consulta produce claves de tema ranqueadas, términos de búsqueda full-text con sinónimos y un HyDE (Hypothetical Document Embedding), que es una declaración formulada como si fuera la respuesta a la pregunta. La consulta en bruto también se embebe directamente, y ambos embeddings se usan en las etapas siguientes.
En la segunda etapa, cinco canales de recuperación corren en paralelo:
- Búsqueda full-text con Porter stemming — para precisión de palabras clave cuando sabes el término exacto pero no el contexto alrededor
- Búsqueda exacta por clave de hecho — devuelve resultados donde la consulta mapea directamente a una clave de tema conocida
- Búsqueda en mensajes en bruto — consulta los mensajes originales de la conversación vía full-text, funcionando como red de seguridad para detalles que el pipeline de extracción puede haber generalizado
- Búsqueda vectorial directa — encuentra memorias semánticamente similares usando el embedding de la consulta
- Búsqueda vectorial HyDE — encuentra memorias similares a lo que la respuesta se parecería, lo que frecuentemente trae resultados que la búsqueda directa no encuentra, especialmente para consultas abstractas o multi-hop
En la tercera etapa, los resultados de los cinco canales se fusionan usando Reciprocal Rank Fusion (RRF), donde cada resultado recibe una puntuación ponderada basada en su posición dentro de cada canal. Las coincidencias exactas por clave de hecho reciben el mayor peso. Búsqueda full-text, vectores HyDE y vectores directos se ponderan de acuerdo con la fuerza de la señal. Los mensajes en bruto entran con peso bajo como red de seguridad. Los empates se resuelven por recencia, con resultados más nuevos ranqueados más alto.
El pipeline entonces pasa los mejores candidatos al modelo de síntesis, que genera una respuesta en lenguaje natural para la consulta original. Algunos tipos específicos de consulta reciben tratamiento especial. La computación temporal, por ejemplo, se maneja de forma determinística vía regex y aritmética, no por el LLM. Los resultados se inyectan en el prompt de síntesis como hechos precomputados, ya que los modelos son notoriamente poco confiables para cosas como cálculos de fechas. 📊
La infraestructura bajo el capó
Cloudflare construyó Agent Memory usando sus propios productos, y eso es un punto interesante. Bajo el capó, el servicio es un Cloudflare Worker que coordina varios sistemas:
- Durable Objects — almacena los mensajes en bruto y las memorias clasificadas, con SQLite como backend, garantizando aislamiento fuerte entre tenants
- Vectorize — proporciona búsqueda vectorial sobre memorias embebidas
- Workers AI — ejecuta los LLMs y modelos de embedding usados en el pipeline
Cada contexto de memoria mapea a su propia instancia de Durable Object e índice Vectorize, manteniendo datos completamente aislados entre contextos diferentes. Esto también permite escalar fácilmente conforme la demanda crece.
La elección de los modelos
Un hallazgo interesante del desarrollo fue que un modelo más grande y más potente no siempre es mejor. El equipo optó por usar Llama 4 Scout (17B parámetros, MoE con 16 expertos) para extracción, verificación, clasificación y análisis de consultas, y Nemotron 3 (120B MoE, 12B parámetros activos) para síntesis. Scout maneja bien las tareas de clasificación estructurada de forma eficiente, mientras que la mayor capacidad de razonamiento de Nemotron mejora la calidad de las respuestas en lenguaje natural. La síntesis fue la única etapa donde meter más parámetros al problema consistentemente ayudó. Para todo lo demás, el modelo más pequeño alcanzó un equilibrio superior de costo, calidad y latencia.
Qué se puede construir con esto
Agent Memory fue diseñado para funcionar con una amplia variedad de arquitecturas de agentes, y los casos de uso son bastante diversos:
Memoria para agentes individuales. No importa si estás usando agentes de código como Claude Code u OpenCode con un humano en el bucle, frameworks auto-hospedados como OpenClaw o Hermes actuando en tu nombre, o servicios gestionados como los Managed Agents de Anthropic. Agent Memory puede servir como capa de memoria persistente sin exigir cambios en el bucle central del agente.
Memoria para harnesses personalizados de agentes. Muchos equipos están construyendo su propia infraestructura de agentes, incluyendo agentes de background que corren autónomamente sin supervisión humana. Empresas como Ramp, Stripe y Spotify ya han descrito públicamente sistemas de este tipo. Estos harnesses pueden beneficiarse enormemente de memoria que persiste entre sesiones y sobrevive a reinicios.
Herramientas que usamos a diario
Memoria compartida entre agentes, personas y herramientas. Un perfil de memoria no necesita pertenecer a un único agente. Un equipo de ingeniería puede compartir un perfil para que el conocimiento aprendido por el agente de código de una persona esté disponible para todos: convenciones de código, decisiones arquitectónicas, conocimiento tribal que normalmente vive solo en la cabeza de las personas o se pierde cuando el contexto se poda. Un bot de code review y un agente de código pueden compartir memoria para que el feedback de revisiones influencie la generación futura de código. El conocimiento que tus agentes acumulan deja de ser efímero y se convierte en un activo duradero del equipo. 🤝
Cómo Cloudflare lo está usando internamente
El equipo ya usa Agent Memory internamente como campo de pruebas y fuente de ideas para los próximos pasos.
En el flujo de agentes de código, usan un plugin interno de OpenCode que conecta Agent Memory al bucle de desarrollo. El beneficio menos obvio, pero quizás el más valioso, fue la memoria compartida entre el equipo. Con un perfil compartido, el agente sabe lo que otros miembros del equipo ya aprendieron, lo que significa que deja de hacer preguntas que ya fueron respondidas y de cometer errores que ya fueron corregidos.
En la revisión de código agéntica, el resultado más interesante fue que el revisor aprendió a quedarse callado. Ahora recuerda que un comentario específico no fue relevante en una revisión pasada, o que un patrón fue señalado y el autor eligió mantenerlo por una buena razón. Las revisiones se vuelven menos ruidosas con el tiempo, no solo más inteligentes.
En chatbots, la memoria se conectó a un bot interno que ingesta historial de mensajes y después se queda observando y recordando nuevos mensajes. Cuando alguien hace una pregunta, el bot consigue responder basándose en conversaciones anteriores.
Tus datos son tuyos
Conforme los agentes se vuelven más capaces y más profundamente integrados a procesos de negocio, la memoria que acumulan se convierte en genuinamente valiosa. No solo como estado operacional, sino como conocimiento institucional que costó trabajo real construir. Cloudflare reconoce la preocupación creciente de los clientes sobre lo que significa atar ese activo a un único proveedor.
El posicionamiento es claro: Agent Memory es un servicio gestionado, pero los datos pertenecen al cliente. Toda memoria es exportable, y la empresa se compromete a garantizar que el conocimiento acumulado por los agentes en la plataforma pueda salir junto si las necesidades cambian. La filosofía declarada es que la mejor forma de construir confianza a largo plazo es hacer fácil la salida y seguir construyendo algo lo suficientemente bueno para que nadie quiera irse.
Lo que viene por delante
El equipo continúa probando y refinando Agent Memory internamente, mejorando el pipeline de extracción, ajustando la calidad de la recuperación y expandiendo capacidades de procesamiento en segundo plano. Una analogía interesante que la propia Cloudflare usa es con el cerebro humano: así como nuestro cerebro consolida memorias durante el sueño al reproducir y fortalecer conexiones, ellos ven oportunidades para que el almacenamiento de memoria mejore de forma asíncrona y ya están implementando y probando varias estrategias en esa dirección.
Agent Memory todavía está en beta privada, así que el acceso es limitado por ahora. Los desarrolladores interesados en acceso anticipado pueden entrar en la lista de espera directamente en el sitio de Cloudflare. El lanzamiento en sí ya señala una dirección importante hacia donde el ecosistema de desarrollo de agentes está caminando: menos infraestructura manual, más primitivas de alto nivel, y una apuesta clara de que la memoria gestionada va a ser una pieza tan fundamental como las bases de datos o las colas de mensajes lo son hoy para cualquier aplicación seria en producción. 💡
