Guía de la memoria para los agentes: entre RAG, contexto y nuevos frameworks

En 2024, la conversación sobre la memoria de los modelos lingüísticos se jugaba casi en su totalidad sobre un solo eje, RAG contra ventana de contexto larga, como si tuviera que ganar uno de los dos. En 2026, esa pregunta se ha vuelto casi ingenua. Quienes diseñáis agentes hoy no elegís una sola tecnología, componéis un stack, reuniendo recuperación de conocimiento externo, contexto inmediato, competencias interiorizadas en el modelo, acceso a sistemas operativos en tiempo real y alguna forma de continuidad entre una sesión y otra. El problema ya no es "qué técnica usaremos", es "qué nivel de memoria necesita qué parte del problema, y cuánto cuesta equivocarse en la elección".

Esta guía intenta mapear las opciones disponibles hoy, con sus pros, sus contras, los casos en los que brillan y aquellos en los que son un error. No es una clasificación, se parece más a una caja de herramientas: algunas herramientas son destornilladores, otras son martillos, y usar el martillo para atornillar solo produce frustración.

RAG clásico: orígenes y grietas

La generación aumentada por recuperación (RAG) se presenta a menudo como una invención nativa de la era de los modelos lingüísticos, pero es una simplificación. Recuperación y generación, refinamiento de consultas y verificación de respuestas ya eran temas centrales de la investigación en recuperación de información y respuesta a preguntas mucho antes de los transformers, como relata esta reconstrucción histórica del RAG. Los grandes modelos añadieron una interfaz lingüística fluida sobre una arquitectura que la informática documental conocía desde hacía tiempo, un poco como Toy Story añadió un rostro simpático a décadas de investigación en gráficos por ordenador.

El mecanismo básico sigue siendo sencillo de describir: un corpus se divide en fragmentos, los fragmentos se convierten en vectores en un espacio de embedding, una consulta se proyecta en el mismo espacio, se recuperan los fragmentos más similares y se inyectan en el prompt. Las variantes más avanzadas añaden búsqueda híbrida, reranking, descomposición de consultas y, sobre todo, dos técnicas convertidas en un estándar de facto. La primera es el Self-RAG o Corrective RAG, donde el modelo evalúa la relevancia de lo que ha recuperado antes de generar, en lugar de confiar ciegamente en la puntuación de similitud. La segunda es la recuperación contextual introducida por Anthropic, que genera un breve resumen contextual para cada fragmento antes de indizarlo, de modo que un texto aislado lleva consigo la información sobre a qué documento pertenece y de qué trata, reduciendo sensiblemente los fallos de recuperación cuando se combina con reranking.

Los límites siguen siendo estructurales, sin embargo. Fragmentar un documento en bloques fijos corre el riesgo de separar una pregunta de su respuesta o de partir un razonamiento por la mitad. La similitud vectorial no es lo mismo que la relevancia para una tarea específica; dos frases pueden ser semánticamente cercanas y completamente inútiles para la pregunta formulada. La recuperación de los primeros resultados no garantiza el razonamiento multi-hop, y la base de conocimiento se trata como sustancialmente estática: cada actualización requiere una nueva indización. Sobre todo, el RAG clásico no tiene noción alguna de continuidad entre sesiones diferentes; recupera conocimiento sobre el mundo, no memoria del usuario. Tiene sentido para documentación técnica, políticas de empresa o bases de conocimiento de dimensión media-grande donde rastrear la fuente es importante. No basta para dominios fuertemente relacionales o para agentes que necesitan recordar a quién tienen delante.

Contexto largo: el mito de los megatokens

Los modelos con ventanas de contexto enormes han cambiado de forma concreta lo que es posible hacer sin pipelines de recuperación. A mediados de 2026, Claude Sonnet 5 ofrece un millón de tokens de contexto nativo, Gemini 3.1 Pro llega hasta los dos millones de tokens en producción, y GPT-5.5 se sitúa en un millón. Cifras que, hasta hace dos años, sonaban a ciencia ficción de laboratorio.

