[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Memoria de agente de IA: Estado tipado guiado por esquema para sistemas de ejecución prolongada
Los agentes que operan durante mucho tiempo suelen recuperar datos obsoletos, ya que la memoria semántica habitual no dispone de reglas para determinar qué valor es el actual.
Cuando un usuario modifica la fecha límite del pasaporte de 15 de julio a 30 de junio, la búsqueda vectorial puede recuperar ambas informaciones. Una capa de memoria con estado debe registrar que el valor del 30 de junio sustituye al anterior.
En resumen: Trate la memoria duradera del agente como estado de aplicación tipado. Extraiga los candidatos de memoria a través de un límite de salida estructurada, almacene los registros con ámbito de tenant, ventanas de validez, información sobre sustitución, origen y versionado de esquemas, y luego recupere la versión más reciente en la ruta de lectura. Reserva la búsqueda vectorial para búsquedas aproximadas. Lea los datos mutables desde registros actuales y delimitados.
La trampa de la ventana de contexto
La ventana de contexto es la entrada disponible para una llamada al modelo. Una aplicación puede pasar mensajes a llamadas posteriores, pero la política de la aplicación debe decidir qué datos antiguos siguen siendo válidos y quién puede acceder a ellos.
Los agentes de larga duración necesitan recordar preferencias, estado de tareas, datos de clientes, decisiones sobre herramientas, notas de cumplimiento y errores anteriores. La solución sencilla consiste en añadir resúmenes o guardar notas antiguas en un almacenamiento vectorial. Esto funciona hasta que uno de los datos recordados cambia.
Entonces el agente tiene dos fechas límite de pasaporte, dos formatos preferidos o dos decisiones de proyecto. La búsqueda semántica puede recuperar ambos. Un resumen podría sobrescribir uno de ellos. Un contexto extenso podría incluir el dato obsoleto junto al activo. Estos diseños recuperan texto sin garantizar que el valor actual se aplique efectivamente.
El contrato debe responder a preguntas concretas:
- ¿Qué es válido ahora?
- ¿Qué era válido el 2 de junio?
- ¿Quién lo dijo?
- ¿A qué tenant pertenece?
- ¿Qué dato anterior fue reemplazado por este?
- ¿Puedo eliminarlo o hacer que caduque?
Memoria de agente guiada por esquema (SGAM) almacena estas respuestas como campos y relaciones, en lugar de dejarlas implícitas en texto narrativo.
Qué significa SGAM
Tres conceptos con nombres similares definen el alcance de SGAM.
Diálogo guiado por esquema (SGD) se refiere al conjunto de datos de diálogos orientados a tareas de Google de 2019. Su esquema describe APIs de servicio, intenciones y slots, de modo que un modelo de diálogo pueda seguir el estado de servicios que no ha visto antes. Constituye un precedente útil para el seguimiento basado en esquemas, aunque su ámbito se limita a servicios de diálogo.
Memoria guiada por esquema (SGM) es el término utilizado por Mei et al. en According to Me: Long-Term Personalized Referential Memory QA. En dicho artículo se comparan los datos de Memoria Descriptiva (DM) en formato de texto libre con elementos de memoria clave-valor con esquema fijo. Ambas representaciones contienen la misma información de origen, pero en estructuras diferentes.
En este artículo, utilizo Memoria de agente guiada por esquema (SGAM) para referirme a un patrón de ingeniería en el que los esquemas regulan las operaciones de escritura, actualización, recuperación y eliminación. El esquema define el estado de la aplicación y su ciclo de vida.
ATM-Bench demuestra por qué es importante esta representación. Utiliza aproximadamente cuatro años de datos personales extraídos de correos electrónicos, imágenes y videos. Las preguntas requieren referencias personales, ubicación, múltiples pruebas y actualizaciones a lo largo del tiempo. El rendimiento disminuye con este enfoque difícil, mientras que SGM mejora respecto a DM, ya que el recuperador puede acceder directamente a campos como tiempo, origen, ubicación, entidades y etiquetas.
SGM frente a DM aborda una cuestión de almacenamiento: ¿debe la memoria permanecer como texto libre o utilizar campos nombrados? Un agente en producción enfrenta otro problema antes del almacenamiento: debe razonar a partir de una conversación no estructurada para proponer una actualización en la memoria. Reasoning Guiado por Esquema (SGR) define ese camino de decisión: inspeccionar las pruebas, identificar el sujeto y el atributo, verificar si el hecho modifica el estado existente y, finalmente, generar una propuesta de escritura. SGAM aplica las reglas de almacenamiento y ciclo de vida tras esa llamada al modelo.
Separar la extracción del modelo de la propiedad de la memoria
La escritura en la memoria atraviesa tres capas. Salida Estructurada (SO) impone la forma del objeto propuesto. Reasoning Guiado por Esquema (SGR) codifica los pasos y el orden que el modelo debe seguir para llegar a dicho candidato. Memoria de Agente Guiada por Esquema (SGAM) gestiona dicho candidato como estado duradero después de la llamada al modelo.
Un veredicto, ruta o plan suele caducar con la solicitud actual. Otra ejecución puede leer un candidato de memoria días después o utilizarlo para elegir una llamada a herramienta. Esa vida útil más prolongada exige reglas de almacenamiento que SGR no proporciona.
SGR restringe una sola llamada al modelo al definir su topología de razonamiento. En el caso de una escritura en la memoria, el esquema podría requerir pruebas de origen, un sujeto y atributo normalizados, una comparación con el estado actual y, solo entonces, la actualización propuesta. Pydantic o JSON Schema describen ese camino. La Salida Estructurada nativa del proveedor o un entorno de decodificación guiado como XGrammar impiden que el modelo omita campos o devuelva una forma diferente.
El esquema no puede garantizar una conclusión correcta. Sin embargo, hace explícito y observable el camino de decisión necesario, incluyendo las pruebas y comparaciones que dieron lugar al candidato.
SGAM decide qué ocurre una vez que el objeto existe. ¿Debe almacenarse? ¿Sustituye a un hecho anterior? ¿Qué usuario puede verlo? ¿Es actual o histórico? ¿Qué episodio de origen lo respalda?
La tabla detalla la propiedad y el modo de fallo de cada capa:
| Dimensión | SO | SGR | SGAM |
|---|---|---|---|
| Propósito | Devolver un objeto que cumpla con un esquema | Guiar al modelo por un camino de razonamiento predefinido | Gestionar la memoria persistente tras la llamada al modelo |
| Alcance | Una respuesta generada | Un camino de razonamiento y decisión en una llamada al modelo | Registros utilizados entre llamadas, sesiones e ejecuciones |
| Rol del esquema | Define los campos de salida, tipos y valores permitidos | Define las etapas intermedias de razonamiento y la decisión final | Define los registros almacenados, relaciones y su ciclo de vida |
| Aplicación | Bloquea la decodificación de salidas inválidas según el esquema | Utiliza SO para exigir cada etapa declarada y la decisión final | Validación de aplicaciones, restricciones de base de datos y reglas de conflicto |
| Duración | La llamada actual, a menos que la aplicación almacene el objeto | El rastro de razonamiento suele descartarse tras tomar la decisión | Persiste hasta que se actualice, expire o se elimine |
| Modo de fallo | Forma válida con significado incorrecto | Los pasos requeridos están presentes, pero el razonamiento puede seguir siendo erróneo | Estado obsoleto, contaminado, sin alcance o no verificable |
En el camino de escritura, la secuencia es:
SGR reasoning schema + Structured Output -> candidate write -> SGAM policy and persistence
El siguiente fragmento ilustrativo de memory_models.py define el objeto que se pasa desde la extracción al servicio de escritura de SGAM:
from datetime import datetime
from pydantic import BaseModel, Field
class MemoryDelta(BaseModel):
tenant_id: str = Field(description="Isolation boundary, e.g. acme")
subject: str = Field(description="Normalized entity ID, e.g. mira")
attribute: str = Field(description="Property being updated")
value: str = Field(description="New value")
valid_from: datetime
source_episode_id: str
MemoryDelta muestra lo que el modelo ha extraído. El servicio de escritura de SGAM decide aún si rechazarlo, fusionarlo o almacenarlo.
Los caminos de escritura y lectura tienen funciones distintas
SGAM cuenta con un camino de escritura y uno de lectura. Solo el camino de escritura modifica el estado almacenado. El camino de lectura selecciona los registros para la solicitud actual.
El flujo de ingestión corresponde al camino de escritura:
- Capturar un episodio bruto a partir de mensajes, resultados de herramientas o eventos empresariales.
- Extraer candidatos estructurados mediante la salida tipada.
- Validar el esquema y rechazar las escrituras mal formadas.
- Resolver conflictos, cerrar hechos obsoletos y conservar la procedencia.
- Guardar el registro en el almacenamiento de SGAM.
El flujo de solicitud corresponde al camino de lectura:
- Partir de la pregunta del usuario.
- Determinar si se necesita el estado actual o el estado en un momento específico.
- Filtrar por arrendatario, tipo de memoria, tema, atributo y ventana de validez.
- Añadir expansión vectorial o gráfica solo si la búsqueda del estado exacto no es suficiente.
- Compilar el contexto mínimo necesario para el modelo.
Lea ese diagrama de izquierda a derecha en dos carriles. El carril superior escribe en la memoria, mientras que el inferior la lee. Ambos utilizan el mismo almacenamiento.
Qué debe incluirse en un esquema de memoria
Un registro mínimo de SGAM requiere más que text.
tenant_id
memory_id
subject
attribute
value
memory_type
schema_version
valid_from
valid_to
supersedes_memory_id
source_episode_id
confidence
retention_policy
Con estos campos, un nuevo plazo de pasaporte puede sustituir al anterior sin borrar el historial. La misma tabla permite responder consultas tanto actuales como puntuales en el tiempo, y luego rastrear el resultado hasta su episodio de origen. schema_version facilita las migraciones, mientras que retention_policy indica a los procesos de eliminación qué otros elementos deben eliminarse también.
Se debe utilizar RAG para recuperar documentos y SGAM para gestionar el estado mutable. La búsqueda vectorial sigue siendo necesaria en el sistema para la recuperación difusa, el clustering y la expansión de resultados. El valor actual de mira.passport_deadline debe provenir de un registro de memoria delimitado, y no del primer fragmento que aparezca en la clasificación.
Ejemplo de hecho obsoleto
Considérese un seguimiento sintético de dos episodios representado mediante una línea base DM y un libro mayor SGAM:
e1: Mira prefers concise answers. Her passport deadline is 2026-07-15.
e2: Mira corrected the deadline. It is now 2026-06-30.
Una línea base DM almacena ambos episodios como texto libre, por lo que la búsqueda de texto puede devolver e1, ya que contiene las palabras adecuadas. SGAM extrae un hecho estructurado de cada episodio, indexado por arrendatario, tema y atributo. Debería devolver e2 como estado actual y conservar e1 para consultas históricas.
La función siguiente corresponde al código del camino de escritura de SGAM. Estaría ubicada en un módulo de almacenamiento como sgam_store.py. DM no cuenta con un equivalente, ya que no mantiene una fila actual por atributo. Antes de que el llamante inserte un reemplazo, esta función cierra la fila actual:
def close_previous_fact(db: sqlite3.Connection, fact: MemoryFact) -> int | None:
row = db.execute(
"""
select fact_id
from memory_facts
where tenant_id = ?
and subject = ?
and attribute = ?
and valid_to is null
order by valid_from desc
limit 1
""",
(fact.tenant_id, fact.subject, fact.attribute),
).fetchone()
if not row:
return None
db.execute(
"update memory_facts set valid_to = ? where fact_id = ?",
(fact.valid_from, row["fact_id"]),
)
return int(row["fact_id"])
Cuando llega e2, la función establece valid_to en el hecho extraído de e1 con la marca de tiempo de e2. A continuación, el llamante inserta el nuevo hecho con un valid_to abierto. DM no dispone de un paso de actualización similar, por lo que el texto antiguo puede seguir superando en prioridad a la corrección.
Realizar consultas sobre plazos actuales e históricos contra ambas representaciones produce resultados diferentes:
Naive text memory:
returned episode: e1 -> passport deadline is 2026-07-15
SGAM current state:
mira.passport_deadline = 2026-06-30
valid_from=2026-06-03T10:00:00Z, source=e2
SGAM point-in-time state:
on 2026-06-02, mira.passport_deadline = 2026-07-15
En entornos de producción, se debe combinar esta transacción con una extracción estructurada en el camino de escritura. La transacción de base de datos actualiza la validez temporal, mientras que el modelo extrae un hecho candidato pero no decide qué fila almacenada permanecerá como la actual.
Las elecciones de almacenamiento siguen el patrón de recuperación
Los proyectos emplean diversos nombres para las partes de este patrón: almacenes de memoria, grafos de contexto, perfiles, almacenes a largo plazo, RAG basado en grafos y agentes con estado.
| Herramienta o framework | Capa de almacenamiento principal | Mecanismo de estado temporal | Mecanismo de esquema | Nicho práctico |
|---|---|---|---|---|
| Zep / Graphiti | Neo4j, FalkorDB, Neptune; soporte también para Kuzu legado | Intervalos de validez de los hechos junto con la procedencia del episodio fuente | Tipos de entidades y aristas en Pydantic, aristas temporales, información de procedencia | Memoria de grafos temporales |
| LangGraph / LangMem | Almacenes de LangGraph, almacenes basados en Postgres | Marcas de tiempo y campos gestionados por la aplicación dentro de los registros del almacén | Almacenes JSON más extracción de perfiles o colecciones mediante Pydantic | Aplicaciones de agente ya desarrolladas sobre LangGraph |
| Mem0 | Stack gestionado; backends Valkey / Redis / vector en configuraciones OSS | Actualizaciones en memoria; la política temporal sigue siendo gestionada por la aplicación | Tipos de memoria, categorías personalizadas, prompts de extracción | Servicio de memoria para usuarios, agentes y sesiones |
| Letta / MemGPT | Estado del agente y bloques de memoria respaldados por base de datos | Bloques editables sin intervalos de validez a nivel de campo | Bloques de memoria etiquetados y editables | Agentes con estado persistente y gestión de contexto al estilo SO |
| Cognee | Backends de tipo grafo, vectorial y relacional | El historial depende de la ontología y del backend seleccionado | Extracción y validación orientadas a la ontología | Memoria de grafos de conocimiento empresarial |
| LlamaIndex property graph | Almacenes de tipo grafo de propiedades además de almacenes vectoriales | Los campos de tiempo dependen del esquema del grafo y del almacén | SchemaLLMPathExtractor con entidades y relaciones permitidas | Extracción de grafos a partir de documentos y trazas |
Graphiti es una implementación concreta de código abierto de memoria relacional y temporal. Permite rastrear los cambios en los hechos, conservar referencias a los episodios fuente y soportar búsquedas híbridas. LangGraph separa los puntos de control entre hilos de las memorias compartidas entre ellos. Mem0 encapsula las operaciones de memoria como un servicio gestionado. Letta emplea bloques de contexto editables en lugar de mecanismos SGAM a nivel de campo, pero sigue tratando el estado del agente como datos persistentes.
Comience por el modelo de datos. Si la operación principal es la búsqueda exacta de hechos, suele ser suficiente contar con una tabla relacional con payloads en JSON, columnas de validez, índices por tenant y un componente vectorial adicional. Agregue un grafo solo cuando la navegación entre relaciones forme parte de las funcionalidades del producto, y no porque una demostración con grafo parezca impresionante.
Construir la ruta de escritura antes que el grafo
Primero se debe definir qué datos puede recordar el producto. La elección entre grafo y vectores se aborda posteriormente.
Un agente de soporte podría recordar el nivel de la cuenta, los casos abiertos y las preferencias de contacto persistentes. No debería convertir cada consulta frustrada en un registro permanente en el perfil. Un agente de programación podría recordar las convenciones del repositorio y las tareas pendientes. Tampoco debería conservar una nota privada indefinidamente solo porque esa nota fue consultada una vez.
Se debe comenzar con la ruta de escritura y tratar la memoria como una pequeña mutación de estado:
- Designar el tipo de memoria, el sujeto, el ámbito del inquilino y la clase de retención.
- Extraer los registros candidatos mediante una salida estructurada.
- Validar el payload con Pydantic o con la capa de esquemas que ya utiliza el stack.
- Resolver conflictos antes de realizar la inserción, incluyendo determinar si el nuevo registro sustituye al anterior.
- Mantener un puntero de origen al episodio original, al resultado de la herramienta, al archivo, a la incidencia o a la confirmación del usuario que generó el registro.
- Incluir la versión del esquema junto a cada registro, en lugar de dejarla únicamente en el código de la aplicación.
El primer almacenamiento SGAM puede ser una tabla relacional con una columna JSON y algunos índices. El grafo resulta útil cuando el producto necesita recorrer relaciones como cliente-cuenta, cuenta-política, tarea-artefacto o proyecto-Decisión.
Ruta rápida y escrituras en segundo plano
La extracción inmediata tiene sentido cuando la siguiente interacción depende de la nueva memoria. Si el usuario indica “recuerda que prefiero respuestas breves”, el sistema no necesita una tarea nocturna para comportarse de forma distinta.
La mayoría de las interacciones no requieren una escritura inmediata. Se deben guardar los datos brutos del episodio junto con metadatos del inquilino, sesión y herramienta, y luego dejar que un proceso en segundo plano extraiga los registros candidatos más tarde. Mediante consolidación basada en recurrencias, este proceso almacena temporalmente señales débiles y eleva un hecho a estado activo solo después de que aparezcan evidencias similares repetidas o el usuario lo confirme. Esto genera un retraso en la actualización de la información. Es aceptable en casos como “el usuario solicita con frecuencia exportaciones en CSV”, pero riesgoso en situaciones como “el cliente cambió la dirección de entrega”.
Se debe mantener la ruta de lectura como algo determinista. Primero se deben aplicar restricciones por ámbito del inquilino y validez, y luego utilizar búsquedas difusas únicamente cuando puedan aportar contexto útil.
- Filtrar por inquilino, tipo de memoria y ventana de validez.
- Obtener primero el estado estructurado exacto, y luego los vecinos semánticos.
- Utilizar expansión vectorial o gráfica para obtener evidencias complementarias, entidades relacionadas y ejemplos, pero no como fuente autorizada de los hechos actuales.
- Componer el contexto mínimo necesario para responder a la pregunta.
Se debe considerar la migración de esquemas como un cambio de producto, ya que altera lo que el agente puede recordar, citar o eliminar. También puede cambiar qué hechos históricos se consideran actuales. Es necesario planificar scripts de migración, procesos de relleno, períodos de lectura dual y comportamientos de eliminación dentro de la misma versión del producto.
Cuándo merece la pena la complejidad de SGAM
Utilizar SGAM cuando los hechos pueden cambiar con el tiempo:
- Preferencias del usuario que pueden actualizarse o revocarse.
- Datos de clientes o cuentas que requieren auditoría.
- Estado de tareas en asistentes de ejecución prolongada.
- Memoria de proyectos de agentes de programación.
- Estado compartido entre múltiples agentes.
- Notas de cumplimiento donde es importante conocer el origen de los datos.
- Preguntas temporales como “¿qué creíamos antes de la migración?”
SGAM resulta un exceso cuando la memoria es de corta duración, se utiliza con fines exploratorios o su recálculo es económico. Si el agente solo necesita unos pocos pasos de continuidad, un punto de control y un historial de mensajes reducido son suficientes. La verificación de calidad de documentos estáticos puede requerir únicamente RAG. Y si el dominio es tan inestable que el esquema cambia a diario, la memoria tipada ralentizará al equipo.
Lista de verificación de evaluación
Se debe evaluar tanto el ciclo de vida de la memoria como la respuesta final. Un sistema puede generar una respuesta plausible incluso después de haber escrito un hecho incorrecto, recuperado uno obsoleto o traspasado los límites de un tenant.
Utilizo la misma división por fases que en mi artículo de evaluación de RAG. Se miden las fases en las que puede producirse un fallo, en lugar de limitar la evaluación únicamente al texto generado. La disciplina de seguimiento de el artículo de evaluación de agentes también es aplicable, ya que los errores de memoria suelen manifestarse en el historial de ejecución antes de llegar a la respuesta.
Probaría SGAM mediante reproducción. Se introduce una secuencia fija de episodios en el escritor de memoria, se inspecciona el registro tras cada paso relevante y luego se formulan preguntas sobre el estado actual y en un momento específico basadas en el almacenamiento resultante.
| Capa | Fallo que se busca detectar | Métricas de medición |
|---|---|---|
| Extracción de escritura | El agente omitió un hecho, lo inventó o generó una estructura inválida | Tasa de escrituras válidas según el esquema, precisión/recuerdo de extracción, cobertura de episodios de origen |
| Manejo de conflictos | Un hecho obsoleto permanece vigente o un hecho antiguo válido es sobrescrito | Correctitud en la supresión, tasa de duplicados, corrección en la invalidación de hechos obsoletos |
| Aislamiento y políticas | La memoria se filtra entre usuarios o sobrevive más allá de su ventana de política | Fallas en el aislamiento por tenant, corrección en las eliminaciones, cumplimiento de reglas de retención |
| Recuperación de lectura | Existe el registro correcto, pero el lector no lo obtuvo | Precisión del estado actual, precisión en un momento específico, recall@k entre los registros de memoria |
| Anclaje de la respuesta | La respuesta utiliza la memoria sin soporte o cita una fuente incorrecta | Verificación de que la afirmación esté respaldada por episodios de origen, precisión en las citaciones, corrección en la resolución de conflictos |
| Operaciones | La ruta de acceso a la memoria es demasiado lenta, obsoleta o costosa | Latencia de escritura p95, retraso en la actualización, latencia de lectura, costo por consulta |
Marcadores de referencia como LoCoMo, LongMemEval y ATM-Bench ofrecen casos de prueba públicos. No sustituyen a un conjunto de pruebas específico para el dominio. Un asistente de programación, un bot de soporte al cliente y un copiloto de cumplimiento requieren esquemas, filtros, reglas de retención y pruebas de fallo diferentes.
Precauciones
SGAM es mi denominación para un patrón específico, no para un estándar universal. Los proyectos existentes abordan el problema de forma distinta. LangGraph memory y LangMem describen mecanismos de almacenamiento a corto y largo plazo, perfiles, colecciones, operaciones en rutas críticas y gestores de memoria en segundo plano. Zep Graphiti emplea el término “gráfico de contexto temporal”. Letta permite persistir bloques de memoria editables, mientras que Mem0 ofrece una capa de memoria gestionada. Microsoft GraphRAG, los gráficos de propiedades de LlamaIndex y Cognee modelan partes del problema como gráficos de conocimiento.
Un perfil de usuario, un registro de episodios, un gráfico de documentos y un bloque de memoria editable por el agente resuelven problemas diferentes de recuperación y actualización. Reservo SGAM para la memoria duradera que representa el estado actual de la aplicación, por lo que requiere esquema, validación, trazabilidad, gestión de conflictos, políticas de retención y migración.
La memoria tipada puede seguir siendo errónea. Un esquema facilita la inspección de escrituras defectuosas, pero no garantiza su fiabilidad. Sigue siendo necesario contar con confianza en las fuentes, confirmación del usuario para datos sensibles, políticas de gestión de conflictos, procedimientos de eliminación y monitoreo continuo.
La migración de esquemas implica trabajo adicional. Una vez que la memoria pasa a ser parte del estado del sistema, se deben gestionar la versióning, los rellenos retroactivos, los registros antiguos y el comportamiento de eliminación. Si se omite este proceso, los registros antiguos sobrevivirán a las políticas semánticas o de retención que los originaron.
Referencias
- According to Me: Long-Term Personalized Referential Memory QA - Artículo de Mei et al. que presenta ATM-Bench y Schema-Guided Memory.
- Towards Scalable Multi-Domain Conversational Agents: The Schema-Guided Dialogue Dataset - Artículo de Rastogi et al. sobre el conjunto de datos SGD.
- LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory - Prueba de rendimiento de Wu et al. para evaluar capacidades de memoria a largo plazo.
- Graphiti: Build Temporal Context Graphs for AI Agents
- Zep: A Temporal Knowledge Graph Architecture for Agent Memory
- Mem0 Platform Overview
- Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
- LangGraph Memory Overview
- LangGraph Persistence
- LangMem documentation
- Letta: Introduction to Stateful Agents
- Microsoft GraphRAG documentation
- LlamaIndex: Using a Property Graph Index
- Cognee Documentation
- Pydantic model validation docs
- Python sqlite3 documentation