Capa de memoria para IA: diseñar memoria persistente para agentes

¿Qué debería recordar un agente cuando termina una conversación? Imaginar que guardamos todo es fácil. Decidir qué debería influir en la siguiente respuesta requiere más cuidado.

Una capa de memoria para IA es la parte de una aplicación que selecciona, guarda y recupera información para que un agente la reutilice más allá de la interacción actual. También necesita una forma de corregir o eliminar lo que conserva. La memoria persistente sobrevive a un reinicio, pero guardar algo no basta para que sea útil.

En Conceptos clave para implementar memoria en Agentes repasé los conceptos principales. Aquí vamos a seguir un comentario desde una conversación hasta su posible uso posterior.

¿Qué vale la pena recordar?

Veamos un ejemplo hipotético. Alguien que trabaja en un documento le dice a un asistente:

Para este correo, usa un tono más directo porque la audiencia ya conoce la empresa.

Hay tres partes útiles: la instrucción, el alcance y el motivo. Si quitamos cualquiera de ellas, cambiamos lo que pidió la persona.

“Usa un tono directo” es demasiado amplio. “La empresa prefiere una comunicación directa” inventa una regla para toda la empresa. El comentario original se refiere a un correo y a una audiencia que necesita menos introducción.

La memoria es una interpretación selectiva de lo ocurrido, no una segunda transcripción. Una instrucción temporal puede servir para futuras revisiones de ese correo sin convertirse en una preferencia permanente. La pregunta es: ¿en qué tarea futura ayudaría esto y bajo qué condiciones?

¿Qué guardamos exactamente?

Una pequeña nota de memoria podría verse así. Es ilustrativa, no un esquema de base de datos:

• Comentario: usar un tono más directo en este correo.
• Se aplica a: las revisiones del correo que se está trabajando.
• Motivo indicado: la audiencia ya conoce la empresa.
• Fuente humana: “Para este correo, usa un tono más directo porque la audiencia ya conoce la empresa.”
• Ubicación de la fuente: el mensaje de la persona en la conversación correspondiente.

La interpretación facilita recuperar la nota. El fragmento exacto que la respalda permite revisar si esa interpretación es fiel. Conservar una referencia a la fuente también ayuda cuando hace falta aclarar a qué se refiere “este correo”.

También debemos distinguir entre un comentario, una propuesta y una decisión explícita. “¿Podríamos hacerlo más directo?” no equivale a “Usa esta versión”. Un extractor puede clasificar mal cualquiera de las dos frases. Encontrar una cita exacta demuestra que esas palabras aparecieron, no que el significado extraído sea correcto.

Una sugerencia del asistente tampoco es una aprobación humana. Si propone cambiar el tono y nadie acepta, esa sugerencia no debería convertirse silenciosamente en una decisión recordada.

¿Cuándo capturamos la información?

Podemos capturar una instrucción clara durante la interacción o extraer candidatos después. Depende de qué tan pronto necesitemos disponer de la información.

La extracción en segundo plano permite continuar con la respuesta sin esperar cada operación de memoria. También separa dos procesos: el asistente puede haber respondido mientras el procesamiento de memoria sigue pendiente. Una extracción fallida no debería verse igual que una extracción exitosa que no encontró nada que conservar.

Conviene hacer visibles esos resultados para poder revisarlos o reintentarlos. De lo contrario, alguien puede creer que se guardó una corrección cuando solo se completó la respuesta. La extracción debería producir candidatos que la aplicación pueda validar, no convertir cada frase en una regla duradera.

¿Cómo se usa en la siguiente interacción?

Supongamos que la persona vuelve a revisar ese correo. Primero buscamos notas aplicables al documento y comprobamos el acceso actual. Unos pocos registros con un alcance definido pueden bastar; la búsqueda vectorial no es un requisito para tener memoria persistente en agentes.

Es fácil confundir estos tres pasos:

Información guardada → candidatos recuperados → contexto actual del modelo

Una nota guardada puede no recuperarse. Una nota recuperada puede quedar fuera del prompt porque es irrelevante, está en disputa o es demasiado extensa. El modelo solo puede usar el material que recibe en esa invocación.

El historial registra el intercambio. El contexto es la entrada que se entrega en una llamada concreta al modelo. La generación aumentada por recuperación, o RAG, incorpora material relevante a esa entrada: puede recuperar documentos o notas de memoria, pero no decide qué merece recordarse.

En una ejecución con varios pasos, una opción de diseño es fijar las memorias seleccionadas al inicio. Así, los pasos comparten una vista consistente mientras continúa la extracción en segundo plano. Otra tarea puede necesitar una actualización explícita. No hay una opción universal; lo importante es saber qué información se usó para responder.

Si la recuperación falla o solo devuelve una parte del material disponible, no hay que presentarla como un recuerdo completo. “No encontré notas relevantes” y “No pude consultar las notas” significan cosas distintas.

Los permisos se comprueban tanto al leer como al escribir. Recordar que alguien administra un documento no le concede autoridad para acceder a él o modificarlo. La aplicación debe verificar los permisos actuales por separado.

¿Qué pasa si las personas no están de acuerdo?

Ahora imaginemos que otra persona pide una versión con más introducción. ¿Es una contradicción, otra audiencia u otro correo?

Necesitamos suficiente información sobre el alcance y la fuente para distinguirlo. Si ambas instrucciones se refieren a la misma revisión y entran en conflicto, conviene mostrar el desacuerdo en lugar de asumir que gana el mensaje más reciente. El asistente puede preguntar qué dirección seguir, en vez de mezclar instrucciones incompatibles.

Una corrección explícita puede reemplazar una nota anterior según la política de la aplicación. Aun así, hay que decidir quién puede corregirla y a qué se aplica. La actualización debería dejar un rastro comprensible del cambio; las notas obsoletas también necesitan una forma de retirarse o eliminarse.

¿Dónde ayuda un grafo?

Un grafo puede conectar una memoria con su mensaje de origen, documento, autor y decisiones relacionadas. Eso ayuda a responder preguntas como “¿Qué comentarios pertenecen a este documento?” o “¿Qué respalda esta decisión?”.

Esas relaciones no convierten una afirmación en verdad. Un grafo no aporta razonamiento ni ordena resultados por relevancia semántica por sí solo. Organiza conexiones; la aplicación sigue necesitando reglas de acceso, relevancia e interpretaciones en conflicto.

Empieza con registros simples si resuelven tus preguntas. Añade relaciones cuando recorrerlas resulte útil. Mi pipeline experimental de grafos de conocimiento con Markdown explora relaciones entre documentos, no un sistema completo de memoria para agentes.

Algunas comprobaciones prácticas

Antes de elegir más infraestructura, prueba con unas pocas conversaciones:

• ¿El comentario sobre un correo se mantiene limitado a ese correo?
• ¿Se pueden revisar las palabras humanas que respaldan una nota?
• ¿Una propuesta no aceptada del asistente sigue siendo una propuesta?
• ¿Se distingue un fallo de extracción de un resultado vacío?
• ¿Revocar el acceso impide tanto recuperar información como escribirla?
• ¿Los comentarios contradictorios llevan a una aclaración y no a sobrescribir en silencio?

La pregunta útil no es cuánto puede guardar el agente. Es si la información adecuada llega a la siguiente tarea conservando su significado y sus límites.

Para seguir leyendo: los conceptos de memoria de LangChain, la guía de persistencia de LangGraph y la documentación de recuperación.