Memoria a largo plazo buscable para agentes de ingeniería de datos

Los agentes sin estado resuelven bien los problemas. Son malos recordando que ya los resolvieron.

El problema de la amnesia

Imagínese un agente que pasa casi una hora intentando solucionar un NoClassDefFoundError en una notebook de Databricks recién generada. Analiza la traza de errores, descubre que falta una biblioteca en el clúster de trabajo, aplica la corrección y confirma que la ejecución se realizó sin problemas. Un debugging autónomo sólido.

Una semana después, otro pipeline encuentra el mismo error, y el agente no tiene idea de que ya lo ha visto antes. Toda la sesión de debugging se repite con el mismo costo en recursos, con una posibilidad real de que esta vez se opte por una solución diferente.

Eso no es un fallo del modelo. Es así como se comportan los agentes por defecto, y olvidan de tres maneras:

1. Cuando termina una sesión, todo lo aprendido en ella desaparece.
2. Las sesiones largas terminan siendo resumidas o comprimidas, lo que mantiene la trama general pero a menudo descarta los detalles de implementación que eran importantes.
3. En los sistemas multiagente, los agentes trabajadores suelen comenzar con un contexto limpio, no heredan nada de agentes anteriores y no conservan nada una vez finalizada su tarea.

Un equipo que gestionaba un sistema multiagente para generar pipelines de tipo lakehouse en Databricks pagaba este “impuesto de amnesia” en los tres aspectos mencionados. Su solución fue implementar una capa de memoria a largo plazo que permitiera búsquedas.

Qué significa “memoria buscable”

En los sistemas de agentes, dos cosas diferentes se denominan memoria, por lo que es necesario definir con precisión estos términos.

La ventana de contexto funciona como la memoria de trabajo del agente. Todo lo que se encuentra en ella está disponible de inmediato para el modelo, pero solo durante la duración de la sesión. Una vez que la información desaparece, para el agente es como si nunca hubiera existido.

La memoria a largo plazo es un almacenamiento persistente que sobrevive a las sesiones, tareas y agentes. Sin embargo, no basta con simplemente almacenar cosas. La información almacenada solo se convierte en memoria útil cuando se captura automáticamente, se puede buscar de manera efectiva y se recupera en la ventana de contexto cuando es necesario. Este último paso es el que realmente importa. Una lección perfecta que nunca se recupera es como si no existiera, y una lección recuperada carece de valor si no llega al agente que toma las decisiones.

La ciencia cognitiva ofrece una taxonomía que se adapta bien a los sistemas de agentes:

• Memoria episódica: almacena registros de experiencias pasadas específicas: transcripciones archivadas de sesiones, fallos anteriores y sus soluciones, decisiones tomadas en versiones anteriores.
• Memoria semántica almacena hechos estructurados, como “la entidad X pertenece al producto de datos Y” o “este sistema de origen se autentica de esta manera”, idealmente con intervalos de validez, ya que los hechos cambian.
• Memoria procedural es el conocimiento práctico: archivos de instrucciones, habilidades y las convenciones que se cargan en cada sesión.

Dos niveles de memoria

Una decisión eliminó gran parte de la complejidad: dividir la memoria en dos niveles.

Nivel 1, memoria curada. Un conjunto pequeño de reglas mantenido manualmente que se carga en cada sesión. Piense en estándares arquitectónicos, requisitos de seguridad, convenciones de nomenclatura y restricciones de gobernanza. El espacio de memoria es escaso, por lo que este nivel está reservado para lo que debe estar siempre disponible.

Nivel 2: memoria con búsqueda. Un gran archivo de experiencias capturadas automáticamente y recuperadas únicamente cuando son relevantes: soluciones validadas, hallazgos en la resolución de problemas, lecciones de despliegue y patrones de fallos recurrentes. Por defecto, permanece fuera del prompt.

La regla general:

Un hecho que debe respetarse siempre pertenece al nivel curado. Un hecho útil cuando se repite una situación similar pertenece al nivel con búsqueda.

Esta división permite conservar el conocimiento sin saturar la ventana de contexto.

El sistema multiagente que lo necesitaba

El sistema en cuestión gestiona todo el ciclo de vida de la ingeniería de datos, convirtiendo un requisito empresarial en un pipeline y un panel de control listos para su uso en producción. Un orquestador coordina a trabajadores especializados, cada uno con una única tarea y solo las herramientas que necesita:

• Especificación funcional: se lee la solicitud de requisitos, se elabora una especificación y se obtiene la aprobación del solicitante humano.
• Diseño técnico: se convierte la especificación aprobada en un plano que detalla los contratos de datos y las correspondencias de origen a destino.
• Ingestión, transformación e integración: se genera el código real del pipeline. Esto incluye cuadernos de trabajo de nivel Bronce que extraen datos de Kafka, SAP, REST o archivos, cuadernos de trabajo de nivel Plata que remodelan los datos, y modelos dimensionales de nivel Oro, todos organizados según un esquema tipo medallón.
• Validación: es el único agente permitido cerca de un clúster en funcionamiento. Ejecuta cada cuaderno de trabajo generado contra tablas temporales y verifica los resultados.
• Repositorio: gestiona ramas, commits y solicitudes de integración.
• Monitoreo: vigila el proceso CI/CD una vez que se ha fusionado un cambio.

