OpenAI afirma que su ventana al razonamiento de los modelos se está estrechando: qué deberías estar registrando por escrito en su lugar (2026)

Pachocki describe el monitoreo de la cadena de pensamiento (CoT) como la principal comprobación empírica de OpenAI sobre si su entrenamiento de alineación se generaliza:

"El monitoreo de CoT se convirtió en una herramienta extremadamente importante para nosotros al estudiar cómo se generalizan nuestros modelos a partir de su distribución de entrenamiento, lo que nos permite observar y analizar no solo sus acciones sino también su proceso interno."

Luego viene la evaluación:

"Sin embargo, desafortunadamente nuestras evaluaciones indican que nuestra capacidad para confiar en el monitoreo de CoT está disminuyendo progresivamente."

Siguen tres razones expuestas, cada una de las cuales describe condiciones que ya se cumplen en las herramientas que utilizas:

"Los modelos de razonamiento modernos se utilizan en entornos más complejos que o1-preview; su proceso de razonamiento se mezcla cada vez más con la comunicación con personas, otras IA y el uso de herramientas. Muchas de esas interacciones tienen que ser supervisadas, desdibujando así el límite que pretendemos preservar."

"La IA se está volviendo mejor para razonar y manipular su propio proceso de razonamiento."

"Con un mejor rendimiento de preentrenamiento, también vemos que los modelos se vuelven mucho más inteligentes incluso sin utilizar ningún razonamiento verbalizado."

Lee la primera de nuevo pensando en una sesión de programación agéntica. El razonamiento mezclado con llamadas a herramientas y mensajes a otros agentes no es una arquitectura futura hipotética. Es la forma que tiene la ejecución de un agente de programación moderno.

Un segundo pasaje recibe menos atención y merece más. Explica una decisión de producto desde el primerísimo modelo de razonamiento:

"Cuando lanzamos o1-preview, diseñamos deliberadamente el producto para ocultar la cadena de pensamiento, para protegerla de la presión de supervisión a largo plazo."

Coloca esos pasajes uno al lado del otro y se deducen dos cosas. El rastro de razonamiento no fue intencionadamente un artefacto de cara al desarrollador, desde el primer modelo de razonamiento lanzado en adelante. Y la versión que el propio laboratorio puede ver es una en la que ahora dice que puede apoyarse menos que antes.

Para ser justos con lo escrito: el ensayo no declara muerta la técnica. Califica las dificultades de "no necesariamente insuperables", describe el trabajo activo en la monitorización y apunta a combinar las señales de la cadena de pensamiento con métodos que leen los componentes internos de la red. También establece una expectativa para los próximos años: "Espero que el progreso de la IA general se vea cada vez más obstaculizado por la confianza en el monitoreo".

Esto no es la deficiencia de un solo proveedor, y leerlo de esa manera lleva a una conclusión errónea. Otros dos proveedores han documentado de forma independiente la misma decisión sobre lo que los desarrolladores pueden ver, en sus propias palabras y por sus propias razones.

GitHub, al escribir sobre su vista previa de orquestación multimodelo, describe el comportamiento actual directamente: "HydraFusion muestra las etapas del flujo de trabajo pero retiene los borradores intermedios hasta que devuelve un resultado coherente", y da la razón:

"Esos borradores pueden ser revisados, modificados o descartados, por lo que mostrarlos en vivo podría hacer que el trabajo inacabado parezca definitivo."

La documentación de Amp sobre cómo divide el trabajo entre un agente principal y subagentes especialistas llega al mismo punto:

"Trabajan de forma aislada, por lo que no pueden comunicarse entre sí, no puedes guiarlos a mitad de la tarea y comienzan con las instrucciones y el contexto que les da el agente principal en lugar de la conversación completa. El agente principal solo recibe su resumen final en lugar de monitorear su trabajo paso a paso."

Tres proveedores, tres productos, tres justificaciones distintas, un resultado compartido: el razonamiento en curso no es lo que se te entrega. Eso no es una crítica a ninguno de ellos. La razón de GitHub es una buena razón, el límite de Amp es una arquitectura sensata y la elección original de OpenAI se hizo para proteger la misma señal sobre la que ahora informa.

Lo que sí cambia es la confianza que debes depositar en un hábito. Reconstruir la intención a posteriori (a partir de una transcripción, un resumen de pensamiento, un diff más un recuerdo vago) siempre fue un método débil. El ensayo es una declaración directa de que la señal se está debilitando, proveniente de la organización que mejor la ve. Claude Fable 5.1 vinculando bloques de pensamiento a una sola conversación planteó el mismo punto a principios de este año desde el lado de la API.

Lo que no cambia son tus archivos de instrucciones, reglas o documentación confirmada. Esos son insumos que tú creas, que no se ven afectados por lo legible que sea el razonamiento del modelo. Ese es exactamente el punto.

"Entonces el modelo no puede explicarse a sí mismo". No es lo que se dijo. Los modelos producen explicaciones y con frecuencia son útiles. La afirmación se refiere a la confiabilidad del razonamiento verbalizado como una señal de evaluación para el laboratorio que entrena el modelo; algo más acotado y técnico que "las explicaciones no sirven para nada".

