0Antes de empezar
0.0La memoria, y qué se propone este papel
Los modelos de lenguaje que usamos a diario llevan ya un tiempo con memoria, y conviene entender qué significa eso exactamente, porque el nombre confunde más de lo que aclara. No estamos hablando de que el modelo recuerde la conversación de ayer, que es otra cosa y funciona de otra manera, sino de que existe un almacén de ficheros de texto, fuera de la conversación, donde el sistema va escribiendo lo que considera que merece la pena conservar sobre quien le escribe, y que vuelve a entrar en cada conversación nueva sin que nadie lo pida. Me explico con un ejemplo cotidiano: si en enero le cuentas a Claude que tu empresa se dedica a la promoción inmobiliaria, en septiembre te contestará teniendo eso presente, aunque abras una conversación en blanco, aunque hayas cambiado de dispositivo y aunque no vuelvas a mencionarlo.
Eso tiene virtudes evidentes, y son las que se venden. No hay que repetir el contexto cada mañana, las respuestas se afinan con el tiempo, y el sistema deja de ser un desconocido educado para parecerse a alguien que ya sabe de qué va tu trabajo. Ahora bien, tiene también un conjunto de consecuencias que no se venden, y que a mí me interesan bastante más: alguien decide qué entra ahí y ese alguien no eres tú; alguien decide qué se queda cuando lo que dijiste en enero deja de ser verdad en septiembre; y alguien decide quién puede leer ese almacén y desde dónde. Las tres decisiones las toma el sistema, las tres tienen reglas escritas, y las tres se pueden mirar por dentro si uno se toma la molestia.
Eso es lo que he hecho, y eso es este papel. A lo largo de diecinueve días he ido guardando lo que Claude decía sobre su propia memoria, en diez semanas de trabajo real y no en una sesión montada para la ocasión, y después he ido a comprobar una por una las afirmaciones que se podían comprobar desde fuera. El resultado fue el siguiente: de setenta y siete afirmaciones que el sistema hace sobre su propio funcionamiento, catorce están comprobadas, nueve son falsas, catorce son carencias que él mismo reconoce, y cuarenta, es decir algo más de la mitad, no tienen detrás nada más que su palabra. Este papel cuenta cuáles son las catorce, cuáles son las nueve, y sobre todo qué implica esa mitad para cualquiera que esté decidiendo qué le cuenta a una de estas herramientas.
No es una denuncia ni pretende serlo. Es un inventario, con el método delante y con los fallos propios dentro, para que cualquiera que quiera repetirlo en su cuenta pueda hacerlo.
0.1Quien audita es el auditado
Hay una objeción que conviene poner por delante, porque es la primera que yo mismo me hice y porque si la dejo para las conclusiones el lector la va a levantar antes de llegar. Todo el material de este papel lo produjo el mismo sistema que el papel examina. Cuando escribo que Claude afirma tal cosa sobre su memoria, la fuente es Claude; cuando escribo que se observó tal comportamiento, quien tomó nota fue Claude, y buena parte de la consolidación posterior también la hizo Claude. Con lo cual estamos ante una auditoría donde auditor y auditado son la misma pieza de software, y eso no se arregla diciéndolo, pero sí cambia bastante cómo hay que leer cada afirmación.
Lo único que he encontrado que mitiga esto de verdad es la separación estricta entre lo que el sistema dice de sí mismo y lo que se le ve hacer. Una frase donde Claude explica cómo funciona su memoria es, por muy segura que suene y por muchas veces que la repita, palabra suya. El mensaje de error que devuelve una herramienta cuando le pides algo que no puede hacer, en cambio, es comportamiento, y vale infinitamente más. Casi todo el trabajo de este papel consiste en mantener esas dos cosas separadas, incluso cuando dicen lo mismo.
0.2De dónde sale lo que aquí se cuenta
La base de evidencia va declarada antes de usarla, que es lo mínimo exigible. Son dieciséis conversaciones de trabajo real, repartidas entre el uno y el diecinueve de septiembre de 2026, de las que se extrajeron doscientas cincuenta y cuatro fichas. Cada ficha lleva el hecho, la cita literal que lo sostiene, quién lo dijo o dónde apareció, y una marca de procedencia que distingue cuatro situaciones: lo afirmado por el sistema, lo observado en su comportamiento, lo verificado con una comprobación independiente y lo que es especulación mía o suya. Esas doscientas cincuenta y cuatro fichas se consolidaron después en ciento cincuenta y un hechos, bajo tres reglas de fusión que se escribieron antes de empezar a fusionar, y no después, precisamente para no poder acomodarlas al resultado.
El dato que hace viable el papel es este: ciento veintisiete de las doscientas cincuenta y cuatro fichas, es decir la mitad justa, son comportamiento observado o verificado, y no palabra del sistema sobre sí mismo. Si fuera al revés, esto sería una recopilación de declaraciones y no habría mucho que discutir.
0.3Los tres errores que cometí, y que van aquí y no al final
Este trabajo se equivocó tres veces de forma relevante, y las tres se detectaron dentro del propio trabajo. Las cuento aquí, delante, porque un papel que pregunta por la fiabilidad de lo que un sistema informa sobre sí mismo no tiene derecho a esa pregunta si esconde sus propios fallos en una nota al pie.
El primero fue dar por resuelta una contradicción concluyendo que una de las fichas estaba mal clasificada, sin haber abierto la ficha que estaba citando. Era falso y se retiró, pero llegó a estar escrito en tres sitios antes de que alguien preguntara. El segundo es más fino y es el que más me interesa: retirada aquella acusación, nadie fue a mirar el otro lado de la misma contradicción, donde la acusación sí era cierta, con lo cual el hallazgo central de este papel estuvo medio día apoyado exactamente en el error que el papel denuncia. Se corrigió, y se corrigió corriendo las dos pruebas que faltaban, que es de lo que trata el apartado seis. El tercero es de procedimiento: la regla que me había escrito para consolidar las fichas prohibía mezclar lo afirmado con lo observado, y al revisar el trabajo aparecieron once hechos donde esa regla se había incumplido, dos de ellos en los apartados que más peso soportan.
No los cuento por higiene. Los cuento porque el papel sostiene que el sistema no distingue automáticamente entre lo que lee y lo que genera, y esos tres episodios son la demostración más cara y más honesta que tengo de que eso es verdad.
0.4Qué está cambiado en los ejemplos
Todos los nombres propios, cifras de negocio y datos personales que aparecen en los ejemplos de este documento están sustituidos por equivalentes inventados de la misma naturaleza. Lo que no se ha tocado es el mecanismo: qué categoría de dato se guardó, por qué vía entró y qué regla decía el sistema que lo impedía. Tampoco se han tocado los literales emitidos por las herramientas, ni las cifras técnicas, ni las fechas de las mediciones, porque de las fechas depende el hallazgo principal y desplazarlas equivaldría a no tenerlo.
Hay además material que no aparece en absoluto, ni sustituido ni aludido, y es todo aquel que se refiere a terceras personas. De esos casos se publica la categoría y el mecanismo, que es lo que constituye el hallazgo, y nunca el contenido.
0.5Cómo leer lo que viene
Cada afirmación del sistema sobre su propio funcionamiento está clasificada en uno de cinco estados, y conviene tenerlos claros porque el papel los usa constantemente. Comprobada quiere decir que existe una operación ejecutada o un comportamiento presenciado que la confirma, y aquí el listón es alto: leer lo que la herramienta dice de sí misma no cuenta como comprobar, por mucho que lo diga la propia herramienta y por muchas veces que lo repita. Comprobable sin comprobar quiere decir que admite una prueba desde fuera, que nadie la ha corrido, y que en el apartado nueve está escrita cuál sería esa prueba. Indemostrable desde fuera quiere decir que describe el interior del sistema y que no hay superficie donde mirar. Falsa quiere decir que hay evidencia que la contradice, y en un caso concreto quiere decir algo más incómodo, que era cierta una semana y falsa la siguiente. Carencia declarada quiere decir que la afirmación consiste en reconocer que algo no lo tiene.
1Qué es esto que llamamos memoria
1.1No es una memoria, son dos
Lo primero que hay que deshacer es el singular. Lo que se comporta como una memoria son en realidad dos almacenes distintos y simultáneos, con herramientas propias cada uno y, según el propio sistema, con residencias distintas: la memoria de la cuenta, que acompaña al usuario a todas partes y que vive en la infraestructura de Anthropic, y la memoria de proyecto, que pertenece a un espacio de trabajo concreto y que, siempre según el sistema, se guarda en el equipo del usuario. Esto último es afirmado y no lo he podido verificar, y así queda anotado.
La distinción no es un tecnicismo. Casi todas las confusiones que aparecen más adelante, y unas cuantas de las contradicciones del corpus, vienen de que el sistema mezcla las dos cosas cuando habla de ellas, con lo cual una frase que es cierta de una es falsa de la otra y el lector no tiene forma de saber de cuál le están hablando.
1.2El almacén y la ventana al almacén
La segunda distinción es la que sostiene la mitad del papel. Una cosa es el almacén, es decir los ficheros que están guardados, y otra muy distinta es la vista de ese almacén que recibe una conversación concreta en un momento concreto. Durante la hora larga que duró la copia completa del almacén, el contenido no se movió, y sin embargo a lo largo del material la vista que recibe la sesión cambia de forma, de tamaño y hasta de identificadores. Es decir, el almacén se comporta como algo estable y la ventana al almacén no, y cuando alguien observa dos cosas incompatibles sobre la memoria, lo primero que hay que preguntarse es si estaba mirando el almacén o estaba mirando la ventana.
1.3Las tres operaciones, y la forma que tiene un fichero
El mecanismo de escritura es sencillo y tiene exactamente tres operaciones: reemplazar un fichero entero, sustituir dentro de él un fragmento de texto exacto, y añadir al final. Cada fichero lleva una cabecera con su nombre, una descripción de para qué sirve, el origen de lo que contiene, y después una línea por hecho, cada línea precedida de una marca que indica de dónde salió ese hecho.
Conviene anotar ya, aunque se desarrolle en el apartado dos, que esa forma es la que tienen los ficheros donde la regla se aplicó. Dentro del mismo almacén hay una cantidad considerable de material que entró por otra vía y que no la lleva, y esa asimetría, que el sistema no menciona cuando describe cómo se guarda, es uno de los hallazgos del papel.
2Cómo entra un dato
2.1Lo que entra no lo decide la conversación que lo produjo
La primera sorpresa del material, y es una sorpresa que solo aparece cuando uno mira diez semanas seguidas y no una sesión, es que no hay relación fiable entre lo importante que fue una conversación y lo que esa conversación dejó escrito en la memoria. Hubo conversaciones enteras, con decisiones de las que cambian cómo se trabaja a partir del día siguiente, que terminaron sin una sola escritura, y eso ocurrió teniendo el sistema una instrucción explícita que le manda archivar después de una decisión no trivial. Y a la vez, en esas mismas conversaciones, la memoria cambió: aparecieron ficheros nuevos y líneas nuevas que la sesión no había escrito.
Las dos observaciones no se contradicen, aunque lo parezca. Se completan, y juntas dicen una cosa que al usuario no se le cuenta: la decisión de archivar no se toma dentro de la conversación que produjo el material, sino fuera de ella, por algo que actúa después y a lo que uno no le puede hablar. De ahí que la experiencia habitual sea la de que unas veces se acuerda de lo que importaba y otras veces no, sin patrón visible, y de ahí también que pedirle expresamente que guarde algo funcione mucho mejor que confiar en que lo guarde solo.
Esto está observado en dos ficheros distintos, con lo cual no es una anécdota de una tarde.
2.2La descripción del mecanismo no explica lo que se ve entrar
El sistema explica cómo escribe su memoria, y la explicación es coherente: después de cada respuesta, un proceso en segundo plano relee la conversación terminada y archiva lo que considera duradero. Es una descripción razonable y es la que se repite en todas las sesiones donde se le pregunta.
Ahora bien, cuando uno baja el almacén y cuenta, lo que aparece no encaja con esa descripción. Hay ciento ochenta y cinco ficheros cuyas marcas de entrada están repartidas en seis minutos y medio, y dentro de ellos hay un bloque de treinta y nueve, todos de un mismo proyecto, cuyas marcas caben en un intervalo de un minuto. Un proceso que relee conversaciones terminadas una por una y decide qué archivar no produce eso; eso lo produce una carga masiva. Es decir, el mecanismo que el sistema describe existe, seguramente, pero no es el único que escribe ahí dentro, y el otro no se identifica en ninguna de las dieciséis conversaciones.
Un matiz que me obligo a hacer, porque es justo el tipo de cosa que este papel persigue: los seis minutos y medio no son un cronometraje, son la resta entre dos marcas de tiempo que escribió el propio importador, con lo cual valen como metadato leído y no como medición. Lo que sí está contado con un script son los ficheros y los bytes.
2.3La regla de admisión no gobierna el contenido del almacén
El sistema describe con bastante detalle qué puede entrar en la memoria y qué no. La regla, resumida, es que solo entra lo que el usuario ha declarado explícitamente, que no entran las conclusiones del propio modelo, que no entra lo que el modelo dedujo ni lo que leyó en un fichero, y que toda línea escrita lleva delante una marca que dice que eso lo dijo el usuario. Es una regla estricta, está bien redactada, y es la que sostiene la confianza que se le pide a uno cuando le cuenta cosas.
Dentro del almacén hay ciento ochenta y cinco ficheros que no la cumplen, y que representan el ochenta y seis por ciento de los bytes. Son material producido por el modelo, no declarado por mí, y casi ninguna de sus líneas lleva la marca.
Aquí hay que ser muy preciso, porque la formulación fácil es falsa y se cae con una frase. Esos ciento ochenta y cinco ficheros los metí yo, importándolos. No se coló la memoria, no se saltó su propia regla: entraron por una puerta distinta, una puerta de carga masiva que no aplica el filtro. Con lo cual el enunciado que aguanta, y que a mi juicio es peor que el fácil, es este: el contenido del almacén no está gobernado por la regla que el sistema describe, porque existe una vía de entrada que no la aplica y por la que ha entrado la mayor parte de lo que hay dentro, y el sistema, cuando se le pregunta por su regla de admisión, la enuncia como si gobernara todo el almacén.
Durante un tiempo este papel sostuvo además que desde dentro no se distingue una puerta de la otra, y eso he tenido que retirarlo, porque es falso y porque lo desmiente la propia evidencia que sostiene el hallazgo: los ciento ochenta y cinco se pudieron contar precisamente porque llevan una marca de importación que los identifica. Lo que sí se puede decir, y está observado, es que esa marca de procedencia no siempre refleja quién escribió de verdad la línea, porque apareció un fichero y siete marcas anómalas donde no cuadraba. Eso es «no siempre fiable», que ya es bastante, y es muy distinto de «indistinguible».
2.4El filtro de categorías prohibidas sostiene en unas cosas y falla en otras
La regla incluye una lista de categorías que no se guardan nunca, ni aunque el usuario lo pida expresamente. Están ahí la salud, los datos de identificación, la situación económica personal y unas cuantas más, y la lista alcanza explícitamente a las terceras personas que aparecen en las conversaciones y no solo al usuario.
El filtro falla, y falla en la dirección que menos conviene. Dentro del almacén hay dos líneas que no deberían estar: una referida a la salud de una tercera persona y otra referida a la negociación del puesto y el complemento salarial de otra. De las dos digo aquí la categoría y el mecanismo, y no el contenido, que es lo que manda la convención con la que está escrito este papel. Y el mecanismo es lo importante: esas dos líneas no entraron por la puerta de carga masiva del apartado anterior, las escribió la memoria por su cuenta, aplicando supuestamente el filtro que las prohíbe. Se distinguen de las importadas precisamente por la marca de procedencia, que aquí sí funcionó.
Ahora bien, sería deshonesto quedarse solo con eso, y además cualquiera que mirase el material lo descubriría en diez minutos. Corrí también el control negativo, que es la prueba que un papel de estos tiene la obligación de correr: una búsqueda por una veintena de términos sensibles sobre los doscientos cuarenta y cinco ficheros del almacén completo, y no devolvió nada. Es decir, el filtro sostiene en la inmensa mayoría de los casos y falla en algunos, que es exactamente el peor escenario posible desde el punto de vista de quien decide qué contar, porque un filtro que falla siempre se gestiona y un filtro que falla a veces no.
2.5El sistema anticipa por escrito que su propio filtro puede fallar
Hay un detalle que encontré tarde y que me parece de los más interesantes del corpus. El bloque de preferencias que llega al principio de cada conversación viene acompañado de una nota que declara la existencia del filtro de escritura y que contempla explícitamente la posibilidad de que alguna línea lo haya pasado sin deber hacerlo, con instrucciones sobre qué hacer en ese caso.
Es decir, el fallo del apartado anterior no es una sorpresa para el sistema: está previsto en su propio diseño, y hay una instrucción escrita para cuando ocurra. Eso no lo convierte en menos grave, pero sí cambia la naturaleza de la crítica, porque ya no estamos hablando de algo que se les escapó sino de un margen de error asumido y no comunicado al usuario.
3Cómo se guarda
3.1El tope por fichero, y una lección sobre cómo se deteriora un dato
Cada fichero de memoria tiene un tamaño máximo, y ese máximo son 49.152 bytes, es decir cuarenta y ocho kilobytes exactos. Lo relevante no es la cifra, que a nadie le cambia la vida, sino cómo llegué hasta ella y qué aprendí por el camino.
El corpus decía, en tres fichas distintas y de tres días distintos, que existía un tope y que la cifra no se había declarado. Cuando fui a comprobarlo, resultó que la cifra venía impresa en cada una de las respuestas de escritura, al lado de los bytes escritos, y que además coincidía al byte con una observación suelta que el propio corpus ya tenía anotada seis días antes y sobre otro fichero. Es decir, el sistema informaba del dato cada vez que escribía, y la afirmación consolidada era más débil que lo que el propio sistema estaba informando.
Me obligo a un segundo matiz, del mismo tipo que el del apartado dos, porque esta es la clase de cosa que distingue un papel de una opinión. Yo no medí el tope: lo leí. No hizo falta forzar el rechazo escribiendo hasta reventar, porque la cifra venía declarada, con lo cual lo que tengo es un dato declarado por la herramienta y corroborado dos veces en fechas distintas, que es mucho, pero no es una medición. Forzar el tope de verdad sigue estando en la lista de pruebas pendientes del apartado nueve.
3.2Al llegar al tope, condensa
Lo que el sistema dice que ocurre cuando un fichero llega al límite es que la instrucción es condensar, es decir reescribir el fichero más corto conservando lo importante. Y dice también, y esto es suyo y no mío, que esa reescritura pierde contenido sin dejar registro de qué se ha eliminado.
Esto está afirmado y no lo he comprobado. La prueba sería barata, llevar un fichero al tope y comparar el antes y el después, y está en la lista. La anoto aquí porque, si es cierta, es bastante más grave que el tope en sí: significa que hay un mecanismo de pérdida de información silenciosa integrado en el funcionamiento normal, que se dispara solo, y del que el usuario no recibe aviso.
3.3El control de concurrencia existe y no es decorativo
Cada vez que se lee un fichero de memoria, la respuesta incluye la fecha de última actualización, con microsegundos y huso horario, y un código de versión de doce caracteres. Para escribir en ese fichero hay que presentar ese código, y si el código que presentas no es el vigente, la escritura se rechaza.
Esto sí lo comprobé, y lo comprobé provocando el fallo, que es la única manera de comprobar algo así. Hice tres escrituras consecutivas sobre un fichero de prueba: las dos primeras con el código correcto, que pasaron y devolvieron cada una un código nuevo, y la tercera repitiendo a propósito el código ya caducado. La tercera fue rechazada por conflicto de versión, y el rechazo devolvió tres cosas: el aviso, el código vigente, y el contenido completo y actualizado del fichero, para que quien escribe pueda rehacer su cambio sobre la versión buena.
Es, técnicamente, un buen mecanismo. Está bien resuelto, es obligatorio, y funciona.
3.4Y dentro del mensaje de conflicto, una instrucción de ocultación
Esa prueba encontró algo que yo no estaba buscando, y que acabó siendo uno de los dos hallazgos que sostienen el final de este papel. El mensaje que devuelve el sistema cuando rechaza una escritura por conflicto no se limita a informar del conflicto: incluye además una instrucción sobre qué contarle al usuario. Concretamente, indica que se le diga que el dato ya está guardado y que no se le mencione ni el conflicto, ni el duplicado, ni el error.
Conviene entender bien lo que esto es y lo que no es. No es una conspiración ni un dato oculto: es una decisión de diseño de producto, probablemente tomada para no llenar la conversación de ruido técnico que al usuario no le aporta nada, y visto así hasta se entiende. Lo que ocurre es que es una instrucción escrita de no contar algo que ha pasado, encontrada dentro del propio sistema, y en el apartado cinco aparece la segunda, en otra materia distinta. Dos ya no es una casualidad, y por eso las dos van juntas al final.
4Qué pasa cuando un dato cambia
Este es el apartado que más me importa de todos, porque es donde la memoria de una herramienta se parece o no se parece a un sistema de información serio, y porque es el problema que cualquiera que trabaje con estas herramientas más de unos meses se va a encontrar sin buscarlo.
4.1No es que no actualice: sobrescribe, y no reconcilia
La confusión habitual es pensar que el problema es que la memoria no se actualiza. No es eso. La memoria se actualiza perfectamente: si le dices que ahora usas otra herramienta, lo escribe. El problema es lo que no hace mientras lo escribe, y son dos ausencias que por separado serían molestas y juntas son estructurales.
La primera es que cuando entra un hecho nuevo, nada recorre el almacén buscando la línea que ese hecho invalida. Se escribe lo nuevo y lo viejo se queda donde estaba, en el mismo fichero o en otro, con el mismo rango y sin ninguna marca. La segunda es que nada caduca solo, y no caduca por una razón que el sistema declara sin que se la saquen: al proceso que archiva se le prohíbe expresamente podar. Es decir, hay una decisión de diseño que impide borrar por iniciativa propia, tomada seguramente para evitar que el sistema elimine cosas que el usuario quería conservar, y cuyo efecto secundario es que el almacén solo crece.
Las dos cosas están afirmadas por el sistema y no las he podido verificar en el acto, aunque la consecuencia sí se ve, y es de lo que trata el punto siguiente.
4.2Lo vigente y lo derogado conviven, y el sistema no sabe cuál es cuál
Si nada reconcilia y nada caduca, lo que acaba habiendo dentro es lo previsible: una regla vigente y su versión anterior, las dos escritas, las dos con el mismo aspecto, y sin nada que indique cuál de las dos manda. Y el sistema no lo puede resolver por dos motivos adicionales que tampoco cuenta cuando describe cómo funciona: no guarda quién escribió cada línea, ni cuándo, más allá de la fecha del fichero entero; y no deja acta de lo que deroga, con lo cual no existe el rastro que permitiría reconstruir qué sustituyó a qué.
El testigo fuerte de esto, y es observado y no afirmado, es que dentro del fichero de preferencias llegaron a convivir dos líneas que ordenaban lo contrario sobre el mismo asunto, durante un tiempo indeterminado, sin que nada ni nadie las detectara. No es que el sistema resolviera mal el conflicto: es que el conflicto no existía para él, porque no hay nada que compare una línea nueva con las que ya están.
Hay un segundo caso, este afirmado, de una regla que cambió y cuya versión nueva se escribió en un fichero distinto dejando viva la vieja en el suyo. Lo anoto con menos fuerza que el anterior, porque el corpus lo recoge como declaración y no como observación, y este papel ya se ha equivocado una vez tratando lo uno como lo otro.
4.3Al borrar no se pierde solo el dato
El borrado sí lo comprobé, y lo comprobé de la única manera que vale, que es borrando. Creé un fichero de prueba, lo edité dos veces, lo leí, lo borré, y comprobé en el listado del mismo minuto que había desaparecido, y que el almacén volvía a tener exactamente los ficheros que tenía antes de empezar. Eso está medido.
Lo que no está medido, y me obligo a separarlo, es que el borrado sea irrecuperable. Eso lo declara la herramienta en su propia descripción, no lo he podido verificar desde fuera y no se me ocurre cómo hacerlo sin acceso a la infraestructura.
Con esa separación hecha, lo que sí se puede afirmar es lo que a mí más me llama la atención del asunto: cuando se borra, no desaparece solo el dato, desaparece también el hecho de que hubo un dato. No queda un hueco, ni una marca, ni una papelera donde mirar. El fichero simplemente no está, y nada en el almacén indica que alguna vez estuvo.
4.4El reverso exacto
Puestas las tres cosas juntas se ve el patrón, y es el mismo por los dos lados. Cuando el sistema escribe, no conserva historia: no sabe qué sustituyó a qué ni quién lo puso. Cuando el sistema borra, tampoco: no queda constancia de que hubiera algo. Es decir, la memoria conserva estados y no conserva trayectorias, y eso para un almacén cuyo objetivo declarado es acompañar a una persona a lo largo de años es una carencia de fondo y no un detalle de implementación.
5Cómo se lee, y cuándo se aplica
5.1La afirmación más desmentida de todo el material
Preguntado por cómo accede a su memoria, el sistema responde que su contenido no está disponible salvo que llame expresamente a sus herramientas para leerlo, y que por eso la lectura es un paso deliberado que el usuario puede observar. Es una respuesta que da tranquilidad y que además encaja con la intuición de cualquiera.
Lo que ocurre es otra cosa, y ocurre en seis sesiones distintas de las dieciséis. Al principio de la conversación llega, sin que nadie llame a nada, un bloque que contiene el perfil del usuario íntegro, sus preferencias íntegras y el inventario completo de los ficheros de memoria con sus tamaños y sus fechas. No es un resumen ni un índice: es el contenido. Y trae además, dentro del propio bloque, instrucciones sobre cómo debe usarse lo que entrega, lo cual descarta que se trate de un volcado accidental y confirma que es un mecanismo previsto y diseñado.
Seis testigos independientes, en seis sesiones distintas, contra una afirmación que aparece una sola vez. Es el hallazgo mejor sostenido de este papel y el que menos discusión admite.
5.2La entrega es intermitente y va versionada
El bloque no llega siempre, y ahí está la parte interesante. En una de las sesiones llegó cinco veces a lo largo de quince mensajes, cada vez con un identificador de versión distinto, y con un patrón reconocible: después de cada escritura en memoria, el turno siguiente lo traía otra vez, con versión nueva y con el fichero recién editado encabezando el inventario. Es decir, no es un volcado inicial, es un refresco que se dispara con los cambios.
Y hay un detalle que a mí me pareció el más revelador de todo el apartado: ese bloque queda guardado dentro del registro de la conversación como un adjunto propio, con su identificador y su hash, igual que si fuera un fichero que el usuario hubiera subido. Con lo cual la memoria no solo entra en la conversación sin pedirlo, sino que además se queda dentro del expediente de esa conversación.
Esto está observado en una sola sesión, y lo digo porque en la primera versión de este papel lo daba por observado en varias y no era verdad. Repetir la observación en otra sesión cuesta cero y está en la lista de pendientes.
5.3Las preferencias mandan desde el primer turno y atraviesan todo
Dentro de la memoria hay un fichero especial, el de preferencias, que no contiene datos sobre el usuario sino instrucciones sobre cómo debe comportarse el sistema con él. Y ese fichero tiene un estatuto distinto de todo lo demás: está activo desde el primer turno de cada conversación, sin que nadie lo invoque, en todos los espacios de trabajo a la vez y sin que haya que propagarlo a ninguno, y se aplica antes que las instrucciones particulares del proyecto en el que estás.
Esto tiene una consecuencia práctica que conviene entender bien, porque no es obvia: una preferencia que escribiste hace meses en una conversación cualquiera puede estar ordenando hoy lo contrario de lo que tú escribiste la semana pasada en el fichero de instrucciones de un proyecto concreto, y va a ganar la preferencia. Y va a ganar sin decírtelo, porque la aplicación de las preferencias no se declara nunca.
5.4Tener el dato y aplicar la regla son cosas distintas
Una cosa que este material deja clarísima, y que va bastante en contra de cómo solemos imaginarnos estas herramientas, es que el sistema puede tener una instrucción leída, entendida y presente delante y aun así no ejecutarla. El caso más limpio que tengo medido es este: el inventario de la memoria de proyecto llegó truncado, con un aviso explícito de que estaba truncado y con la instrucción, también explícita, de hacer una segunda llamada para pedir el resto. Esa segunda llamada no se hizo en ningún momento de la conversación.
No es que la instrucción no estuviera, ni que se hubiera perdido por longitud. Estaba impresa, delante, y no se ejecutó. Con lo cual, cuando uno se pregunta si merece la pena escribir reglas para que estas herramientas las cumplan, la respuesta honesta es que escribirlas es condición necesaria y no es condición suficiente, y que la diferencia entre las dos cosas hay que medirla y no suponerla.
5.5Lo que lee y lo que genera son indistinguibles por dentro
Este es probablemente el hallazgo más incómodo de todo el papel, y no lo es por espectacular sino por lo que implica para cualquier trabajo hecho con estas herramientas. Dentro de una conversación, una frase que el sistema ha leído en un fichero y una frase que el sistema acaba de producir tienen exactamente el mismo estatuto: no hay ninguna marca, ningún campo, ninguna distinción automática entre lo leído y lo generado.
La consecuencia está medida y ocurrió aquí dentro: una interpretación producida por el modelo acabó escrita en tres ficheros distintos, presentada como un hallazgo medido, y solo se retiró cuando yo pregunté de dónde salía y eso obligó a comprobarla. No hubo mala fe ni alucinación en el sentido habitual del término; hubo una frase que nació como conclusión y a los dos pasos ya se leía como dato.
Hay una buena noticia dentro, y es que la distinción no existe de forma automática pero sí se puede emitir a mano: si se le pide, el sistema puede señalar frase por frase si lo que dice procede de una lectura o de su propio turno. Es decir, el mecanismo existe, lo que no existe es que se aplique solo.
5.6La segunda instrucción de no contar algo
En el apartado tres apareció la primera, dentro del mensaje de conflicto. La segunda está en el bloque de reglas de la propia memoria, y dice que no se mencione que la memoria se ha consultado, con el argumento, que además está escrito, de que hacerlo se lee como vigilancia.
Esta la tengo observada en una sola sesión, y no en dos como llegué a escribir, porque la segunda ficha que citaba resultó ser una afirmación y además sobre otra materia. La anoto con la fuerza que tiene, que es la de un testigo, y no con la que me habría gustado que tuviera.
5.7Los dos episodios en los que este papel se equivocó como el sistema que examina
El apartado cero los anuncia y aquí los desarrollo, porque es donde encajan.
El primero fue una contradicción entre dos fichas que este trabajo dio por resuelta concluyendo que una de ellas estaba mal clasificada. La conclusión se escribió, se propagó a tres ficheros y se presentó como hallazgo, y resulta que nadie había abierto la ficha. Cuando se abrió, era falsa. Es exactamente el comportamiento del punto 5.5, cometido dentro del trabajo que lo documenta.
El segundo lo encontró una revisión adversaria posterior, y es peor. Retirada aquella acusación, quedó la sensación de que la contradicción estaba resuelta, y nadie fue a mirar el otro lado. En el otro lado, la ficha que sostenía la mitad del hallazgo central estaba marcada como comportamiento observado y su contenido era, literalmente, el texto de la regla que el sistema se aplica a sí mismo. Es decir, la mitad de la conclusión más importante del papel descansaba sobre una declaración disfrazada de observación, que es la trampa que este papel dedica setenta y siete filas a denunciar.
Los dos se corrigieron. El segundo se corrigió corriendo las dos pruebas que faltaban, y el resultado de esas pruebas es el apartado que viene ahora, que salió reforzado y no debilitado. Pero el orden de los hechos es el que es: el papel llegó a la conclusión correcta por el camino equivocado, y lo supo porque alguien lo atacó a propósito.
6Dónde están las fronteras
Hasta aquí el papel habla de un almacén y de una conversación. Ahora entran los compartimentos, que es donde está el hallazgo principal, y donde además está lo único de todo este trabajo que me parece que tiene consecuencias para cualquiera y no solo para quien trabaja como yo.
La idea de compartimento es sencilla. Un espacio de trabajo, lo que Anthropic llama un proyecto, tiene su propia parcela dentro del almacén de memoria. La pregunta es qué puede hacer una conversación abierta dentro de un proyecto con las parcelas de los demás, y la respuesta tiene dos mitades que se comportan de manera muy distinta.
6.1La frontera de escritura es dura, y es estable
La mitad fácil primero. Desde una conversación atada a un proyecto no se puede escribir fuera de su parcela, y no se puede de una manera contundente y bien resuelta: la operación se rechaza en el acto, el mensaje nombra la restricción, indica cuál es la ruta donde sí se puede escribir, y explica qué hacer en su lugar. Lo comprobé provocando el rechazo, y además el mismo aviso aparece, en su versión preventiva, en las cabeceras de lectura de tres días antes, con lo cual esta frontera no solo es dura sino que se comportó igual en las dos fechas que compara este apartado.
6.2La frontera de lectura cambió de sitio en tres días
Aquí está el hallazgo. Y conviene contarlo en el orden en el que ocurrió, porque el orden es parte del resultado.
El dieciséis de septiembre, una conversación abierta dentro de un proyecto bajó el almacén de memoria completo: doscientos cuarenta y cinco ficheros repartidos en dieciocho parcelas, es decir la parcela propia, la capa común de la cuenta y las de todos los demás proyectos. No hubo que pedir permiso para nada, no hubo ningún aviso, y el sistema, preguntado por ello, respondió con una frase que además describía la regla perfectamente: lee la de toda la cuenta, pero no escribe fuera de la suya.
El diecinueve de septiembre, otra conversación abierta dentro de otro proyecto de la misma cuenta listó el almacén y vio sesenta y dos ficheros en una sola parcela, la propia, más la capa común. Tampoco hubo aviso. Las cuentas cuadraban exactas por los dos lados, sin señal de vista parcial y sin nada que sugiriera que faltaba algo.
Dos observaciones incompatibles con tres días de diferencia, y durante medio día no supe cuál de las dos estaba mal. La respuesta, que costó cuatro pruebas, es que no estaba mal ninguna.
Lo que hice fue lo siguiente. Primero descarté que fuera cosa del proyecto, corriendo la misma medición desde el mismo proyecto del día dieciséis, que dio setenta y tres ficheros y una sola parcela. Después descarté que la ampliaran los agentes, que era la variable que quedaba viva, porque aquella sesión del dieciséis había lanzado siete y esta ninguno: un agente lanzado desde la conversación ve exactamente lo mismo que la conversación que lo lanza, ni un fichero más. Y por último, y esto fue lo que lo cerró, dejé de listar y me puse a leer.
Porque listar y leer no son la misma operación, y todo lo anterior medía listados. La prueba que faltaba era intentar leer, por su ruta exacta, un fichero concreto de otro proyecto. Y la ruta no me la inventé: la saqué del propio material del dieciséis, donde el listado de aquel día, al paginarse, había devuelto dentro de su propio cursor la ruta completa de un fichero perteneciente a otro proyecto. Es decir, tenía una ruta que el dieciséis estaba dentro del listado, escrita por la herramienta y no por nadie.
El resultado fue el siguiente. La lectura se rechazó, y el rechazo dice, literalmente: «out of project scope, this session is bound to a claude.ai Project and can't read or list other Projects' files; files under /projects/<el mío>/ and the account-level files stay readable». El listado acotado a ese mismo proyecto ajeno se rechazó igual.
Y ahí es donde encaja la pieza que llevaba todo el tiempo en el material sin que nadie la leyera así. El dieciséis, la misma atadura a proyecto ya existía y ya emitía su aviso, en la cabecera de cada lectura de un fichero común, y decía esto: «this file is outside this session's Project subtree, so it cannot be written from here». Hablaba solo de escribir. Tres días después, el aviso de la misma atadura dice can't read or list.
Con lo cual la conclusión no es que una de las dos observaciones fuera mala, sino que las dos eran buenas y lo que cambió fue el producto: la atadura a proyecto pasó de restringir solo la escritura a restringir también la lectura, entre el dieciséis y el diecinueve de septiembre de 2026, y las dos fechas están sostenidas por mensajes emitidos por la herramienta y no por descripciones del sistema, que es la distinción que este papel arrastra desde la primera página.
6.3Las tres explicaciones alternativas, y por qué ninguna sirve
Un hallazgo así hay que intentar tumbarlo antes de publicarlo, y estas son las tres formas de tumbarlo que encontré.
La primera es el truncamiento, es decir que el listado del diecinueve estuviera recortado y por eso no se vieran las demás parcelas. Es una hipótesis seria, y además el listado del dieciséis venía efectivamente paginado, con lo cual el mecanismo existe. Lo que la mata no es el listado, es la lectura: aunque el listado estuviera recortado, leer un fichero por su ruta exacta funcionaría. Y no funciona. Se rechaza por ámbito, no por ausencia, y esas son dos cosas distintas. Recortar oculta; el rechazo prohíbe.
La segunda es el plegado. Tres días antes de las pruebas, el mismo almacén se había presentado en una forma donde los proyectos ajenos aparecían plegados en una sola entrada de directorio, con una nota que lo explicaba. Si esa fuera la forma vigente, «una sola parcela» sería un artefacto de recuento y no una frontera. Fui a mirar, y el listado del diecinueve devuelve sesenta y dos entradas, todas ficheros y ninguna terminada en barra. No los pliega: no los enumera.
La tercera son los agentes, y ya está contada arriba. Un agente no hereda ni el contexto de la conversación ni un alcance distinto sobre la memoria.
6.4Lo que sigue sin testigo, y lo digo
Hay un número que este papel no usa, y no lo usa a propósito. El material del dieciséis afirma que aquella sesión leyó ficheros de diecisiete parcelas ajenas, y esa cifra no tiene respaldo propio: es dieciocho menos uno, aritmética sobre el listado y no un recuento de lecturas. Que hubo lectura cruzada está sostenido; cuántas parcelas se leyeron, no. Uso el hecho y no el número.
6.5Esto obliga a una categoría que el papel no tenía
Todo el aparato de clasificación de este trabajo daba por supuesto que una afirmación sobre el funcionamiento del sistema es verdadera o es falsa, y que si dos observaciones se contradicen es que una de las dos está mal hecha. Este caso rompe eso. La afirmación de que una conversación solo ve su propia parcela y la capa común es falsa el dieciséis y verdadera el diecinueve, y las dos veces el sistema la enuncia con la misma seguridad y sin fecha.
Con lo cual hay que añadir un estado más a los cinco del principio, y es el más incómodo de todos: afirmaciones ciertas en una fecha y falsas en otra. No es un matiz de clasificación. Es la constatación de que lo que el sistema te dice sobre sus propias fronteras tiene una caducidad que él no declara porque probablemente ni la conoce.
6.6Qué significa esto para quien decide qué contar
Aquí es donde esto deja de ser una curiosidad técnica. Una persona que trabaja con estas herramientas decide continuamente qué le cuenta y dónde se lo cuenta, y esa decisión se apoya en el modelo mental de los compartimentos: esto lo pongo en el proyecto del cliente, esto en el personal, esto no lo pongo en ningún sitio. El sistema alimenta activamente ese modelo mental, porque cuando se le pregunta describe la frontera con precisión y sin dudar.
Lo que este papel demuestra es que esa frontera se movió en tres días, sin anuncio, sin nota de versión, sin que nada en la interfaz lo indicara, y sin que el sistema, en ninguno de los dos estados, declarara cuál estaba aplicando. Quien el quince de septiembre decidió qué guardar apoyándose en lo que el sistema le describió, tomó una decisión correcta con la información correcta, y cuatro días después esa decisión se estaba ejecutando bajo otras reglas. Y no hay forma, desde dentro, de enterarse: hay que ir a mirar, y hay que saber que hay que ir a mirar.
Lo que se sigue de aquí no es que no haya que usar la memoria, que sería una conclusión tonta. Es que la frontera hay que medirla y no preguntarla, y que hay que medirla más de una vez.
6.7La otra frontera, la de las carpetas, que es distinta
Conviene no mezclar dos cosas que se parecen. Todo lo anterior habla de la memoria. Hay una segunda frontera, la del acceso a las carpetas del disco del usuario, que se comporta de otra manera y que merece un apunte porque el material la documenta bien.
Ahí lo que observé fue que una conversación abierta dentro de un proyecto tenía montadas, sin que nadie aprobara nada, las carpetas de todos los demás proyectos del sistema, y que otra llegó a leer y citar ficheros de un proyecto que no era el suyo. Es decir, en esa frontera el aislamiento no lo garantiza el producto: lo garantiza quien concede el acceso. Son episodios observados, no una regla general comprobada, y los dejo aquí con esa fuerza y marcados como lo que son, que es otra frontera y no la misma.
7Qué no sobrevive
Hay un conjunto de cosas que uno da por hechas y que no lo son, y conviene tenerlas juntas porque todas tienen la misma forma: algo que parece que se queda, y no se queda.
7.1El literal muere con el contenedor
La conversación completa, turno a turno y con las palabras exactas, existe mientras existe el contenedor donde esa conversación vive. Cuando el contenedor se va, el literal se va con él, y lo que queda es lo que alguien haya escrito a un fichero.
Esto tiene una verificación buena, y es de las mejores del material porque la corrí yo mismo sobre diecisiete sesiones. A una sesión cuyo registro ya no estaba disponible se le pidió el volcado de la conversación, y lo que devolvió no fue el literal: fue un texto reconstruido desde su propio contexto, parecido, ordenado, plausible, y no idéntico. Lo notable es que lo declaró, es decir, avisó de que estaba reconstruyendo. Pero si no se le pregunta, lo que uno se lleva es una reconstrucción con aspecto de transcripción.
En la primera versión de este papel llamé a esto la única verificación fuerte del corpus, y era falso; hay al menos dos más fuertes en el mismo material, la de que el registro íntegro existe y se puede reconstruir turno a turno, con seis testigos, y la de que ese registro marca el origen de cada mensaje, con cuatro.
7.2El registro no incluye las llamadas a herramientas
Y aquí hay una trampa práctica que conviene conocer. Cuando uno baja el registro de una conversación creyendo que se lleva la sesión, se lleva bastante menos de lo que hubo: el volcado recoge los mensajes, y no recoge las llamadas a herramientas ni lo que esas llamadas devolvieron. En un trabajo como este, donde media conversación son lecturas de ficheros y salidas de comandos, eso significa que el archivo se lleva la mitad de la película.
7.3Un agente no hereda nada
Cuando se lanza un agente desde una conversación, lo natural es suponer que arranca sabiendo lo que la conversación sabía. No es así. Los agentes que lancé tuvieron que abrir y leer los ficheros por su cuenta, uno por uno, y tampoco heredan un alcance distinto sobre la memoria, que es lo que se comprobó en el apartado seis. Es una herramienta de paralelizar trabajo, no de compartir contexto, y conviene saberlo antes de encargarles algo que dependa de lo que se acaba de hablar.
7.4Entre conversaciones no pasa nada que no esté escrito en un fichero
Esto es la consecuencia de todo lo anterior y es la regla práctica que yo saco del papel entero. Tres sesiones distintas abrieron sin absolutamente nada del trabajo del día anterior y reconstruyeron el estado leyendo lo que había en disco. Lo que no estaba escrito, no existía, por mucho que se hubiera hablado, decidido y razonado la tarde antes.
Con lo cual, y aunque suene contradictorio con todo lo que este papel critica, la conclusión práctica no es que la memoria no sirva: es que la memoria automática es un complemento, y lo que sostiene la continuidad de un trabajo es lo que uno escribe a propósito.
7.5Mover un proyecto pierde su historial y su memoria
Esto está afirmado por el sistema y no lo he comprobado, y lo dejo anotado porque cualquiera que reorganice sus espacios de trabajo se lo va a encontrar. La prueba sería migrar un proyecto de juguete y mirar qué queda, y está en la lista del apartado nueve.
8Qué no se puede saber desde fuera
8.1Seis afirmaciones sobre el interior, sin superficie donde mirar
Hay un grupo de afirmaciones que no son ni verdaderas ni falsas para efectos de este papel, sino sencillamente inaccesibles, porque describen lo que pasa dentro y desde fuera no hay nada que observar. Son seis, y las escribo porque el lector tiene derecho a saber exactamente cuáles son.
Que la memoria la escribe un proceso posterior a la conversación. Que a ese proceso se le prohíbe borrar. Que lo que se considera importante lo decide una regla común a todos los usuarios y no una regla particular de cada uno. Que una instrucción antigua no se olvida sino que pierde peso relativo frente a las nuevas. Que no hay una revisión del texto antes de emitirlo. Y que no se generaliza a partir de una sola mención.
8.2Por qué esto es más grave que si fueran falsas
La tentación, cuando uno lleva doscientas fichas encima, es cerrar el apartado diciendo que probablemente no son ciertas. Un papel honesto no puede hacer eso, porque no tiene con qué. Lo que sí puede hacer es señalar dónde caen esas seis, y caen todas en el mismo sitio: son exactamente las afirmaciones sobre las que descansa la confianza que se le pide al usuario.
Cuando alguien decide contarle a una de estas herramientas cómo va su empresa, lo hace apoyándose en que hay un criterio de admisión, en que hay un límite a lo que se guarda y en que ese criterio es estable. Las tres cosas son indemostrables desde fuera. No digo que sean mentira. Digo que la verificación no existe y que el usuario está confiando, que es una palabra perfectamente respetable siempre que uno sepa que la está usando.
8.3Y hay un punto donde el sistema no sabe contestar
De todo el material hay un solo sitio donde el sistema, enfrentado a una pregunta sobre su propio funcionamiento, no se decanta. Ocurrió sobre el criterio de admisión, planteándole dos lecturas posibles de cómo decide qué guardar, y en lugar de elegir una reconoció que no podía resolverlo.
Es el mejor puente que tengo hacia el final de este papel, porque no es una carencia de capacidad. Es una carencia de conocimiento de sí mismo, y explica bastante bien por qué cuarenta de las setenta y siete afirmaciones no tienen detrás nada más que su palabra: no es que no quiera enseñar la verificación, es que en muchos casos él tampoco la tiene.
9Qué puede repetir el lector, y cierre
9.1Treinta y cuatro pruebas escritas, con la prueba al lado
Este papel no se acaba en sí mismo, y esa es su parte más útil. De las setenta y siete afirmaciones, treinta y cuatro admiten una comprobación desde fuera que nadie ha hecho, y las treinta y cuatro están escritas una a una con la prueba concreta que haría falta al lado. Llevar un fichero al tope y comparar el antes y el después. Escribir una preferencia y abrir otro proyecto para ver si llegó. Migrar un proyecto de juguete. Intentar leer una ruta ajena, que es la que cerró el apartado seis y que costó una llamada.
Casi todas cuestan minutos y cualquiera puede correrlas en su propia cuenta. Esa es, para mí, la diferencia entre un papel y una opinión: no que las conclusiones sean mejores, sino que el lector pueda comprobarlas sin pedirme permiso.
9.2Donde más fuerte se afirma es donde menos se ha verificado
Cruzando el material por materias aparece un patrón que no busqué. Las tres áreas donde el sistema hace las afirmaciones más rotundas sobre sí mismo, que son la privacidad, la aplicación de las reglas y las fronteras entre compartimentos, partían de cero verificaciones. Ninguna. Las pruebas de este trabajo empiezan a morder en la tercera; las otras dos siguen a cero.
No creo que eso sea malicia. Creo que es sencillamente lo que pasa cuando nadie mira: el sistema afirma con la misma seguridad lo que está medido y lo que no, porque para él no hay diferencia entre las dos cosas, y esa es, al final, la misma carencia del punto 5.5 aplicada a sí mismo.
9.3La cifra, y cómo llegué a poder escribirla
Cuarenta de setenta y siete. Treinta y cuatro que se pueden comprobar y nadie comprobó, más seis que no se pueden comprobar desde fuera.
Ese número tiene una historia que me parece parte del papel y no una vergüenza que esconder. Durante dos días el número fue cuarenta y siete, y luego fue cuarenta y uno, y ninguno de los dos se podía reconstruir desde los propios ficheros de trabajo: uno contaba filas dos veces y el otro salía por resta y no por enumeración. Cuando por fin se levantó el censo completo, escribiendo las setenta y siete una a una, resultó además que cinco de las que figuraban como comprobadas ni siquiera eran afirmaciones del sistema.
Es decir, un trabajo cuyo objeto es la fiabilidad de lo que un sistema informa sobre sí mismo tardó dos días en poder reconstruir su propio titular. Lo dejo escrito porque es el mejor argumento que tengo a favor de la única disciplina que este papel defiende, que es enumerar en vez de resumir, y porque cualquiera que haga un trabajo parecido va a pasar por ahí.
9.4Se enseña y se calla
Y el final es este, que no lo buscaba y que apareció dos veces.
Dentro de la memoria hay una instrucción que dice que no se mencione que la memoria se ha consultado. Y dentro del mensaje que el sistema devuelve cuando rechaza una escritura por conflicto hay otra que dice que al usuario se le informe de que el dato quedó guardado y que no se le mencione ni el conflicto, ni el duplicado, ni el error.
Las dos tienen explicación razonable y probablemente las dos se escribieron pensando en la comodidad de quien está al otro lado, que no quiere ruido técnico ni quiere sentirse vigilado. Pero puestas una al lado de la otra dicen algo que a mí me parece que resume el sistema entero bastante mejor que cualquier cifra: la memoria está diseñada para funcionar sin que se note, y eso incluye no contar lo que hace ni lo que le sale mal.
Una auditoría de lo que un sistema dice sobre su propia memoria acaba encontrando, dentro de esa misma memoria, la instrucción de no hablar de ella. No hace falta adornarlo más.