Panel de control: crea paneles de análisis a partir de los resultados.

Seguimiento de costos: informa cuánto cuesta todo esto.

La arquitectura es deliberadamente aislacionista. Los trabajadores operan en paralelo con una propiedad de archivos independiente, no pueden comunicarse entre sí y comienzan cada tarea con un contexto completamente limpio. El orquestador escribe una instrucción de tarea autónoma; el trabajador realiza una tarea definida, devuelve un resultado y desaparece.

El aislamiento hace que el sistema sea seguro y paralelizable. También empeora el problema de la amnesia en comparación con una configuración de un solo agente, ya que cada trabajador “nace” de nuevo cada vez. Cada rol acumula su propio tipo de experiencia que vale la pena conservar, y ninguna de ellas sobrevive al final de una tarea a menos que algo fuera del contexto de los agentes la mantenga.

Diseño de la memoria para múltiples agentes

Hay cuatro mecanismos que abordan este problema.

1. Captura automática

Los ganchos en el tiempo de ejecución del agente se activan en dos momentos: cuando se cierra una sesión y justo antes de que el contexto sea compactado. Cada uno lee la transcripción y extrae lecciones reutilizables a un almacén de memoria. Nadie tiene que recordar escribir documentación o actualizar una base de conocimientos.

Las operaciones de memoria también son no bloqueantes. Si la infraestructura de memoria falla, los ganchos simplemente no realizan acción alguna. La capa de memoria está ahí para ayudar; nunca debe convertirse en algo sin el cual el trabajo real no pueda continuar.

2. Acceso por ámbito

El orquestador posee todo el conjunto de herramientas de memoria. Los trabajadores solo tienen tres capacidades: leer su propio diario, escribir su propio diario y buscar en el almacén. Son las herramientas las que imponen esto, no las instrucciones, lo que mantiene las responsabilidades claras y evita que los trabajadores modifiquen la memoria fuera de sus competencias.

3. Diarios específicos por rol

Cada trabajador cuenta con un espacio de nombres de memoria privado. Los fallos en tiempo de ejecución y las soluciones verificadas se acumulan en el diario del agente de validación, mientras que el monitor de CI/CD recopila las firmas de los fallos y las soluciones que funcionaron. Los demás agentes mantienen almacenamientos similarmente limitados.

Los diarios no son canales de comunicación. Los trabajadores no transmiten mensajes a través de la memoria, y la coordinación queda en manos del orquestador, quien mantiene cada diario coherente y relevante.

4. Recuperación a nivel de contexto

Esta resultó ser la decisión más importante. Los trabajadores comienzan con un contexto vacío, por lo que una memoria recuperada solo es útil una vez que se ha inyectado en ese contexto. La regla de funcionamiento es:

Una memoria que se recupera pero no se coloca en el contexto no existe para el trabajador.

Cada vez que se encuentran lecciones relevantes, el orquestador las escribe directamente en el contexto de la tarea antes de enviarla a ejecución. La mera recuperación no es suficiente; para poder aplicarlas, una lección debe estar visible.

Desarrollo en MemPalace

Esta capa se construye sobre MemPalace, un marco de memoria de código abierto orientado a lo local. El almacén, los embeddings y el índice de búsqueda funcionan todos localmente, por lo que ningún dato abandona el entorno, lo cual es importante cuando los agentes manejan datos empresariales y sistemas de producción.

MemPalace almacena los recuerdos como fragmentos de texto enriquecidos con metadatos como el agente que los creó, una categoría y una marca de tiempo, organizados en espacios de nombres separados. Esto permite que los diarios específicos de cada rol funcionen de manera eficaz: cada agente escribe en su propio espacio y va acumulando conocimientos con el tiempo.

La captura se realiza a través de los ganchos del ciclo de vida mencionados anteriormente. Al final de la sesión, o antes de la compactación, la transcripción se limpia, se convierte en lecciones reutilizables, se incrusta con un modelo ONNX local y se indexa para su recuperación posterior. Todo esto ocurre en segundo plano, por lo que los agentes nunca esperan por operaciones de memoria.

La recuperación es híbrida, combinando similitud vectorial con coincidencia de palabras clave. Esto es útil en ingeniería de datos, donde algunas señales son semánticas y otras son cadenas exactas. Un nombre de error como NoClassDefFoundError o una versión exacta del entorno de ejecución de Databricks debe coincidir literalmente, pero el mismo problema formulado de manera diferente también debe poder ser encontrado.

Los agentes acceden a la memoria a través de MCP. El orquestador ve todo el conjunto de herramientas, mientras que los trabajadores solo ven diary_read, diary_write y search, con límites impuestos por las herramientas y no por instrucciones.