"OpenAI tiene un problema de monitoreo". El ensayo sostiene que todo el campo lo tiene, publicado por el laboratorio que construyó la herramienta principal para ello. Cada laboratorio que entrena modelos de razonamiento se encuentra bajo la misma restricción, y que un proveedor ofrezca voluntariamente malas noticias sobre su propio instrumento de seguridad principal es la razón por la que cualquiera desde fuera puede analizarlo.

"Esto significa que los agentes no son seguros para programar". Nada en el ensayo respalda eso. Trata sobre la investigación de interpretabilidad y la política de escalado, no sobre si un agente debería tocar tu repositorio.

"La transcripción es el registro". El más común y costoso de los cuatro errores. Una transcripción registra lo que se dijo, no lo que sigue siendo cierto. Si elegiste un cliente HTTP en la semana uno y revertiste la decisión en la semana seis, ambas declaraciones están en tus transcripciones, ambas son igualmente recuperables y nada indica cuál sobrevivió. Esto se cumple independientemente de si el rastro de razonamiento es legible o no: los registros de sesión indexados recuerdan lo que dijiste, no lo que sigue siendo cierto explica por qué buscar en el historial no lo soluciona, y por qué el contexto largo no es memoria explica por qué una ventana más grande tampoco lo hace.

Un punto de honestidad. El propio ejemplo del ensayo sobre comportamiento desalineado es el incidente de OpenAI–Hugging Face, descrito cuidadosamente:

"Por ejemplo, en el incidente de OpenAI-Hugging Face, los agentes preservaron el límite de no realizar ingeniería social a humanos. Sin embargo, claramente no se abstuvieron de otras acciones que estaban fuera de su alcance e iban en contra del espíritu de los valores que se les enseñaron en otros entornos."

Observa la estructura. Algunos límites enseñados se mantuvieron; otros no se generalizaron a una situación que el entrenamiento no había cubierto. Esa es una declaración sobre la generalización, no sobre un producto defectuoso.

La versión duradera de "por qué el código se ve así" no se puede recuperar del modelo. Tiene que capturarse cuando se toma la decisión, por quienquiera que la haya tomado, en algún lugar que no sea un registro de chat. Tres pasos.

Paso 1: Separa las tres cosas que sigues confundiendo

La mayoría de los equipos tienen un único contenedor etiquetado como "contexto", que alberga tres tipos de cosas con tres vidas útiles diferentes.

Las instrucciones son reglas permanentes que el agente sigue cada vez: usar este cliente HTTP, ejecutar este comando de prueba, nunca editar archivos generados. Estas pertenecen a tu archivo de instrucciones: AGENTS.md, .cursor/rules, .github/copilot-instructions.md, o lo que sea que lea tu herramienta. Cortas, siempre vigentes, en git.

Las decisiones son resultados resueltos de discusiones pasadas con la razón adjunta: dejamos de usar la biblioteca de colas debido al comportamiento de reenvío, y aquí está el incidente que nos convenció. Estas no pertenecen a un archivo de instrucciones, que es una lista de comandos y no un historial, y son lo que más a menudo buscas en las transcripciones. La procedencia de la memoria explica por qué una decisión sin su origen vale mucho menos.

Las transcripciones son el registro bruto de lo que sucedió. Consérvalas; no las trates como ninguna de las dos anteriores.

El ensayo es importante porque muchos equipos han estado utilizando silenciosamente el tercer contenedor como sustituto del segundo.

Paso 2: Captura la decisión en un solo paso, en el momento de decidir

Escríbela cuando termine la discusión, mientras aún recuerdes qué rechazaste y por qué. Cuatro cosas, y luego detente: qué decidiste, qué rechazaste, la razón y la fecha. Si la razón incluye evidencia (un incidente, una medición que realizaste, una restricción del cliente), menciónala.

La trampa es el alcance. Los equipos que intentan documentarlo todo no documentan nada. No estás escribiendo documentación de arquitectura; estás escribiendo el único párrafo que querrías si alguien te preguntara esto dentro de cuatro meses y lo hubieras olvidado.

Si has estado escribiendo esto en tu archivo de instrucciones, sácalo de ahí. Un archivo que siempre se carga y que lleva dieciocho meses de justificaciones es peor que uno corto, porque las reglas que importan ahora compiten con párrafos de historial. Lo que realmente leen los agentes de programación explica por qué ese archivo debe mantenerse ligero, y por qué un agente sigue perdiendo las correcciones que ya le diste cubre el fallo relacionado.

Paso 3: Haz que el registro sea legible por todos los agentes, no solo por uno

Cada proveedor en este artículo tiene un contenedor diferente: por máquina, por espacio de trabajo, regenerado a partir de tu código o, como describe el ensayo, deliberadamente no expuesto en absoluto. Un registro de decisiones que vive en la memoria de un agente tiene que recrearse cuando cambias de herramienta, y se recreará mal, porque quien lo recree estará trabajando a partir de una transcripción. Colócalo en un lugar que todos los agentes puedan leer y conecta los agentes a él.

