Por qué ChatGPT olvida tus decisiones de arquitectura y cómo solucionarlo (2026)

Una decisión es una restricción más un motivo

"No compartimos la base de datos entre servicios" es la mitad de una decisión. La otra mitad es porque el orden de las migraciones causó dos caídas del servicio y el equipo propietario del esquema no puede autorizar cada despliegue. Sin la segunda mitad, la primera es solo una preferencia, y una preferencia siempre pierde frente a una alternativa que suene plausible.

Por esto existe la práctica de los registros de decisiones de arquitectura (ADR): un ADR empareja la decisión con el contexto que la forzó y las consecuencias resultantes, precisamente porque los equipos descubrían una y otra vez que una decisión sin justificación no sobrevive al contacto con nuevas personas o nuevas circunstancias. Un asistente es una persona nueva en cada sesión.

El motivo es lo que se elimina al resumir

Este es el mecanismo que hace que esto sea peor que el olvido común. La memoria guardada de ChatGPT es corta por diseño, porque se envía junto con cada prompt. Y desde la actualización del sistema de memoria que OpenAI anunció en junio de 2026, lo que obtienes es un resumen de memoria (un relato sintetizado de lo que el sistema concluyó sobre ti, que se mantiene actualizado con el tiempo) en lugar de una transcripción de lo que dijiste.

La síntesis es la solución ideal para mantener útil una memoria pequeña, pero es la incorrecta para las decisiones. Si comprimes "no compartir la base de datos porque el orden de las migraciones causó dos caídas del servicio", el resultado natural es "prefiere bases de datos propias por servicio". La restricción desaparece; la preferencia permanece; la preferencia es anulable. Terminas con un asistente que recuerda a medias tu arquitectura como si fuera una elección de estilo.

Las opciones rechazadas nunca se escriben

El contenido más valioso en una discusión de arquitectura es la lista de cosas que descartaste y por qué. También es el contenido que nadie registra, porque en el momento en que descartas algo parece obvio y no crees que valga la pena escribirlo.

Nada en el flujo de trabajo de un chat lo captura. Así que se vuelven a proponer las mismas tres alternativas cada trimestre, y cada vez pasas veinte minutos volviendo a deducir por qué no funcionan; este es el patrón detrás de un asistente que resurge repetidamente ideas que ya rechazaste.

No hay un archivo para ello, a diferencia de un agente de programación

Los agentes de programación resolvieron la mitad de la disponibilidad de este problema con archivos cargados en cada solicitud, razón por la cual el hecho de que Cursor olvide decisiones de arquitectura generalmente se puede solucionar escribiendo un mejor archivo de reglas.

ChatGPT no tiene un equivalente. No hay una ruta que lea antes de responder. Las instrucciones personalizadas son pequeñas y globales. Los archivos adjuntos de un Project están limitados a ese Project. La memoria es de una o dos páginas. Ninguno de ellos es un registro de decisiones, por lo que tu arquitectura vive en la última conversación en la que la discutiste.

Las decisiones cambian y la anterior no se retira

La arquitectura tiene versiones, la gestiones activamente o no. Revisas el modelo de tenencia en el tercer trimestre, y cada diseño realizado bajo el modelo del segundo trimestre era correcto en ese momento. Un flujo de trabajo basado en chat no tiene un lugar para registrar que una decisión reemplazó a otra en una fecha determinada, por lo que terminas sin poder interpretar tu propio trabajo pasado, que es precisamente el modo de fallo que los ADR buscan prevenir con su campo de estado.

Explicarlo de nuevo cada vez. Funciona, pero se degrada. Estás repitiendo de memoria, por lo que la versión que escribes en septiembre es la mitad resumida de la versión que definiste en julio, y la restricción es la parte aburrida.

Poner las decisiones principales en las instrucciones personalizadas. El primer paso correcto para dos o tres restricciones fundamentales, y vale la pena hacerlo. El espacio es pequeño, por lo que debes elegir qué decisiones importan más, y se aplica de forma global, lo cual es incorrecto si trabajas en más de un sistema.

