Memoria y RAG para agentes que no olvidan: capas, recuperación y pruebas

Casi toda la "memoria de agentes" es una base de datos vectorial pegada con cinta adhesiva a un bucle de chat. Embebes todo, recuperas el top-k por similitud de coseno, lo pegas en el prompt y en la demo se ve precioso. Después un usuario real pregunta "¿qué decidimos la última vez?" y el agente recita con toda seguridad la reunión equivocada, porque la correcta era el fragmento número 11 y solo trajiste 8. La solución no es un modelo de embeddings más grande ni una base de datos más sofisticada. Es aceptar que la memoria es un sistema con capas bien diferenciadas, reglas explícitas de promoción, una recuperación que se gana su lugar en el prompt y un eval que te dice si algo de eso sirvió. Termina de leer esto sabiendo cómo armar una memoria que sabe qué conservar, dónde y cuándo botar el resto.

01 · La memoria son tres sistemas, no uno

El error de fondo es tratar la "memoria" como un solo balde donde echas cosas y consultas después. La cognición humana mantiene separadas la memoria de trabajo, la episódica y la semántica por buenas razones, y los agentes necesitan esa misma separación, con reglas explícitas sobre qué va dónde.

La memoria de trabajo es la ventana de contexto actual: la tarea en curso, los últimos turnos y lo que acabas de recuperar. Es rápida, cara y pequeña. La regla de oro es que nada importante puede vivir solo aquí, porque la ventana se trunca o se compacta y entonces se pierde. Trátala como un borrador, nunca como almacenamiento.

La memoria episódica es el registro append-only de lo que de verdad pasó. Decisiones, llamadas a herramientas y sus resultados, correcciones del usuario, errores. Cada uno con su timestamp y atribuible a una sesión. Este es tu rastro de auditoría y tu respuesta literal a "¿qué decidimos la última vez?". En Proyección, nuestra herramienta para practicar negociaciones, la memoria episódica es el producto entero: cada ensayo es un episodio, y el valor está en volver a vivir una conversación puntual, no un promedio borroso de todas.

La memoria semántica son hechos destilados y duraderos. "El presupuesto máximo del cliente es 40k." "Este usuario prefiere TypeScript antes que Python." Son conclusiones que escribes una vez y actualizas de forma deliberada, no transcripciones crudas. Es pequeña a propósito. Si crece sin límite, lo único que estás haciendo es acumular episodios con pasos de más.

02 · Promover es una decisión, no un efecto colateral

El flujo entre capas es donde vive casi todo el valor, y es justo la parte que todo el mundo se salta. Los episodios se escriben sin pensarlo y a bajo costo; registras todo, todo el tiempo. Los hechos semánticos se escriben rara vez y de forma deliberada, solo cuando algo es lo bastante estable como para valer la pena recordarlo para siempre. Generoso abajo, conservador arriba.

// Promover es una decisión, no un efecto colateral.
type MemoryWrite =
  | { layer: "episodic"; sessionId: string; kind: "decision" | "correction" | "tool_result"; text: string }
  | { layer: "semantic"; key: string; value: string; source: string; confidence: number }

// Los episodios se escriben sin pensarlo. Los hechos semánticos se escriben
// solo cuando algo es estable y vale la pena recordarlo para siempre, y
// siempre llevan un puntero de vuelta al episodio que los respalda.
function shouldPromote(fact: { key: string; confidence: number }): boolean {
  return fact.confidence >= 0.8
}

El campo source es la parte que no puedes dejar fuera. Cada hecho semántico tiene que apuntar de vuelta al episodio que lo justifica. El día que un usuario diga "no, el presupuesto nunca fue 40k", necesitas encontrar de dónde salió eso para corregirlo o eliminarlo. Un hecho semántico sin procedencia es un rumor que tu agente trata como verdad revelada.

Haz que el agente justifique la promoción. En la práctica es un paso extra: cuando el agente quiere escribir en memoria semántica, tiene que enunciar el hecho, citar el episodio y asignarle una confianza. El umbral es un ajuste que tú defines, no una constante grabada en piedra. Fíjalo observando qué se promueve y preguntándote si te jugarías una respuesta con eso.

03 · Recuperación que se gana su lugar en el prompt

El top-k por coseno es un punto de partida, no una estrategia. Dos cambios se pagan solos de inmediato.

Enruta antes de embeber

"¿Cuál es el presupuesto?" debería ir a memoria semántica, devolver un hecho limpio y detenerse. "Cuéntame cómo fue esa llamada" debería ir a memoria episódica y traer un tramo contiguo, no fragmentos sueltos de seis sesiones distintas. Decidir a qué capa pertenece una consulta, antes de embeber nada, elimina la mayor parte del ruido "relevante pero inútil" que hace que el RAG ingenuo termine respondiendo a medias. Un clasificador barato, o hasta una simple heurística por palabras clave, hace el enrutamiento; no necesitas una llamada a un modelo para distinguir "¿cuál es la X?" de "cuéntame la Y".

Reordena y poda