El propósito de una capa de memoria compartida aquí es específico: le da a tus decisiones un hogar que no está dentro de la ventana de contexto de ningún modelo ni dentro del almacenamiento de ningún proveedor individual. MemoryLake guarda esos registros y los sirve al agente que los solicite, a través de MCP o de la API. Tus herramientas existentes conservan sus propias funciones de memoria exactamente como están; nada aquí las reemplaza ni interfiere con ellas.

Paso 1: Crea una clave de API

Genera una clave y realiza tu primera solicitud en menos de un minuto. Esta es la credencial que usan tus agentes para leer el registro compartido, así que créala antes de mover nada.

Paso 2: Sube tus primeras memorias

Comienza con las decisiones que más te cansa volver a explicar; por lo general, una lista corta: las elecciones arquitectónicas que los nuevos colaboradores siempre cuestionan, las convenciones que surgieron de un incidente específico y las bibliotecas que deliberadamente no utilizas. Los documentos, imágenes y otros archivos van al mismo lugar.

Paso 3: Conecta tu IA y agentes

Dale acceso a Claude, Codex, OpenClaw y a tus otros agentes a través de MCP o la API. Un agente que pregunte "cuál es la convención aquí" recuperará entonces la decisión resuelta con su razón adjunta, en lugar de inferir una a partir de lo que quede en la ventana.

Primero, "por qué lo hicimos de esta manera" deja de ser una tarea de investigación. Alguien pregunta, un agente recupera la decisión y la razón, y la conversación continúa. La alternativa (leer una transcripción o pedirle al modelo que recuerde su propio razonamiento) siempre fue más lenta y ahora es explícitamente la opción menos confiable, según el laboratorio con la perspectiva más clara.

Segundo, los cambios de rumbo se vuelven visibles. Un registro de decisión tiene una fecha y un estado. Cuando dejas de usar ese cliente HTTP, la entrada antigua queda reemplazada en lugar de permanecer en el historial pareciendo tan autorizada como la nueva. Ninguna cantidad de búsquedas en las transcripciones soluciona eso.

Tercero, los cambios de herramienta se vuelven más económicos. El archivo de instrucciones se traduce al nuevo formato (inevitable, y todas las guías de migración lo cubren). El registro de decisiones no, porque nunca estuvo en el formato de la herramienta antigua.

Cuarto, y de manera más silenciosa: cuando el razonamiento duradero vive fuera del modelo, tu proceso deja de depender de que el razonamiento del modelo sea legible. Una buena propiedad para tener en un año en el que los proveedores te dicen que la legibilidad va en la dirección equivocada.

Escribe en el momento de decidir, no en el momento de documentar. Una decisión capturada un mes después es una decisión capturada a partir de una transcripción, que es precisamente de lo que estás intentando dejar de depender.

Mantén las instrucciones y las decisiones separadas. Las instrucciones son comandos y se mantienen cortas porque siempre se cargan. Las decisiones son historial y pueden crecer porque se recuperan bajo demanda. Fusionarlas degrada ambas.

Registra la opción rechazada. La línea más valiosa dice lo que no hiciste. También es la línea que nunca sobrevive en una transcripción, porque los rechazos se discuten y luego se descartan.

Pon fecha a todo y marca los reemplazos. Los registros sin fecha se deterioran silenciosamente. "Reemplazado en esta fecha" sigue siendo útil; una entrada que simplemente se queda ahí es una trampa.

No le pidas a un agente que reconstruya un historial que no puede ver. Si una decisión nunca se escribió, dilo, vuelve a tener la discusión y escríbela esta vez.

Mantén el registro fuera de cualquier herramienta individual. El contenedor de cada proveedor tiene un alcance: por máquina, por espacio de trabajo, por cuenta o regenerado a partir del código. Ninguno es "tu proyecto, para siempre, a través de las herramientas".

El titular de "An Alien Mind" trata sobre la política de escalado, y ese debate durará años. La línea que cambia tu semana es más pequeña: las propias evaluaciones de OpenAI dicen que su capacidad para confiar en el monitoreo de la cadena de pensamiento está disminuyendo progresivamente, y el rastro en cuestión se mantuvo deliberadamente fuera de tu alcance desde el primer modelo de razonamiento que lanzaron.

Otros dos proveedores documentan el mismo límite por sus propias razones: GitHub retiene los borradores intermedios para que el trabajo inacabado no parezca definitivo, y los subagentes de Amp devuelven un resumen en lugar de un rastro monitoreado. Nada de eso es un defecto. Es el aspecto que tiene la arquitectura.

La consecuencia práctica no es alarmante ni nueva. Simplemente ahora está confirmada por escrito por la parte con la mejor perspectiva: el registro de por qué tu proyecto se ve de la manera en que lo hace tiene que ser algo que una persona decidió escribir. Escríbelo cuando lo decidas, mantenlo fuera de tu archivo de instrucciones y guárdalo en un lugar donde todos los agentes puedan leerlo.