Memoria de agente que de verdad recuerda: knowledge graphs y ensamblaje de contexto

El problema: modelos sin estado, conversaciones con estado

Te lo digo directo: un modelo de lenguaje no tiene memoria. Cada llamada es una hoja en blanco. La ilusión de un sistema que "se acuerda de ti" es pura ingeniería que ocurre fuera del modelo, antes de que el prompt siquiera se envíe.

Si haces mal esa ingeniería, te llevas los dos fallos clásicos. O el agente olvida lo que el usuario dijo tres turnos atrás, o metes todo el historial de la conversación en cada petición y ves cómo tu factura de tokens y tu latencia explotan mientras la relevancia cae. La verdadera memoria de agente es la disciplina de decidir, por petición, exactamente qué necesita ver el modelo y nada más.

La memoria no es una cosa que enciendes. Son cuatro mecanismos distintos con costes distintos y trabajos distintos, ensamblados en una sola ventana de contexto en el momento de la petición.

Esto lo corremos en producción en Exfinity, nuestra plataforma de comercio con AI multi-tenant, donde ocho agentes comparten una capa de memoria y conocimiento a través de miles de conversaciones. Esta guía es la arquitectura real, no un juguete. Para la vista de alto nivel de los sistemas agénticos, mira nuestra guía de sistemas de AI agéntica, y para ver cómo encaja el retrieval, nuestra guía de sistemas RAG empresariales. Esto es trabajo central de nuestros servicios de AI.

A quién le importa qué

Cuatro tipos de memoria

Antes de la arquitectura, el vocabulario. Estos cuatro mecanismos hacen trabajos distintos, y los sistemas en producción los usan todos.

El error de los juniors es tratar la memoria como un único blob de "historial de chat". El error que los seniors evitan es pagar por contexto que el modelo no necesita en este turno.

Ensamblaje de contexto: las siete capas

Cada petición en Exfinity pasa por un pipeline de ensamblaje de contexto que construye un array ordenado de mensajes inyectados antes del texto del usuario. Cada capa es condicional. Este es el corazón del sistema, así que aquí va el pipeline completo.

Dos decisiones de diseño importan aquí más que la lista en sí.

Primero, no todas las capas se disparan. La capa 4 solo corre cuando el grafo de un tenant tiene suficientes nodos para ser útil, y la capa 5 solo entra cuando un hilo es lo bastante largo como para necesitar resumen. No pagas por contexto que no necesitas.

Segundo, y esta es la decisión de seguridad: las capas que llevan datos producidos por otros usuarios nunca se inyectan como instrucciones de sistema. Las reglas de plataforma y el propio mensaje del usuario son las únicas voces con autoridad. Los insights del grafo, el historial compactado, los productos recuperados y los documentos recuperados van todos envueltos como datos no confiables e inyectados en el rol user, con los delimitadores del fence eliminados del contenido para que el texto inyectado no pueda romper el bloque. Volvemos al porqué en la sección de guardrails.

User message
   │
   ▼
[1] Platform rules      (system, always)
[2] Date context        (system, always)
[3] Tenant persona      (system, if configured)
[4] Graph insights      (untrusted-data, if graph is big enough)
[5] Compacted history   (untrusted-data, if thread is long)
[6] Product context     (system, if product-like query)
[7] Knowledge passages  (untrusted-data, if question-like query)
   │
   ▼
Assembled context ──▶ Agent ──▶ Model

Working memory: la plantilla en la que escribe el agente

Cargar los mensajes recientes para siempre sale caro. La working memory lo resuelve con una plantilla estructurada que el agente lee y escribe entre turnos. En vez de releer "tengo 200 euros para dos adultos el sábado que viene" del historial crudo en cada turno, el agente lo extrae una vez a una plantilla y carga con la plantilla.

<user_context>
preferences:
budget:
travel_dates:
group_size:
interests:
viewed_products:
current_intent:
</user_context>

