Diseñando la memoria de una organización para sus agentes de IA

Ayer construimos el conocimiento estable. Hoy construimos lo que el agente
usa a diario: su memoria. Y «diseñar memoria» no es «elegir una base de
datos». Es decidir qué se retiene, qué se consolida, qué expira y qué se
borra — porque una memoria que no se gestiona se convierte en un
vertedero que el agente consulta con confianza.

Introducción

Ayer asentamos la capa de conocimiento: los datos, la semántica, la
ontología, las entidades, el grafo y el RAG, integrados. Esa es la memoria
estable de la organización.

Pero un agente no solo consulta conocimiento estable. A diario ocurren
cosas: conversaciones, decisiones, eventos, incidencias, correcciones. Y el
agente tiene que recordarlas, de forma selectiva, durante el tiempo que
importan. Eso es la memory architecture, y es el tema de hoy.

El problema

Una aseguradora ha desplegado un agente de claims (gestión de siniestros)
sobre su capa de conocimiento. El agente consulta bien las pólizas, los
endosos y las reglas. Pero el equipo de siniestros empieza a quejarse:

• «El agente no recuerda que este siniestro ya se visitó en dos
  ocasiones. Cada vez que le pregunto, vuelve a proponer una visita, como si
  fuera la primera.»
• «Propuso un anticipo de pago que ya se hizo el mes pasado. Tuvo que
  pararlo un humano.»
• «Cuando un siniestro lleva meses, el agente trata cada consulta como si
  fuera nueva: no sabe qué se ha hecho, qué se ha prometido al asegurado ni
  qué falta.»

El patrón: el agente tiene conocimiento, pero no memoria operativa.
Sabe qué es un siniestro (conocimiento estable), pero no recuerda qué ha
pasado con este siniestro concreto (memoria episódica), ni qué se ha
decidido (memoria de decisiones), ni qué se ha comprometido con el
asegurado.

El resultado es un agente que repite acciones, olvida promesas y empieza
cada caso de cero. Y en un dominio como siniestros, donde la confianza del
cliente se juega en la coherencia a lo largo de meses, eso es inaceptable.

El concepto

La memory architecture es el diseño de cómo se combinan los distintos
almacenes de memoria que el agente necesita, y las reglas que gobiernan qué
entra, qué se conserva, cuánto tiempo, y cómo se consolida o expira.

Se apoya en las tipologías del día 9, pero las aterriza como
arquitectura, con cuatro decisiones de diseño:

1. Qué almacenes existen y para qué.
   – Memoria de trabajo: el estado de la tarea actual (se borra al
   terminar).
   – Memoria episódica: los eventos y conversaciones, indexados por
   tiempo y por entidad («lo que pasó con el siniestro S-2026-007»).
   – Memoria semántica: los hechos generalizados y estables («los
   siniestros de este tipo se pagan con depreciación»).
   – Memoria procedural: los procedimientos y políticas operativas.
   – Memoria organizacional: las decisiones institucionales y lecciones.
   – Knowledge base / RAG: el conocimiento estable en prosa (día 8, 11).
   – Knowledge graph: las relaciones estructuradas (día 7, 11).
   – Eventos: el stream de lo que ocurre en la operación (nuevos
   siniestros, pagos, visitas, notas).

2. Qué se retiene (ingesta). No todo lo que pasa merece memoria. Se
   decide qué tipos de evento se graban (decisiones, compromisos,
   acciones ejecutadas, correcciones) y con qué detalle.

3. Cómo se consolida (episodio → semántico). Los episodios puntuales se
   destilan en hechos generales cuando el patrón se repite. «Se pagó el
   siniestro X con depreciación» (episodio) → «los siniestros de este tipo
   se pagan con depreciación» (semántico). Esta transición es la que convierte
   memoria en conocimiento, y hay que hacerla con curaduría, no al azar.

4. Cuánto dura (retención y expiración). Cada tipo de memoria tiene una
   vida útil: la memoria de trabajo dura la tarea; la episódica de un
   siniestro dura hasta que se cierra (y luego pasa a archivo); la
   semántica dura hasta que se la corrige; la procedural dura hasta que se
   revisa. Una memoria sin expiración es un vertedero, y un agente que
   consulta un vertedero da respuestas del pasado con la confianza del
   presente.

La decisión más importante, y la que separa una memoria útil de un
vertedero, es la consolidación con curaduría: decidir qué episodio se
convierte en conocimiento, y quién lo aprueba. Sin ella, la memoria
semántica se llena de «aprendizajes» que son ruido.

Arquitectura

En el diagrama de la serie, la memory architecture es la columna de la
recolección, junto al contexto:

              AGENTES
                 ↓
          REASONING
                 ↓
     ┌───────────┴───────────┐
     ↓                       ↓
  MEMORY                  CONTEXT
 (HOY: memory architecture) (mañana)
  trabajo + episódica +
  semántica + procedural +
  organizacional + KB +
  grafo + eventos
                 ↓
        KNOWLEDGE (día 11)

La memoria y el contexto son dos caras de la misma moneda: la memoria es lo
que se conserva; el contexto es lo que se trae ahora. La memory
architecture produce el almacén; el context engineering (mañana) decide qué
se trae de ese almacén para cada decisión.

Caso de uso

La aseguradora, con su agente de claims. Descomponemos:

1. Problema. El agente repite acciones ya hechas, olvida promesas al
   asegurado y trata cada caso como nuevo, porque no tiene memoria
   operativa de cada siniestro.
