Memoria para agentes de IA: tipos y cómo construirla

El problema: un modelo de lenguaje olvida todo entre una llamada y la siguiente. Lo que tu agente "recuerda" (el plan del cliente, la solución que funcionó la última vez, que pidió que le escriban por correo y no lo llamen) tiene que guardarse fuera del modelo y volver al prompt en el momento justo. Ese almacén, y las reglas para escribir y leer en él, es la memoria del agente.

Construimos SynapCores, y los ejemplos de SQL lo usan. Todos se ejecutaron en SynapCores 2.4.8. Los tipos de memoria, el ciclo y los errores típicos aplican a cualquier stack.

¿Qué es la memoria de un agente de IA?

Es la información que un agente puede usar más allá del prompt actual, junto con el mecanismo que la mantiene al día. En la práctica son dos cosas:

1. Un almacén que sobrevive entre llamadas y sesiones, asociado a un usuario, una cuenta o un equipo de agentes.
2. Un ciclo que escribe en ese almacén después de cada turno y lee de él antes del siguiente.

El modelo nunca "aprende" de la conversación. La memoria es recuperación: el agente, o el código que lo rodea, encuentra los recuerdos correctos y los agrega al prompt.

Tipos de memoria de un agente de IA

Dos distinciones hacen casi todo el trabajo.

Episódica vs. semántica decide si una escritura agrega o reemplaza. La memoria se corrompe casi siempre por el lado semántico: agregar un episodio no puede dejar el almacén mal, reemplazar un hecho sí.

Corto vs. largo plazo decide qué va al prompt (un problema de presupuesto) y qué va al almacén (un problema de exactitud).

El ciclo de memoria (arquitectura)

Con cualquier framework o base de datos, la memoria de un agente sigue el mismo ciclo:

 turn ends ──► 1. EXTRACT facts / episodes
                   │
                   ▼
              2. WRITE RULE: new? duplicate? replaces an old fact? conflict?
                   │
                   ▼
              3. STORE with identity, time, source and confidence
                   │
 next turn ◄── 5. USE: put the recalled memories in the prompt
                   ▲
              4. RECALL: current state first, then the most relevant facts
                 and episodes (meaning × recency × importance)

1. Extraer. Un LLM o una regla convierte la conversación en frases cortas: "se mudó de Azure a AWS", "prefiere correo".
2. Regla de escritura. Decidir si cada frase es nueva, un duplicado, una actualización de un hecho existente o un conflicto que alguien debe revisar. Este es el paso que mantiene la memoria correcta.
3. Guardar. Cada recuerdo va con la identidad a la que pertenece, cuándo se dijo, desde cuándo es cierto, de dónde salió y cuánta confianza le tienes.
4. Recuperar. Antes de que el modelo responda, trae los valores actuales de los atributos que importan y luego los hechos y episodios más relacionados con el mensaje nuevo, ponderados por lo recientes e importantes que sean.
5. Usar. Ponlos en el prompt de forma compacta y etiquetada, para que el modelo distinga un hecho actual de un episodio viejo.

Frameworks como Mem0 o el almacén de largo plazo de LangGraph resuelven algunos de estos pasos o todos, cada uno a su manera. Las preguntas para evaluar cualquiera son las mismas: ¿cuál es la regla de escritura? ¿Cómo distingue la recuperación un hecho actual de uno viejo?

Cómo construir la memoria de un agente en SQL

SynapCores ofrece dos niveles:

• MEMORY_STORE / MEMORY_RECALL: un almacén semántico plano, con un espacio de nombres y una búsqueda por similitud.
• CREATE MEMORY: un objeto de memoria administrado que guarda episodios, hechos, estado actual, intervalos de validez y procedencia por identidad, y aplica la regla de escritura por ti.

Los dos son SQL normal, así que puedes usarlos desde cualquier framework de agentes que ejecute SQL.

Paso 1: guardar y recuperar por significado (el almacén plano)

SELECT MEMORY_STORE('customer_4821',
  'Oct 3: asked for a refund on order 1182; we promised it within 5 to 10 business days.',
  json_object('kind', 'interaction', 'channel', 'email')) AS id;
SELECT MEMORY_STORE('customer_4821', 'Prefers email over phone calls.',
  json_object('kind', 'preference')) AS id;
SELECT MEMORY_STORE('customer_4821', 'Runs the app on AWS with Postgres 15.',
  json_object('kind', 'fact')) AS id;

SELECT content, similarity
FROM MEMORY_RECALL('customer_4821', 'Has my refund gone through yet?', 3);

Con estos tres recuerdos guardados, la promesa de reembolso sale primero con similitud 0.64; los otros dos quedan muy abajo (0.04 y 0.02). Es la herramienta correcta para recuperar episodios. Pero no tiene idea de "valor actual", y eso es lo que agrega el paso siguiente.

Paso 2: un objeto de memoria con estado actual, historial y procedencia

CREATE MEMORY support_memory IDENTITY customer_id;

Una sola sentencia crea el objeto y cinco tablas normales que puedes consultar con SELECT: episodios, hechos, estado actual, procedencia y relaciones. IDENTITY indica el campo que delimita cada lectura y escritura, así la memoria de un cliente nunca se mezcla con la de otro.