La ventaja es la simplicidad arquitectónica: no se necesita un vector store, no hace falta una pipeline de retrieval, se carga el texto y se consulta el modelo. Para tareas que requieren ver todo junto, como sintetizar un documento largo o razonar sobre una base de código reducida, el contexto largo puede superar al RAG precisamente porque no introduce la pérdida informativa de la fragmentación. La otra cara de la moneda son el coste y la latencia: procesar un millón de tokens en cada consulta cuesta órdenes de magnitud más que una recuperación dirigida, y las inferencias sobre contextos enormes pueden requerir decenas de segundos frente al tiempo de respuesta casi instantáneo de un RAG bien diseñado. Existe además el fenómeno conocido como "lost in the middle", por el cual, incluso con un contexto desmesurado, la atención del modelo no se distribuye de forma uniforme y la información enterrada en el medio corre el riesgo de quedar infrautilizada, un problema debatido a fondo en este análisis sobre arquitecturas de memoria para agentes. Por último —y este es el punto que a menudo se escapa—, el contexto largo es una propiedad de un solo turno; no da continuidad entre conversaciones diferentes ni gestiona el estado de un usuario a lo largo del tiempo, como aclara bien esta comparación entre RAG y ventanas amplias. Tiene sentido para corpus pequeños y bien delimitados, prototipado rápido y razonamiento global sobre un solo documento. Se convierte en un antipatrón en aplicaciones enterprise de alto volumen de consultas, donde la factura a fin de mes puede ser brutal.

Fine-tuning y preentrenamiento continuado: competencias, no hechos

Adaptar directamente el modelo, mediante fine-tuning completo o preentrenamiento continuado, sirve para interiorizar estilo, formato y convenciones de dominio, no para almacenar hechos que cambian cada semana. Un modelo entrenado en lenguaje jurídico aprende cómo se redacta un dictamen, no aprende el contenido actualizado de cada norma. La ventaja es que, una vez entrenado, no se necesita ningún retrieval en tiempo de ejecución para esas competencias específicas, y en tareas repetitivas de formato fijo —como extraer entidades según un esquema preciso— el fine-tuning supera a menudo a soluciones basadas en unos pocos ejemplos en el prompt, como se ilustra en esta panorámica sobre las alternativas al RAG.

El inconveniente es claro: no es una base de conocimiento dinámica, requiere conjuntos de datos cuidados, infraestructura de entrenamiento y evaluación continua; y si el dominio evoluciona, el modelo debe reentrenarse o corre el riesgo de quedar obsoleto silenciosamente. Tiene sentido para competencias estables en el tiempo; no tiene sentido cuando el valor principal reside en el conocimiento factual que cambia de forma constante.

Tool-use agéntico: la memoria vive en otra parte

Existe toda una categoría de problemas donde la respuesta correcta no es "recordar mejor" sino "no fiarse de la memoria e ir a comprobarlo". Un agente que llama a una API de ticketing, consulta un CRM o ejecuta una consulta en una base de datos no está leyendo un corpus estático, está pidiendo la verdad a quien la posee en tiempo real, como se describe en esta guía sobre recuperación de contexto en producción. La ventaja es obvia: los datos están siempre actualizados, las políticas de acceso se aplican a nivel del sistema origen y las alucinaciones sobre hechos dinámicos se reducen porque el modelo no está adivinando, está leyendo.

El coste reside en la complejidad de integración: se requieren esquemas de entrada y salida, gestión de errores, límites de frecuencia y autenticación, y la latencia depende de sistemas que el agente no controla, por lo que una cadena de varias llamadas puede ralentizarlo todo significativamente. En 2026, buena parte de esta integración pasa ya por el Model Context Protocol, un estándar que ha facilitado enormemente la conexión de agentes a herramientas externas sin reinventar la interfaz en cada ocasión, y que se ha convertido también en la forma en que los frameworks de memoria descritos más adelante se exponen a los agentes. El uso de herramientas tiene sentido para conocimiento crítico en sistemas transaccionales y para tareas que requieren acciones, no solo respuestas. Es un error cuando el dominio es principalmente documental y estable, o cuando las API externas no ofrecen garantías de fiabilidad.

GraphRAG: el conocimiento como red

En lugar de recuperar solo fragmentos de texto, se puede construir un grafo de entidades, relaciones y atributos y realizar retrieval sobre nodos y rutas. La diferencia práctica se observa en preguntas del tipo "¿qué proyectos han usado un determinado modelo y han tenido incidentes de seguridad?", donde se requiere atravesar múltiples saltos relacionales que la similitud textual por sí sola no puede captar, un punto profundizado en esta guía de técnicas RAG avanzadas de 2026 y en mi artículo anterior sobre la construcción de wikis autogeneradas para LLM. Investigaciones independientes presentadas en eventos del sector mostraron mejoras sustanciales en precisión factual al pasar de un mero rescate vectorial a un grafo consultable, como relata esta análisis sobre la memoria agéntica más allá de los vectores.