Cuando el usuario dice un presupuesto y unas fechas, el agente escribe esos valores en los campos. En el siguiente turno, la plantilla se vuelve a cargar en el contexto, así que el agente recuerda sin que los mensajes originales estén presentes. Esto es dramáticamente más barato que cargar el historial completo, y sobrevive a la compactación. Los agentes que no necesitan un esquema rígido mantienen en su lugar un bloque de working memory libre.

La regla de diseño: pon los hechos duraderos y estructurados en la working memory, y deja que la ventana de mensajes crudos maneje el ida y vuelta inmediato. Nuestra guía de diseño de workflows de AI cubre cómo decidir qué va dónde.

Recuerdo semántico versus ventana reciente

Dos mecanismos cubren el historial de conversación, ajustados por agente.

La ventana reciente son los últimos N mensajes, cargados literales. Barata y siempre relevante para el intercambio inmediato.

El recuerdo semántico convierte el mensaje actual en un embedding y busca en el historial más antiguo del hilo mensajes pasados semánticamente similares, trayendo unas cuantas coincidencias más los mensajes alrededor de cada una. Así es como un agente recuerda algo que el usuario dijo veinte turnos atrás cuando vuelve a ser relevante, sin cargar los veinte turnos.

Cada agente ajusta esto de forma independiente. Un agente de reservas puede mantener una ventana reciente corta y un recuerdo poco profundo porque las reservas son de corto plazo. Un agente de recomendaciones mantiene un recuerdo más profundo porque el gusto se expresa en un arco más largo. El punto es que los ajustes de memoria son por rol, no globales. Nuestra guía de arquitectura multiagente cubre cómo los agentes especializados divergen en configuración.

// Config de memoria por agente: ventana reciente + recuerdo semántico
const bookingAgent = {
  memory: {
    lastMessages: 15,                       // ventana reciente literal
    semanticRecall: { topK: 3, messageRange: 2 }, // pasado similar + vecinos
    workingMemory: { enabled: true },
  },
};

const recommendationAgent = {
  memory: {
    lastMessages: 15,
    semanticRecall: { topK: 5, messageRange: 3 }, // recuerdo más profundo
    workingMemory: { enabled: true },
  },
};

El knowledge graph: memoria que cruza sesiones

Todo lo anterior está limitado a una conversación. El knowledge graph es memoria que sobrevive a la sesión y guarda patrones de todas las interacciones de un tenant. Es la capa que la mayoría de los equipos se salta, y es donde el contexto deja de ser "lo que acabas de decir" y pasa a ser "lo que tiende a ser verdad aquí".

El grafo es por tenant, con nodos tipados y aristas tipadas.

Los tipos de nodo incluyen product, query, response, user, document, tool call, booking y competitor price. Los tipos de arista incluyen searched-for, answered-by, booked, viewed, cited, similar-to, asked-about, used-tool y priced-against.

query ──searched_for──▶ product
query ──answered_by──▶ response ──cited──▶ document
user  ──booked──▶ product
user  ──viewed──▶ product
product ──similar_to──▶ product

Ruta de escritura. Tras cada respuesta del agente, un job fire-and-forget registra la interacción: un nodo query con el mensaje del usuario limpio de datos personales, un nodo response con la respuesta limpia, una arista answered-by ponderada por el feedback (un pulgar arriba la refuerza, un pulgar abajo la debilita), y un nodo product más una arista searched-for por cada producto mencionado. Corre en asíncrono, así que nunca añade latencia a la respuesta.

Ruta de lectura. Durante el ensamblaje de contexto (capa 4), el grafo solo produce insights cuando tiene suficientes nodos para ser significativo. Dos consultas corren en paralelo: los productos más buscados, y las preguntas recientes sin buena respuesta. Eso se convierte en un bloque compacto de datos no confiables que le dice al agente qué le importa de verdad a los usuarios de ese tenant.

