Memoria de agentes de IA: las cuatro capas que usamos y la quinta que rechazamos

La memoria de agentes de IA es todo lo que le permite a un agente usar información que está fuera de la conversación actual: quién es el cliente, qué se decidió la semana pasada, qué salió mal la última vez que intentó algo parecido. Los datos de Google Ads muestran que las búsquedas del término se multiplicaron aproximadamente por cuatro en el último año, y casi todo lo que aparece en los primeros resultados explica los tipos de memoria desde el punto de vista de un framework.

Este artículo es la mirada desde la operación. En Bamboo Tech Studio mantenemos cuatro capas de memoria para nuestros propios agentes de IA. Cada una cubre una forma concreta en que los agentes olvidan, y cada una tiene su propia forma de fallar en silencio.

Capa 1: la wiki compartida (lo que sabe toda la empresa)

Nuestra empresa funciona sobre una LLM Wiki: un vault de Obsidian en git que los agentes leen y mantienen. Clientes, proyectos, servidores, decisiones, estándares, el registro de tareas. Es la memoria que comparten todos los agentes y todas las personas.

Qué resuelve: un agente que retoma la conversación con un cliente conoce la última decisión, las tareas abiertas y el sistema sobre el que corre, sin que nadie tenga que ponerlo al día.

Qué vigilar: un único archivo compartido de “caché caliente” con el contexto reciente. Cuando varias sesiones escriben en el mismo archivo, cualquiera puede sobrescribirlo por completo, y el contexto de una persona desaparece sin que nadie lo note. Nuestra regla: cada operador tiene su propia caché caliente y su propio log; todos leen los de todos y cada uno escribe solo en el suyo.

Capa 2: lecciones que el agente escribió por su cuenta

Cada máquina que corre Claude Code guarda una pequeña carpeta de memoria: un archivo Markdown por lección, con la regla, el porqué de su existencia y cómo aplicarla. Algunos ejemplos:

• Los agentes no saben qué fecha es hoy. Inyéctala en cada mensaje (por qué importa en agentes de WhatsApp).
• Cero filas pueden significar “descartadas”, no “inexistentes”. Confírmalo en la fuente.
• Que un proveedor diga “recibido” no significa que lo aceptó.
• Haz clic en la página antes de publicarla.

Qué resuelve: que el mismo error no ocurra dos veces. Es la memoria más valiosa que tenemos, y son simples archivos de texto.

Cómo puede fallar: este tipo de memoria vive en cada máquina y con cada operador. Una lección aprendida en una laptop no llega a un agente que corre en un servidor. Ese es un problema de distribución, y sumar otra base de datos no lo resolvería.

Capa 3: recuerdo sobre sesiones pasadas

Usamos memsearch, un plugin que resume cada turno de cada sesión de Claude Code en un archivo Markdown diario e indexa esos archivos para poder buscarlos. Desde el 13 de junio ha escrito 106 archivos diarios. La búsqueda es híbrida: vectores densos más búsqueda por palabras clave con BM25, combinados con reciprocal rank fusion, y cada resultado lleva un enlace de vuelta a la transcripción original.

Qué resuelve: “¿qué decidimos sobre X hace tres semanas, y por qué?”

Qué vigilar:

• Transcripciones que caducan. Claude Code borraba por defecto las transcripciones de sesión a los 30 días, así que el trabajo más antiguo puede desaparecer antes de que alguien se dé cuenta. Los resúmenes diarios en Markdown son los que permiten recuperar ese historial, y nosotros fijamos la retención en 365 días.
• Actualizaciones que cambian el formato del índice. Una versión menor de un plugin puede traer una nueva versión mayor de su almacén de vectores, con un formato en disco incompatible. Cuando los resúmenes son Markdown y el índice es un derivado, la solución es mover el índice viejo a un lado y reconstruirlo, sin perder nada.

Capa 4: un servicio de memoria para agentes conversacionales

Nuestros asistentes de mayor duración usan Honcho, un servicio de memoria que guarda los mensajes, deduce hechos sobre cada persona y los recupera con embeddings en Postgres con pgvector.