2. Decisión. Definir el siguiente paso de un siniestro en curso y
   garantizar que no se repite nada ni se olvida ningún compromiso.
3. Conocimiento necesario. El estado actual del siniestro (qué se ha
   hecho, qué se ha pagado, qué se ha prometido); las reglas de gestión;
   el procedimiento de este tipo de siniestro.
4. Datos. Póliza, endosos, el expediente del siniestro, el stream de
   eventos (visitas, pagos, notas del ajustador).
5. Relaciones. Siniestro → póliza; siniestro → asegurado; siniestro →
   eventos; siniestro → acciones tomadas; siniestro → compromisos.
6. Contexto. El siniestro lleva 4 meses; hay un anticipo pagado; se
   prometió al asegurado una visita de peritaje en 10 días; hay una
   investigación de fraude abierta.
7. Memoria. Episódica: «se visitó el 2/03 y el 20/03», «se pagó anticipo
   de 8.000 € el 25/03», «se prometió visita de peritaje antes del 10/04»;
   semántica: «los siniestros de este tipo con fraude abierto no admiten
   anticipos adicionales»; procedural: «el cierre de siniestro exige informe
   de peritaje firmado».
8. Razonamiento. Estado: anticipo ya pagado → no proponer otro; visita
   de peritaje prometida y vencida → es el siguiente paso; fraude abierto →
   aplicar la restricción de no más anticipos; falta informe firmado → el
   siniestro no puede cerrarse.
9. Acción. Recomendar «programar la visita de peritaje pendiente (vencida
   el 10/04); no pagar más anticipos (fraude abierto); el cierre queda
   bloqueado hasta el informe firmado» y registrar el compromiso.
10. Infraestructura. La memory architecture: eventos del siniestro
    (episódica) + reglas de gestión (semántica) + procedimiento (procedural)
    • knowledge base de pólizas (RAG) + grafo de relaciones siniestro→
      póliza→asegurado. La memoria operativa es lo que impide repetir el
      anticipo y olvidar la promesa.

Trade-offs

• Coste. Cada almacén de memoria es un sistema con su propia operación.
  Diseñar y operar la memory architecture completa es un proyecto, no una
  configuración.
• Complejidad. La consolidación episodio→semántico es el punto más
  delicado: hacerla mal produce «conocimientos» que son ruido o sesgo. La
  curaduría (quién aprueba qué episodio se convierte en conocimiento) es
  trabajo de negocio, no de ingeniería.
• Consistencia. Si la memoria episódica y la semántica se contradicen,
  hay que decidir cuál manda y en qué contexto. Sin esa regla, el agente da
  respuestas incoherentes dentro de un mismo caso.
• Vigencia y expiración. La memoria caduca. Si no se gestiona la
  expiración, el agente consulta un vertedero y actúa sobre un pasado que ya
  no es. La retención por tipo de memoria es parte del diseño.
• Privacidad y seguridad. La memoria episódica acumula información
  sensible (conversaciones, datos de clientes, decisiones). Hay que aplicar
  permisos, retención limitada y borrado, no solo a los datos de origen sino
  a lo que el agente recuerda.
• Limitación honesta: la memory architecture gestiona la memoria que el
  sistema recibe. No captura el conocimiento tácito de la gente que no se
  explicita (el criterio del ajustador veterano). Mejora lo explícito; no lo
  reemplaza.

Implicación para la empresa

Para el CDO, la memory architecture es lo que convierte el agente en una
capacidad acumulativa y coherente a lo largo del tiempo: cada caso lo hace
mejor y, sobre todo, no le hace repetir errores. Y es un activo con coste de
operación: hay que curarla, actualizarla y vigilarla.

Para el equipo de IA, la lección es de diseño: decidir qué se recuerda,
cuánto dura y qué se consolida es una decisión de producto con implicaciones
de cumplimiento (retención de datos), no de ingeniería. Y medir la memoria
(¿el agente repite lo ya hecho? ¿olvida compromisos?) es tan importante como
medir la recuperación.

Para la alta dirección, el mensaje es de confianza: en dominios donde la
relación con el cliente dura meses (siniestros, proyectos, negociaciones),
la coherencia del agente a lo largo del tiempo es lo que separa un sistema
utilizable de uno que genera fricción.

Conclusión

La memory architecture es el diseño de cómo se combinan los almacenes de
memoria (trabajo, episódica, semántica, procedural, organizacional,
knowledge base, grafo, eventos) y las reglas de ingesta, consolidación,
retención y expiración. Su decisión central es la consolidación con
curaduría: qué episodio se convierte en conocimiento, y quién lo aprueba.
Sin ella, la memoria es un vertedero que el agente consulta con confianza.

Hoy el agente recuerda. Pero recordar todo no es lo mismo que traer lo que
importa ahora. ¿Qué determina, en cada decisión concreta, qué información
—de qué memoria, de qué fuente— se trae y en qué orden? Eso es el contexto,
y mañana lo construimos como mecanismo, no como concepto.

Siguiente artículo

Mañana: Context Engineering: cómo dar a un agente el contexto que realmente necesita. Veremos cómo se construye el contexto dinámicamente a partir de
usuario, tarea, conocimiento, memoria, relaciones, políticas, estado del
proceso y tiempo.

Fuentes

• Sumers, T. R. et al. (2023). «Cognitive Architectures for Language Agents»
  (CoALA). arXiv:2309.02427. — Tipología de memoria formalizada para agentes
  LLM.
• Definición de trabajo de la ICE: ver serie, Día 1.