Guardar decisiones en la memoria. Está bien para un par de decisiones estables, pero luego chocas contra dos muros: el espacio se agota (la memoria se llena y deja de aceptar nuevas entradas) y lo que sobrevive es una paráfrasis sintetizada en lugar del razonamiento.

Un Project con el documento de arquitectura adjunto. La mejor opción integrada. Está bien delimitado y contiene un documento real en lugar de un resumen. Pero es exclusivo de ChatGPT, los archivos no se mantienen de manera confiable en el contexto durante sesiones largas y no ayuda con la pregunta rápida que haces en un chat normal.

Escribir ADRs en el repositorio. La respuesta profesional, y merece ser dicha claramente en lugar de quedar oculta: un directorio numerado docs/adr/ con la decisión, el contexto, las consecuencias y el estado, confirmado (committed) y revisado, es cómo se supone que debe preservarse el razonamiento arquitectónico. Sobrevive a la salida de miembros del equipo, permite ver diferencias (diffs) y no depende de ningún proveedor. Si tu equipo no hace esto, empieza a hacerlo; es más valioso que cualquier otra cosa en este artículo.

La brecha es que un ADR en tu repositorio es invisible para el asistente con el que realmente estás pensando. Escribiste el razonamiento y ChatGPT aún no puede verlo, por lo que terminas copiando y pegando el que corresponde, o más a menudo, no lo haces.

Dos pasos, en este orden.

Escribe las decisiones con la estructura de un ADR, incluso de manera informal. Título, estado, el contexto que la forzó, la decisión, lo que descarta, las consecuencias que aceptaste y la fecha. La estructura importa más que la herramienta; es lo que mantiene el motivo unido a la restricción, que es de lo que trata todo el problema de este artículo. La sección de alternativas consideradas no es opcional; es la parte que evita volver a discutir lo mismo.

Luego, haz que el registro sea accesible para el asistente. No copiado y pegado, sino recuperado. Un almacenamiento del que el asistente lea en cada solicitud significa que la decisión llega con su motivo, su fecha y sus alternativas rechazadas, en la forma exacta en que las escribiste en lugar de una síntesis de ellas.

MemoryLake es una capa de memoria diseñada para eso: los registros de decisiones, las restricciones y los documentos de origen en un solo almacenamiento, legibles desde ChatGPT a través de la API y directamente desde herramientas compatibles con MCP como Claude y Codex. Así, la misma decisión llega a la conversación de diseño, al agente de programación que escribe la migración y al ingeniero que se unió en septiembre.

Dos límites que vale la pena mencionar. Una capa de memoria no reemplaza a los ADR confirmados en el repositorio para la gobernanza del equipo; un registro de decisiones que no está en el control de versiones no se puede revisar, y la capacidad de revisión es la mitad del propósito de la práctica. Además, proporcionar una decisión de manera confiable aumenta la frecuencia con la que se respeta, pero no garantiza que el asistente la cumpla, porque eso depende del comportamiento del modelo. Lo que cambia es que la restricción y su motivo están presentes y actualizados en lugar de ausentes o parafraseados.

Paso 1: Crea una clave de API

Genera una clave y realiza tu primera solicitud en unos 30 segundos. Manténla en tu entorno o en un gestor de secretos en lugar de pegarla en un chat.

Paso 2: Sube tus primeras memorias

Sube los documentos, imágenes y archivos donde realmente viven tus decisiones: los ADR, los documentos de diseño, los informes de incidentes que causaron una restricción, el RFC que alguien escribió y en el que todos estuvieron de acuerdo. Sube las fuentes en lugar de un resumen ordenado; el resumen es donde "debido a las dos caídas del servicio" se convierte en "prefiere bases de datos propias por servicio".

Paso 3: Conecta tu IA y agentes

Dale a Claude, Codex, OpenClaw y otros agentes de IA acceso a la memoria a través de MCP o la API. ChatGPT no tiene un cliente MCP, por lo que el camino allí es la API: recupera las decisiones relevantes e inyéctalas en el prompt, en las instrucciones de un GPT personalizado o en el flujo de trabajo que llama al modelo. Las herramientas que hablan MCP leen el mismo almacenamiento directamente, lo cual es importante porque el agente que escribe el código necesita las mismas restricciones que el asistente que lo diseña.