Paso 3: recordar, incluidos los hechos que reemplazan a otros

REMEMBER support_memory FOR customer_id = 4821
  'We run the app on Azure and use Postgres 15.';

REMEMBER support_memory FOR customer_id = 4821
  'We finished moving the app from Azure to AWS last week.'
  WITH (attribute = 'cloud_provider', value = 'AWS');

REMEMBER support_memory FOR customer_id = 4821
  'Please email me, I never pick up the phone.'
  WITH (attribute = 'contact_channel', value = 'email');

Cada REMEMBER guarda primero el episodio tal cual y después deriva de él hechos y estado. Si indicas el atributo y el valor de forma explícita, como en las dos últimas sentencias, el cambio de estado es seguro y no depende de la extracción.

Cada dato lleva además una autoridad (source_type), desde system_of_record hasta agent_inference. Así un registro verificado le gana a algo que el agente dedujo.

Paso 4: pedir el valor actual, no la frase más parecida

CURRENT support_memory FOR customer_id = 4821 ATTRIBUTE cloud_provider;

En 2.4.8 devuelve el estado ok con el valor AWS, autoridad user_statement, confianza 0.85 y el momento desde el que es válido. Para un cliente sin nada registrado devuelve not_found con valor nulo. Y cuando dos datos no se pueden desempatar por autoridad, fecha ni confianza, devuelve conflict con los dos en competing_claims en lugar de elegir uno.

CURRENT es una consulta de estado, nunca una búsqueda por similitud, así que el episodio viejo de "estamos en Azure" no puede volver como respuesta.

Paso 5: recuperar todo lo relevante para el prompt y rastrear cualquier dato

RECALL support_memory FOR customer_id = 4821 ABOUT 'which cloud are they on';

TRACE support_memory FOR customer_id = 4821 ATTRIBUTE cloud_provider;

RECALL devuelve el estado actual (cloud_provider: AWS, contact_channel: email) separado de los hechos y episodios relacionados, para que el prompt pueda etiquetar cada cosa.

TRACE dice de dónde salió un valor: el episodio original tal cual ("We finished moving the app from Azure to AWS last week."), cuándo se registró, cómo se extrajo y qué reemplazó. Es el rastro de auditoría que necesitas cuando un agente dice algo inesperado.

Memoria correcta: la regla de escritura

Casi todos los errores de memoria de un agente ocurren al escribir. Un hecho nuevo se guarda junto al viejo, un dato se mezcla con el cliente equivocado o una suposición se guarda como si estuviera verificada. Cuatro reglas evitan la mayoría:

• Separa episodios de hechos. Solo los hechos necesitan una regla de reemplazo.
• Usa atributos fijos cuando puedas. cloud_provider = AWS no necesita un modelo para actualizarse; el texto libre sí.
• Pon un filtro a los reemplazos en texto libre. Reemplaza un recuerdo viejo solo si el nuevo está muy relacionado y una verificación de contradicción está segura; lo dudoso va a revisión. La receta 036 (en inglés) lo hace en una sola sentencia SQL.
• Conserva historial y procedencia. Nunca borres sin un puntero a lo que lo reemplazó, para poder deshacer un reemplazo malo y explicarlo.

Recetas de memoria para agentes de IA

Cada receta es SQL ejecutable en la Community Edition gratuita. Las recetas están en inglés.

Memoria de largo plazo y recuperación

• Memoria de largo plazo para cualquier agente de IA, en SQL
• Recuperar memoria por significado y por lo reciente
• Memoria episódica y semántica para un agente
• Quitar duplicados de la memoria por significado

Memoria correcta

• Detectar contradicciones al escribir, en una consulta SQL
• Memoria coherente: negarse a recordar una contradicción

Memoria de conversación

• Memoria de conversación con resumen continuo
• Memoria de conversación con hechos estructurados
• Memoria de conversación para un agente de voz

Memoria compartida y agentes completos

• Memoria compartida para sistemas multiagente (patrón pizarra)
• Un asistente personal: memoria + herramientas + rag

¿Dónde debería vivir la memoria?

Checklist antes de poner la memoria en producción

• Asocia cada recuerdo a una identidad (usuario, cuenta, cliente) y prueba que una no puede leer la de otra.
• Separa episodios (se agregan) de hechos (se reemplazan) y usa atributos fijos cuando puedas.
• Guarda la fuente, la fecha y la confianza de cada hecho.
• Recupera el estado actual por separado del historial que se le parece.
• Filtra los reemplazos y manda a revisión lo que el filtro no pueda decidir.
• Mide la recuperación y los reemplazos con tus propias conversaciones antes de confiar en un umbral, incluido el nuestro.

Pruébalo

• Sin instalar nada: el Playground corre SQL, Cypher y búsqueda vectorial en el navegador. La memoria de agentes necesita un modelo, así que esa parte corre en tu instalación.
• En tu máquina: descarga la Community Edition gratis (sin registro ni tarjeta) y ejecuta los pasos 1 a 5 en la interfaz web incluida.
• Más contexto: la base de datos para IA que corre en tu máquina.