El grafo hace explícitas relaciones que el texto deja implícitas, permitiendo consultas estructuradas más allá de la similitud semántica. Construirlo y mantenerlo, sin embargo, es un trabajo intensivo: exige extraer entidades y relaciones, limpiar, alinear ontologías y supervisar una pipeline compleja donde componentes simbólicos y neuronales deben coexistir, como señala también esta guía de bases de datos de grafos para agentes de IA. No todo el dominio se presta a la modelización en grafo; a menudo se requiere un híbrido entre grafo y texto puro. Funciona bien para organizaciones empresariales, redes de productos y componentes, y cadenas causales de incidentes. Es un despilfarro de recursos en corpus predominantemente narrativos o poco estructurados.

Caching del contexto: velocidad en contenidos estables

Cuando un mismo corpus se reutiliza continuamente, reconstruir desde cero el contexto en cada llamada es un desperdicio evidente. Las principales plataformas han respondido con soluciones concretas, no solo teóricas. El prompt caching de Anthropic permite marcar bloques estables del prompt —como instrucciones del sistema o documentos de gran tamaño— y reutilizarlos en peticiones sucesivas a una fracción del coste, con lecturas de la caché tarificadas hasta a un décimo del precio de los tokens de entrada normales y reducciones muy notables de la latencia en documentos largos. Google ofrece un mecanismo análogo con el context caching de su API Gemini, pensado para no tener que pagar cada vez el procesamiento de bases de código enteras o transcripciones de reuniones de varias horas.

El beneficio es concreto en contextos reutilizados intensamente: un asistente interno sobre manuales fijos o una base de código estable obtiene ventajas inmediatas en latencia y coste. La limitación es igualmente clara: esta técnica ayuda poco en conocimientos que cambian a menudo o en sesiones muy heterogéneas entre sí, e introduce además una gestión no trivial de invalidación y coherencia de la caché.

Taxonomía de la memoria agéntica

Aquí se entra en el territorio más específico de los agentes que deben comportarse como si recordaran algo, no solo como si supieran algo. La memoria en el contexto inmediato —los últimos turnos de la conversación actual— es instantánea y con coste de infraestructura nulo, pero dura solo para la sesión en curso y pierde información fácilmente si la ventana es pequeña. La memoria episódica resume sesiones pasadas, eventos destacados y decisiones tomadas, otorgando continuidad entre conversaciones a costa de una compresión que inevitablemente pierde detalles. La memoria semántica se parece al RAG pero concebida como memoria a largo plazo del agente: excelente para hechos puntuales, débil en relaciones complejas si no se acompaña de un grafo. La memoria procedimental, a menudo realizada mediante fine-tuning o configuración explícita del agente, captura patrones de acción y competencias reutilizables, pero no es adecuada para hechos cambiantes —un marco bien trazado en esta panorámica sobre arquitecturas de memoria vectorial, en grafo y episódica y en esta comparación entre memoria personal y conocimiento recuperado.

Los beneficios generales de esta capa son la continuidad entre sesiones y la personalización, pero conllevan riesgos específicos, en particular lo que podría llamarse "memoria tóxica": información obsoleta o errónea que se queda atascada y degrada silenciosamente el comportamiento del agente con el tiempo. Tiene sentido para agentes que interactúan repetidamente con los mismos usuarios; debe mantenerse al mínimo o evitarse en chatbots ocasionales o bajo restricciones estrictas de privacidad.

El mapa de los frameworks reales

La taxonomía teórica anterior cobra forma concreta en un puñado de proyectos que en 2026 cualquiera que trabaje con agentes conoce por su nombre. Letta, heredero directo del proyecto MemGPT, popularizó la idea de un agente con una core memory de unos pocos cientos de tokens que el modelo lee y escribe por sí mismo mediante llamadas a herramientas, más una archival memory mucho más amplia fuera de la ventana de contexto, paginada hacia dentro y hacia fuera según la necesidad, como se describe en esta comparación entre los principales frameworks de memoria para agentes. Mem0 se centra en la simplicidad de integración, una capa de memoria plug and play orientada a preferencias de usuario y sesiones, con recuperación basada en múltiples señales combinadas.

Zep, construido sobre el motor de código abierto Graphiti, adopta un enfoque diferente y bastante elegante: trata cada mensaje como fuente de hechos sobre entidades y relaciones, y cada hecho como un arco delimitado temporalmente en el grafo, con una ventana de validez que permite invalidar una información superada en lugar de sobrescribirla o dejar que contamine respuestas futuras. El Technology Radar de Thoughtworks promovió Graphiti a la fase de prueba en abril de 2026, citando benchmarks que hablan de mejoras de precisión en torno al 18,5 por ciento y reducciones de latencia cercanas al 90 por ciento frente a un GraphRAG tradicional, como se lee en esta ficha del radar tecnológico. Cognee sigue una lógica más cercana al grafo puro, con una pipeline de recuerdo, recuperación, olvido y mejora pensada para documentos, entidades y bases de código.