La primera diferencia es que la opción rechazada sigue rechazada. Pregunta sobre el servicio de reportes y el enfoque de esquema compartido aparecerá como descartado de antemano, con el historial de caídas del servicio adjunto, en lugar de ser propuesto como una idea nueva.

La segunda es que las conversaciones de diseño comienzan más adelante. No pasas los primeros quince minutos restableciendo restricciones; los pasas en la pregunta real. Eso se acumula: cuantas más decisiones se junten en el registro, más heredará cada nueva conversación.

La tercera es que las decisiones reemplazadas se vuelven legibles en lugar de confusas. Una decisión con fecha y estado te permite decir "ese servicio se construyó bajo el modelo de tenencia anterior a agosto" en lugar de preguntarte por qué se ve mal. Esta es la única propiedad que hace que la arquitectura pasada sea interpretable.

Y deja de ser algo específico de ChatGPT. Una decisión de tenencia restringe al agente de programación tanto como a la conversación de diseño, y un asistente que llega sin el contexto de tu proyecto es el mismo problema en cualquier herramienta. Una vez que el registro está en un almacenamiento compartido, todas lo heredan.

Escribe siempre el contexto que forzó la decisión

"Usamos event sourcing para los pedidos" invita al debate. "Usamos event sourcing para los pedidos porque finanzas requiere un registro de auditoría reconstruible y el diseño anterior de estado mutable falló una auditoría del primer trimestre" lo termina. El contexto es lo que convierte una preferencia en una restricción, y es lo primero que se pierde cuando lo repites de memoria.

Registra lo que rechazaste, no solo lo que elegiste

Dos líneas por alternativa: qué era y por qué no. Esta es la sección de mayor valor y la que menos se escribe, y es la que evita que la misma propuesta regrese cada trimestre. Si no escribes nada más allá de la decisión en sí, escribe esto.

Pon fecha a todo y conserva las decisiones reemplazadas

Dale a cada decisión una fecha y un estado, y cuando cambie, añade la nueva y marca la antigua como reemplazada en lugar de eliminarla. Eliminar la decisión antigua destruye tu capacidad para entender el código escrito bajo ella. Las decisiones sin fecha que no coinciden son peores que una marcada honestamente con una fecha.

Mantén pequeño el conjunto que siempre se carga

Lo que sea que se inyecte en cada solicitud debe ser tu puñado de restricciones estrictas, aquellas que harían que una respuesta fuera incorrecta, no simplemente no idiomática. El registro completo pertenece a la recuperación (retrieval). Un muro de historia arquitectónica frente a cada pregunta desplaza la pregunta misma.

Confirma los ADR de todos modos

Coloca los registros en el repositorio bajo control de versiones incluso con una capa de memoria implementada. El almacenamiento los hace accesibles para tus asistentes; el repositorio los hace revisables por tu equipo, y una decisión que nadie revisó no es realmente una decisión de equipo. Usa ambos para lo que cada uno es bueno.

ChatGPT olvida tus decisiones de arquitectura porque conserva preferencias, no restricciones. No hay un archivo de reglas que lea, su memoria es de una o dos páginas que se envían en cada solicitud, y el sistema de memoria actual sintetiza lo que almacena; por lo tanto, el motivo detrás de una decisión, que es la mitad que la hace vinculante, es exactamente lo que se comprime y elimina.

La solución es un consejo antiguo más un paso nuevo. Escribe las decisiones con la estructura de un ADR (contexto, decisión, alternativas rechazadas, consecuencias, fecha, estado) y confírmalas en tu repositorio, porque así es como el razonamiento arquitectónico sobrevive a las personas. Luego, coloca el registro en un lugar del que tus asistentes lean en cada solicitud, para que la restricción y su motivo lleguen juntos en lugar de esperar a que te acuerdes de copiarlos y pegarlos. Así, la discusión que tuviste en julio seguirá resuelta en septiembre.