// Ruta de lectura: solo mostrar insights cuando el grafo es sustancial
async function buildGraphInsights(tenantId) {
  const stats = await graph.getStats(tenantId);
  if (stats.totalNodes < GRAPH_MIN_NODES_FOR_INSIGHTS) return null;

  const [popular, unanswered] = await Promise.all([
    graph.getPopularProducts(tenantId, 5),      // los más buscados
    graph.getUnansweredQuestions(tenantId, 3),  // huecos por cerrar
  ]);
  return fenceUntrusted(formatInsights(popular, unanswered));
}

Evitar que crezca para siempre. Dos jobs de mantenimiento importan. El decaimiento de aristas aplica un decaimiento exponencial por edad a los pesos de las aristas, para que las interacciones viejas pierdan relevancia, y recalcula desde el peso inicial en cada ejecución, así que es idempotente en vez de acumulativo. La purga de nodos borra los nodos transitorios que pasan un corte y cae en cascada a las aristas huérfanas, mientras que los nodos duraderos como los productos persisten.

weight = initial_weight * exp(-ln(2) / halfLifeDays * ageDays)   # floored at 0.1

Borrado. Para una solicitud de borrado GDPR, el grafo resuelve los nodos query de un usuario por hilo, sigue las aristas answered-by hasta sus nodos response, y borra esos nodos más cada arista que los toca. Los nodos product compartidos nunca se borran. El borrado dirigido en todos los stores de memoria es un requisito duro, no un extra, y cubrimos el lado de cumplimiento en nuestra guía de GDPR y AI.

Confianza y auto-learn: memoria que mejora

Una memoria que solo acumula es un pasivo. Una memoria que mejora es un activo. El puente es una puntuación de confianza en cada respuesta y un bucle de revisión humana que convierte las respuestas de baja confianza en conocimiento nuevo.

La confianza es un compuesto de cuatro factores, ponderados.

const composite =
  retrieval * 0.4 + policy * 0.2 + completeness * 0.2 + memory * 0.2;

Cuando una respuesta puntúa por debajo de un umbral por tenant, se captura como candidata de aprendizaje y se clasifica en una clase de fallo: fallo de retrieval, bloqueo de policy, una señal de alucinación como una fecha pasada presentada como futura, feedback negativo, etcétera. Un humano revisa la candidata en un dashboard. Al aprobarla, la respuesta se formatea como documento de conocimiento, se convierte en embeddings y se publica de vuelta en la base de conocimiento, para que la misma pregunta recupere una buena respuesta la próxima vez. El umbral incluso se autoajusta: si los revisores aprueban casi todo, baja para capturar más; si rechazan mucho, sube para cortar el ruido.

Este es el patrón de human-in-the-loop aplicado a la propia capa de memoria, y es lo que separa un sistema que se degrada de uno que se capitaliza. Nuestra guía de observabilidad de AI cubre las métricas que miras para saber cuál de los dos está pasando.

Guardrails: prompt injection y datos no confiables

Este es el modo de fallo que introduce la memoria: texto que un usuario guardó, o que sobrevivió a la compactación, puede intentar secuestrar la sesión de otro usuario. Si el contenido recuperado o los insights del grafo se inyectaran como instrucciones de sistema, un documento malicioso podría decir "ignora tus reglas" y ser obedecido.

La defensa es una separación estricta. Solo las reglas de plataforma y la petición del propio usuario final tienen autoridad. Todo lo demás, pasajes recuperados, datos de producto, insights del grafo, historial compactado, se declara dato no confiable y se inyecta en el rol user dentro de un fence, con los delimitadores del fence eliminados del contenido para que el texto inyectado no pueda cerrar el bloque antes de tiempo y parecer que escapa. Se trata como información a considerar, nunca como órdenes a seguir.

Esto importa más a medida que la memoria crece, porque la superficie de "texto que otras personas hicieron existir" crece con ella. Nuestras guías de gobernanza de AI y modos de fallo de AI profundizan en la defensa de sistemas agénticos.

Coste: la memoria no es gratis

Cada capa que añades son tokens, y los tokens son latencia y dinero. Tres controles lo mantienen acotado.