Qué resuelve: un asistente que recuerda las preferencias y el contexto de una persona a lo largo de semanas de conversaciones, que es lo más parecido a lo que la mayoría imagina cuando escucha “memoria de agentes”.

Qué vigilar, en el servicio y en el asistente que lo rodea:

• Una recuperación híbrida que no es híbrida. Si los embeddings están apagados en la configuración, la recuperación semántica se degrada en silencio a algo más débil, y puede parecer que funciona durante semanas. Confirma que los embeddings están activos antes de confiar en lo que recupera.
• Una memoria llena que sigue diciendo “guardado”. La memoria integrada del propio asistente, separada del servicio de memoria, puede tener un tope pequeño. Con unos 2.200 caracteres se llena después de cinco o seis entradas, y el modelo sigue diciéndole al usuario que está guardando cosas mientras los guardados fallan. La solución es un tope más grande, las reglas permanentes en un archivo aparte y volver a leer cada escritura.
• Memoria en la máquina equivocada. Una memoria a la que solo llega una máquina no le sirve a nadie. Si el servicio se muda a una laptop, todo lo que sigue apuntando a su dirección vieja deja de funcionar, y cuando la laptop se cae de la red, la memoria se va con ella. La nuestra corre en un servidor al que llegan todos los agentes.

Por qué rechazamos una quinta capa

Evaluamos otro proyecto popular de memoria para agentes y dijimos que no. Nuestro veredicto en ese momento, cuando ya operábamos cuatro: cinco sistemas de memoria son estrictamente peores que tres. Cada capa es otro lugar donde los datos pueden desalinearse, otro índice que mantener sincronizado y otra forma de fallar en silencio. Los problemas difíciles de la memoria de agentes son de distribución (que las lecciones lleguen a todos los agentes) y de verificación (saber que una escritura llegó a su destino), y un almacén nuevo no resuelve ninguno de los dos.

Las reglas que mantienen honesta la memoria

1. El Markdown en git es la verdad; todo índice es un derivado. Si no puedes borrar un índice y reconstruirlo desde los archivos, no es memoria, es un pasivo.
2. Combina la búsqueda semántica con búsqueda de texto completo. La búsqueda vectorial pura no encuentra nombres exactos de productos, IDs ni códigos de error, que es justamente lo que la gente busca.
3. Usa un solo modelo de embeddings por sistema. Los espacios vectoriales son propios de cada modelo, así que cambiar de modelo implica volver a generar los embeddings de todo el corpus. Usamos Qwen3-Embedding-8B a través de la API de Tessera, un servicio de inferencia con el que trabajamos. Produce 4.096 dimensiones y admite truncarlas, y guardamos 1.536 porque el índice HNSW de pgvector sobre el tipo vector estándar llega como máximo a 2.000 dimensiones.
4. Verifica las escrituras en el destino. Que el modelo diga “guardado” no significa nada. Vuelve a leerlo.
5. Vigila los valores de retención por defecto. Una configuración que nadie eligió puede borrar el historial con el que cuentas.
6. No construyas una memoria que no vas a alimentar. Una capa de memoria sin ningún proceso que escriba en ella es peor que no tener ninguna, porque la gente confía en ella.

Cómo elegir para tus propios agentes

• Reglas, decisiones y lecciones: archivos simples que el agente lee al inicio de cada sesión. No hacen falta embeddings.
• Lo que pasó en trabajos anteriores: resúmenes en Markdown más un índice híbrido que puedas reconstruir.
• Datos sobre un cliente o usuario específico: un servicio de memoria con embeddings, separado por persona, con escrituras que puedas verificar.
• El conocimiento de tu producto para responder a clientes: recuperación sobre tu propio contenido, lo que se conoce como RAG. Eso es lo que hace ChatWise en soporte: indexa las páginas y los documentos de un negocio en una colección vectorial por sitio, responde a partir de ellos y pasa la conversación a una persona cuando la respuesta no está ahí.

Si estás diseñando la memoria de un agente que tiene que funcionar en producción, te podemos ayudar. Es parte de cada agente de IA que construimos.