Junto a estos hay proyectos más nicho pero técnicamente relevantes. EverMind, con su EverMemOS, propone una arquitectura de doble capa entre memoria de trabajo y memoria a largo plazo en forma de grafo de conocimiento dinámico, y ha publicado una investigación, de la que hablé en un artículo de mayo de 2026, sobre un mecanismo denominado memoria de atención dispersa, pensado para gestionar eficientemente contextos de hasta cien millones de tokens. Graphify, por su parte, se concentra en la memoria para asistentes de programación, convirtiendo código, documentos, commits e incluso capturas del navegador en un único grafo navegable, actualizando solo los nodos que realmente cambian en lugar de rehacer la indización desde cero; hablé de ello en este artículo de junio de 2026.

Quienes tengáis que orientaros entre estos nombres haríais bien en partir del problema, no de la popularidad del proyecto. Si necesitáis un runtime donde la memoria sea el corazón mismo del agente, Letta es la referencia natural. Si el problema es una personalización rápida con integración mínima, Mem0 sigue siendo la opción pragmática. Si importan los hechos que cambian en el tiempo y su validez histórica, Zep con Graphiti es probablemente la respuesta más madura disponible hoy. Si el dominio es intrínsecamente un grafo —documentos, entidades, bases de código—, Cognee o Graphify merecen una evaluación seria.

Stacks híbridos: la síntesis que funciona

Ninguna de estas técnicas, tomada aisladamente, cubre el espectro completo de las necesidades de un agente serio. La comunidad técnica en 2026 converge en esta idea de forma bastante sólida: el contexto largo debe tratarse como un complemento del RAG y de la memoria, no como su sustituto, según se desprende de este análisis sobre arquitecturas híbridas para agentes de IA y de esta comparación entre memoria a largo plazo y modelos de contexto largo. Pruebas comparativas entre diferentes arquitecturas —RAG puro, contexto largo, archivos de memoria y enfoques híbridos— mostraron que la combinación obtiene una tasa de recuperación muy alta a un coste sensiblemente inferior respecto al contexto largo utilizado en solitario, un dato citado en esta guía práctica de arquitecturas de memoria, aunque conviene comprobar siempre las condiciones específicas de cada benchmark antes de trasladarlas acríticamente al propio caso de uso.

Un patrón razonable para dimensionar el stack parte del tamaño del corpus. Para cincuenta a quinientas páginas, un RAG para filtrar pasajes relevantes más contexto largo para procesarlos juntos funciona bien. Más allá de quinientas páginas, o en corpus en crecimiento continuo, el RAG (potenciado opcionalmente con grafos) se vuelve casi obligatorio, y el contexto largo debe reservarse únicamente para los resultados de la recuperación. En un agente enterprise típico conviven RAG para documentación y políticas, uso de herramientas para sistemas operativos, memoria episódica y semántica para los usuarios, y un grafo para relaciones complejas entre productos, servicios e incidentes, como se describe también en esta guía sobre ingeniería del contexto. Un copiloto técnico podría combinar RAG en documentación, un grafo para dependencias entre componentes y caching en secciones estables. Un tutor didáctico podría unir memoria episódica para el estudiante, RAG sobre el material del curso y un ligero fine-tuning sobre el estilo pedagógico.

Tabla comparativa

Guía práctica para quien diseña agentes

Antes de elegir una arquitectura conviene responder a unas pocas preguntas sencillas pero a menudo descuidadas: ¿Qué tamaño tiene el corpus? ¿Con qué frecuencia cambia el conocimiento? ¿Se requiere continuidad entre usuarios que vuelven o cada conversación puede empezar desde cero? ¿Cuáles son las restricciones reales de coste, latencia y privacidad? ¿Se requieren razonamientos que atraviesen múltiples entidades conectadas entre sí o bastan respuestas puntuales?

De estas respuestas se desprende casi mecánicamente un primer borrador de stack: un corpus pequeño y estable sugiere contexto largo o un RAG ligero; un corpus medio o grande exige RAG (opcionalmente enriquecido con grafos), con el contexto largo reservado a las salidas del retrieval; usuarios recurrentes imponen una capa de memoria episódica o semántica; datos operativos en tiempo real piden el uso de herramientas sobre sistemas externos; relaciones complejas justifican la inversión en un grafo. Ninguna de estas elecciones es definitiva —y ese es precisamente el punto más difícil de aceptar para quienes vienen de un mundo de soluciones únicas y definitivas—: la memoria de un agente serio se construye por capas, se revisa con el tiempo y debe tratarse como una pieza de infraestructura que mantener exactamente igual que el código que la rodea, no como una función que una vez implementada se puede olvidar.