La compactación resume los mensajes antiguos cuando un hilo se alarga, reemplazando el historial crudo por un resumen estructurado compacto y manteniendo el presupuesto de tokens plano mientras las conversaciones crecen. El prompt caching sirve el prefijo de sistema estático desde la caché del proveedor en llamadas repetidas, así que no vuelves a pagar las mismas reglas en cada turno. Y los techos duros por turno sobre pasos de razonamiento, llamadas a herramientas y tokens de salida evitan que un solo turno se desboque.

Cubrimos los trade-offs de coste y latencia en toda la stack en nuestra guía de latencia y precisión de AI.

Por dónde empezar

Añadir memoria a un agente, en orden de retorno:

1. Primero la ventana reciente. Carga los últimos N mensajes. Solo esto ya hace que un agente se sienta coherente.
2. Después la working memory. Añade una plantilla estructurada para hechos duraderos. Barato, alto impacto.
3. Recuerdo semántico cuando los hilos se alargan. Trae de vuelta los mensajes antiguos relevantes en vez de todos.
4. Compactación cuando el coste muerde. Resume el historial viejo cuando los hilos ya son largos.
5. Un knowledge graph cuando tienes volumen. Solo vale la pena cuando tienes suficientes interacciones para que emerjan patrones.

No construyas el grafo primero. Solo se gana su lugar con volumen. Nuestra metodología está construida alrededor de este tipo de entrega por etapas, y nuestros equipos de software a medida y consultoría construyen estas capas con los clientes. Empieza en contacto o pide un presupuesto.

Las formas típicas en que esto sale mal

1. Volcar todo el historial en cada turno. El coste y la latencia explotan, la relevancia cae. Ensambla, no vuelques.
2. Ajustes de memoria globales. Agentes distintos necesitan ventanas y recuerdos distintos. Ajusta por rol.
3. Inyectar texto recuperado como instrucciones de sistema. Eso es un agujero de prompt injection. Enciérralo como dato no confiable.
4. Un grafo sin decaimiento ni purga. Crece sin límite y el ruido viejo ahoga la señal. Añade jobs de mantenimiento.
5. Sin ruta de borrado. Si no puedes borrar la memoria de un usuario, no puedes cumplir una solicitud GDPR. Diseña el borrado desde el principio.
6. Acumular sin mejorar. Añade una puntuación de confianza y un bucle de revisión, o el sistema solo se hace más grande, no mejor.

Quién construye esto

Oronts es una empresa de software liderada por su fundador, con sede en Múnich. Refaat Al Ktifan, nuestro fundador y arquitecto de soluciones, lidera un equipo senior de backend, datos y AI. La arquitectura de esta guía es la capa de memoria real detrás de Exfinity, que corremos contra nosotros mismos antes de llevar estos patrones a los clientes. Diseñamos el pipeline de contexto, construimos las capas de memoria y grafo, y te entregamos un sistema que puedes operar y auditar. Mira nuestras páginas de servicios y soluciones para el cuadro completo.

Conclusiones

• Un modelo no tiene memoria. Todo es ensamblaje que ocurre antes del prompt.
• Usa los cuatro mecanismos: ventana reciente, recuerdo semántico, working memory y un knowledge graph.
• Ensambla el contexto en capas condicionales, y nunca inyectes datos de otros usuarios como instrucciones de sistema.
• Un knowledge graph da memoria que cruza sesiones, pero necesita decaimiento, purga y una ruta de borrado.
• Añade una puntuación de confianza y un bucle de revisión humana para que la memoria mejore en vez de solo acumular.

La mejor memoria de agente es invisible. El usuario se siente entendido, la factura de tokens se mantiene plana, y un regulador puede ver cómo los datos de un usuario se borran cuando lo pide. Eso es ingeniería, no magia.

¿Estás construyendo un agente que necesita recordar, de forma segura y barata? Cuéntanoslo en contacto o pide un presupuesto acotado.