MemPalace fue elegido porque prioriza lo local, es gratuito y fácil de integrar, pero su arquitectura no depende de él. Mem0, Zep o Letta podrían desempeñar la misma función. Lo importante no es el framework, sino el ciclo de retroalimentación: capturar la experiencia, almacenarla y ponerla a disposición cuando vuelva a surgir el mismo problema.

Qué cambió en la práctica

La primera ventaja visible fue la triaje de fallos. Una regla fundamental para el agente de validación es sencilla: ante cada fallo, buscar primero antes de depurar.

mempalace_search(query="NoClassDefFoundError DBR 14.3")

Cuando se vuelve a presentar un caso similar, el agente recibe una lección extraída de una resolución exitosa anterior:

El cuaderno de notas de Bronce para Pedidos se colapsó en DBR 14.3 con un NoClassDefFoundError relacionado con el deserializador Avro. Lo que lo solucionó fue declarar explícitamente la biblioteca del serializador en la configuración del clúster de tareas.

La diferencia es significativa. En lugar de descubrir una solución desde cero, el agente parte de evidencias de algo que ya funcionó. Y el valor no radica solo en la velocidad, sino también en la consistencia. Sin memoria, dos agentes enfrentándose al mismo problema podrían elegir cada uno una solución diferente que parezca razonable. Con memoria, el sistema elige una solución comprobada y sigue utilizando ella.

Se observaron ganancias similares en otros ámbitos. El monitor de CI/CD ahora incluye en sus informes de diagnóstico las ocurrencias históricas de una firma de fallo, los complementos de inicio de sesión restablecen el contexto reciente relevante, y los agentes especializados adquieren conocimiento con el tiempo en lugar de tener que reconstruirlo constantemente.

No se requiere reentrenamiento. El ciclo de aprendizaje ocurre fuera del modelo: experiencia, lección, almacenamiento, recuperación, aplicación.

Lecciones de la producción

Tenga cuidado con las actualizaciones históricas. El primer intento importó grandes volúmenes de transcripciones antiguas. Los resultados fueron decepcionantes, ya que el material más antiguo a menudo eclipsaba las lecciones más recientes y mejores, y hacía que la recuperación de información fuera problemática. El equipo abandonó la importación masiva y comenzó de cero a partir del día en que se puso en marcha la captura diaria. La recencia y la calidad son más importantes que el volumen.

Escriba los recuerdos en lenguaje sencillo. El marco ofrece formatos de entrada compactos, y el equipo los adoptó. La recuperación es más eficaz cuando la lección almacenada incluye exactamente las mismas palabras que se utilizarán en una búsqueda posterior: nombres de productos, nombres de entidades, mensajes de error y clases de excepción. La capacidad de encontrar información es más importante que el tamaño reducido en un almacén de recuerdos.

Elija cuidadosamente qué anotar. No todo lo que se ve merece un lugar permanente. Vale la pena conservar las soluciones confirmadas, los hallazgos validados y las lecciones reutilizables. Lo que se puede omitir son los registros rutinarios, las observaciones temporales, las actualizaciones de estado repetitivas y la información sensible. Una memoria deficiente se acumula rápidamente y puede causar más daño que no tener ninguna.

Conclusiones

Cada vez que los agentes realizan trabajos reiterados, generan experiencia que merece ser conservada. Lo que sugiere este enfoque es:

• Divide la memoria en reglas cuidadosamente seleccionadas y una experiencia buscable.
• Capta las lecciones automáticamente, especialmente antes de la compresión del contexto.
• Concede a los trabajadores permisos limitados basados en su rol.
• Recupera información antes de razonar siempre que pueda haberse resuelto ya un problema similar.
• Integra directamente en el prompt las memorias recuperadas.
• Trata las memorias como evidencia, no como verdades indiscutibles.
• Da prioridad a la calidad de la memoria sobre su volumen.

La lección más importante es de carácter arquitectónico. Se invierte mucho esfuerzo en hacer que los agentes sean más inteligentes, pero en la práctica el valor a largo plazo proviene de hacer que los sistemas recuerden.

Leer más

• De los modelos a los agentes: redefiniendo las tres líneas de defensa — Cómo la gobernanza de MLOps se aplica a los sistemas de agentes: qué debe añadir cada una de las tres líneas, dónde se encuentran las brechas y qué indican las reguladoras de la UE, la FDA y el sector financiero.
• Construyendo una memoria de agente que sobrevive a la conversación sin acumular datos — Un diseño de memoria en tres niveles para los agentes: permitir que el estado de la sesión se elimine, mantener las notas a largo plazo pequeñas y editables, y obtener datos en tiempo real actualizados. Además, se aborda el fallo en la transferencia entre múltiples agentes.

Explicación de los agentes: herramientas, prompts de sistema y el ciclo pensamiento-acción — Una guía para principiantes sobre cómo funcionan los agentes de IA: por qué los modelos de chat olvidan, cómo se describen las herramientas a un LLM, prompts de sistema, ReAct, agentes de código y observaciones.