Audité mi memoria de agentes y le pedí a otro modelo que tumbara la auditoría.
La audité con la lista que uso en las demos ajenas y cerré una conclusión cómoda. Después le pedí a un segundo modelo, con contexto limpio, que la tumbara. Encontró lo que a mí se me había pasado.
Dentro del expediente
Mi regla editorial dice que cualquier estándar que exijo a otro se aplica también al sistema propio. Esta vez lo apliqué a la memoria de mis agentes, y el resultado incordió.
Este expediente cuenta experiencia propia y no es una investigación de mercado. Uso agentes de IA en mi trabajo diario y pido a los proveedores lo que cuento en el expediente 10, que demuestren qué guardan, qué pueden ejecutar solos y cómo reconstruyo una salida meses después. Apliqué ese mismo criterio a lo mío.
Cómo está montada
Mi memoria para agentes tiene varias capas. Una de sesión, otra que hace de memoria del despacho y, dentro de esta, memoria episódica de cada jornada, memoria semántica consultable por texto y por vectores, relaciones entre notas con su estado, promoción a canon con reconciliación, archivo con auditoría y vigencia por nota. Un modelo propio decide qué merece quedarse y qué toca revisar después.
Cuando un sistema es tuyo, la tentación es darlo por resuelto. Por eso tocó auditoría, con la misma lista que uso en las demos ajenas, que pregunta qué contexto hereda el agente al arrancar, de quién es, qué promete mi protocolo de cierre y qué escribe el código de verdad.
Dos fallos de acabado y una conclusión cómoda
El primero estaba en el protocolo de cierre, que promete guardar el objetivo, las instrucciones, los descubrimientos, lo logrado, los siguientes pasos y la rama. El código escribía cuatro campos. Se perdían justo los dos que más valoro. Eran las instrucciones que me di y los descubrimientos, eso que aprendiste y juraste no olvidar. Lo que no se guarda nunca llegó a existir, y un hueco invisible no genera sospecha.
El segundo, en los datos de origen de mis notas. Cuando una nota sobre el mismo tema se volvía a guardar, su origen se reemplazaba en lugar de sumarse. Cuando la nota viajaba por una sincronización, parte de esos datos no llegaba. La deduplicación no distinguía de dónde venía cada copia. Ante un «¿por qué decidimos esto?», la cadena decisión, código y momento estaba rota en los bordes. El registro de cambios guarda qué se modificó, no por qué. Mi sistema guardaba el porqué sin anclarlo a nada.
Luego vino la conclusión cómoda. Revisé el componente de continuidad, comprobé que la tarjeta llevaba rama, fecha y archivos, y lo di por sano. Cada hallazgo tenía su evidencia. El conjunto era coherente. Y contenía un error gordo en la parte que no miré.
Le pedí a un segundo modelo que tumbara mi auditoría. La tumbó
En el expediente 09 expliqué cuándo una segunda opinión vale por nada, que es cuando el revisor recibe el texto ya hecho y la orden de confirmarlo. Esta vez apliqué la otra cara, conmigo de conejillo de indias, y tomé cinco decisiones. Le di mi auditoría como dossier de afirmaciones, no como verdad. La misión era verificar en persona, archivo y línea, antes de opinar. Encargo expreso de buscar el fallo, con permiso de añadir lo que a mí se me hubiera pasado. El veredicto tenía que poder cambiar mi plan. Y debía devolver qué había comprobado y qué no.
El revisor era un modelo de otra casa, sin acceso a mi sesión ni a mis conversaciones previas. Contexto limpio significa que no hereda ni tu primera versión ni tu cansancio.
Encontró un fallo en el componente que yo había declarado sano, en cómo se guarda el estado entre sesiones y cómo se recupera al arrancar. Mis hallazgos eran ciertos, pero este era más serio que los dos juntos, y estaba en el archivo que había abierto y cerrado con un «aquí no pasa nada». El veredicto reordenó mis prioridades y puso la continuidad delante del resto.
No lo vi yo porque la lista decía qué mirar, y nunca me pregunté qué no decía. Fallé por lo de siempre, confianza alta y esfuerzo crítico bajo. Una encuesta a trabajadores del conocimiento lo describía así. A más confianza en la herramienta, menos esfuerzo de comprobación declarado Fuente primaria ↗. El revisor, en cambio, no tenía nada que perder con mi conclusión.
Lo que corregí
Hice tres arreglos. El estado entre sesiones se comprueba al arrancar. La nota de cierre escribe los seis campos prometidos, descubrimientos incluidos. Y los orígenes de cada nota sobreviven a las reescrituras y a las sincronizaciones, de modo que repetir una nota añade un origen en lugar de sustituirlo.
Las capas gruesas de memoria nunca estuvieron en cuestión. Lo que falló fue el acabado de los bordes, y los bordes solo los ves si auditas.
Cómo lo compruebo ahora
La prueba de humo cabe en un minuto. Abro una sesión y pregunto qué hay de la anterior. Si lo que me cuenta no coincide con lo que dejé al cerrar, el arreglo no sirve.
La prueba lenta es un diff de vez en cuando, con las promesas del protocolo en una columna y los campos escritos en la otra. Y una prueba más, que consiste en guardar dos veces la misma nota para comprobar qué pasa con su origen.
Me queda una costumbre nueva, que son las preguntas abiertas por escrito. Mi memoria solo guardaba conclusiones, y la mitad de la historia son las dudas. Ahora hay notas que dicen «esto no lo he mirado». Y lo que la memoria escribe sobre sí misma no debería auditarlo solo su dueño.
El rastro que no se comprueba es decoración. La revisión que no puede tumbar tu trabajo, un visto bueno con retraso.
Lo que me preguntan cuando cierro el portátil.
¿Qué es la tarjeta de «sesión anterior» de un agente de IA?
Un resumen que el sistema guarda al cerrar una sesión de trabajo y muestra al abrir la siguiente, con el proyecto, los archivos tocados y el estado del trabajo. Su función es dar continuidad. Solo la cumple si lo que muestra es fiel a lo que pasó.
¿Cómo se audita la memoria de una pila de agentes propia?
Como la de un proveedor. Qué contexto hereda el agente al arrancar y de qué sesión procede; qué promete el protocolo de cierre y qué escribe el código de verdad; y qué pasa con el origen de una nota cuando se repite o viaja entre sistemas. Los hallazgos de esta auditoría salieron de esas tres preguntas.
¿Cuándo vale algo una segunda opinión entre modelos de IA?
Cuando el revisor recibe las afirmaciones como afirmaciones, verifica en persona antes de opinar, tiene la misión de buscar el fallo y puede cambiar el plan de quien pidió la revisión. En este caso cambió el orden de las prioridades, y la continuidad entre sesiones pasó delante del resto.
Audita tu propio sistema con la lista que aplicas a los demás, y deja que alguien sin tus prejuicios intente tumbar la auditoría.
El expediente detrás del artículo.
IA generativa y pensamiento crítico ↗Lee y colaboradores · CHI 2025 / Microsoft Research · 2025Encuesta publicada en CHI
Fuentes consultadas hasta el 1 de octubre de 2026. Las recomendaciones y ejemplos son elaboración editorial y no se atribuyen íntegramente a estas fuentes. Comprueba versión y ámbito antes de aplicar una norma.
Divulgación general. Ninguna herramienta de esta web certifica la revisión, seguridad o conformidad de un proceso.