Trae más candidatos de los que necesitas, digamos 20, reordénalos contra la pregunta real y quédate solo con los 3 a 5 que sobrevivan. La similitud de coseno te dice qué está temáticamente cerca; un reranker te dice qué responde la pregunta. El reranker más barato es una llamada a Claude que puntúa cada candidato de 0 a 1 según "¿esto ayuda a responder la consulta?" y descarta todo lo que quede bajo un umbral. Cuesta un poquito; te ahorra pegar 8k tokens de ruido en cada turno.

La métrica que importa aquí no es el recall. Es la precisión de contexto: de todo lo que metiste en la ventana, ¿cuánto realmente aportaba? Una precisión alta significa que el modelo gasta su atención en la señal en vez de promediar entre distractores. Un ejemplo concreto deja clara la diferencia. El usuario pregunta: "¿Seguimos con Supabase para el proyecto nuevo?"

• El RAG ingenuo embebe la pregunta, devuelve 8 fragmentos que mencionan Supabase, Postgres, auth y un hilo de migración que no viene al caso, y el modelo los promedia obedientemente hasta dejar todo en un "depende".
• El enfoque por capas enruta a memoria semántica, encuentra un solo hecho ("Decisión (2026-03): Supabase para proyectos bajo ~50k MAU; revisar al escalar.") con un enlace de vuelta al episodio donde se decidió. Un hecho, una fuente, una respuesta limpia.

04 · Compactar sin amnesia

Las ventanas de contexto son finitas, así que las sesiones largas necesitan compactarse. La salida fácil es resumir los turnos viejos en un solo bloque y botar los originales. Ese bloque es donde la memoria se va a morir: pierde información, no es atribuible y reescribe la historia en silencio según lo que al resumidor le pareció importante. Mejor compacta por niveles.

1. Conserva los últimos N turnos tal cual. La recencia es barata y de alto valor; no comprimas lo que quizás necesites palabra por palabra en los próximos dos turnos.
2. Extrae los hechos estructurados antes de resumir. Saca las decisiones, correcciones y resultados de los turnos viejos y escríbelos en memoria episódica o semántica primero. El resumen es una comodidad; la extracción estructurada es lo que de verdad estás guardando.
3. Conserva los punteros. Una línea de resumen debería decir "se decidió X (ver episodio 2026-03-14T...)" para poder volver a abrir el original si una pregunta posterior exige el detalle.

El orden es todo el truco: primero extrae, luego comprime. Si comprimes primero, ya no puedes extraer lo que la compresión botó. Es una puerta de una sola dirección. Esto lo aprendimos por las malas en ThinkTank AI, nuestra plataforma de deliberación multiagente. Al principio, resumir un debate borraba las razones por las que los agentes cambiaban de postura, que es la única parte interesante de una deliberación. Ahora cada cambio de postura se escribe como evento episódico antes de que cualquier resumen pueda tocarlo.

05 · Demuéstralo, o estás adivinando

La pregunta honesta que nadie quiere hacer: ¿la memoria hizo mejor al agente, o solo más lento y más caro? Eso no lo respondes leyendo transcripciones y asintiendo. Arma un eval pequeño y aburrido, y deja que él te lo diga.

• Fija un conjunto de tareas donde la respuesta correcta dependa del contexto previo: "¿qué decidimos sobre X?", "¿qué prefiere este usuario?", "resume cómo fue esa negociación".
• Corre cada tarea de tres formas: memoria apagada, RAG ingenuo y memoria por capas.
• Puntúa en tres ejes: corrección de la respuesta, precisión de contexto (¿cuánto del contexto inyectado se usó de verdad?) y costo/latencia.

Si la memoria por capas no le gana al RAG ingenuo en corrección y en precisión, tu problema es la recuperación, no el modelo. Ajusta el enrutamiento y el reranking antes de echar mano de un modelo más grande o más caro; eso casi siempre sale más barato y casi siempre es el verdadero arreglo. Y vuelve a correr el eval cada vez que toques la ruta de recuperación; los sistemas de memoria se pudren en silencio, y la única forma de enterarte es un número que se movió.

06 · Cuándo no vale la pena

La memoria es un pasivo que eliges asumir, no una función que agregas por defecto. Sáltatela cuando:

• La tarea no tiene estado. Un clasificador o extractor de un solo paso no necesita recordar lo de ayer. Meterle memoria aquí es puro costo y un nuevo modo de fallo a cambio de cero beneficio.
• La "memoria" en realidad es config. Si un hecho nunca cambia para un usuario, es un ajuste, no una memoria. Ponlo en una fila, o en una variable de entorno, no en un vector store. (Construimos Infuse, nuestro gestor de secretos, justamente para que los valores duraderos por tenant vivan en algo consultable y auditable, y no desperdigados entre embeddings.)
• No puedes evaluarla. Una memoria vieja o equivocada es peor que no tener ninguna: un hecho falso recordado con seguridad envenena cada paso que viene después, y vas a perder más tiempo depurando contexto fantasma del que llegaste a ahorrar. Sin eval, no hay memoria.

La memoria que no olvida no es la que guarda todo. Es la que sabe qué conservar, dónde y cuándo botar el resto. Separa la de trabajo, la episódica y la semántica; enruta la recuperación a la capa correcta y reordena lo que traes; extrae antes de comprimir; y ponle un número a si está ayudando. Haz eso y tu agente deja de alucinar su propia historia.