Toda sesión nueva con un asistente de IA empieza con el mismo ritual: explicar de nuevo el proyecto, las decisiones ya tomadas, las preferencias ya acordadas. En el post sobre agentes fuera del laboratorio enumeré el contexto que se evapora como uno de los cuatro huecos clásicos. Entre una sesión y otra, el hueco se vuelve regla: se evapora todo. La solución que uso todos los días en este blog no es una plataforma nueva ni una base vectorial: es un archivo Markdown versionado en git.
El recomienzo cuesta más de lo que parece
El costo visible es el tiempo de volver a explicar. El costo invisible es peor: una lección pagada una vez vuelve a cobrarse. Un ejemplo real de aquí: “una imagen antigua después de publicar casi siempre es caché del navegador, no un defecto”. Esa lección costó una cacería de un bug que no existía. Sin memoria, cada sesión nueva habría repetido la cacería; con memoria, se volvió una línea que el asistente lee antes de empezar, y el falso defecto murió ahí.
Lo mismo vale para las decisiones. Una elección discutida y cerrada un día reaparece como pregunta abierta la semana siguiente, porque quien preguntó olvidó que ya tenía respuesta. Una decisión rediscutida sin necesidad no es solo desperdicio: es el riesgo de decidir distinto sin darse cuenta.
Un archivo Markdown, versionado junto con el proyecto
La implementación cabe en una frase: un archivo MEMORIA-PROJETO.md en la raíz del repositorio, que el asistente lee por completo al inicio de cada sesión y devuelve actualizado al final. En la publicación, estaba en la séptima versión, con fecha e historial de cada consolidación en el pie.
El archivo guarda cuatro tipos de contenido, todos cortos y directos:
- Preferencias: cómo le gusta al dueño del proyecto que se haga el trabajo;
- Lecciones: el bug resuelto y la causa, el enfoque que falló, la corrección que vino de afuera;
- Convenciones: los flujos y los patrones que se repiten;
- Decisiones con motivo: qué se eligió y por qué, para no rediscutir desde cero.
Versionar junto con el proyecto cambia la naturaleza de la memoria. Cada actualización se vuelve un diff revisable, como cualquier cambio de código. La memoria deja de ser una caja negra de la herramienta y pasa a ser un artefacto del proyecto, que cualquier persona (o cualquier asistente) puede abrir, auditar y corregir.
La prueba de los siete días decide qué entra
La regla de corte es una pregunta: ¿esta información seguirá siendo válida dentro de una semana? Si no, no pertenece a la memoria. El progreso de la tarea, lo pendiente, el próximo paso: todo eso envejece en días y vive en otro archivo, un control de estado propio, actualizado en cada avance.
La separación parece burocracia y es lo contrario: es lo que mantiene vivo el archivo. Mezclar los dos entierra las lecciones permanentes debajo de un estado que se pudre. El archivo de memoria que se vuelve depósito de todo deja de leerse, y la memoria que no se lee no es memoria.
Hecho declarativo, nunca una orden para el futuro
La forma de escribir cada ítem importa más de lo que parece. Registrar “el dueño prefiere respuestas cortas” funciona; registrar “responda siempre corto” falla. La diferencia: la orden imperativa se vuelve a ejecutar en toda sesión futura sin el contexto en el que tuvo sentido, incluso en los días en que la respuesta necesitaba ser larga.
El hecho declarativo es contexto; la orden grabada es un comando ciego. Y de ahí sale la regla de conflicto: cuando la instrucción de ahora contradice lo que está grabado, vale la instrucción de ahora, y el conflicto se declara en voz alta, nunca se resuelve en silencio. La memoria orienta; quien manda es el presente.
Lo que nunca entra en el archivo
El secreto no entra. Contraseña, token, clave de API: en un archivo versionado, secreto grabado es secreto filtrado. Lo que se registra es la convención a su alrededor — “las claves viven en variables de entorno” — nunca el valor.
Y nada entra solo. El asistente propone qué registrar; quien aprueba es el dueño, y el diff de la actualización muestra exactamente qué cambió. Es el mismo principio del gate humano que protege lo que este blog publica: el agente pone la propuesta sobre la mesa, y la decisión sigue siendo de quien responde por ella.
Adónde no llega el archivo
Los límites son reales y conviene declararlos. El método exige disciplina de consolidación: sin el ritual de actualizar al final de la sesión, el archivo se congela y miente. Crece, y necesita una poda periódica para seguir siendo legible. Y es contexto de un proyecto: no sustituye la búsqueda semántica en una base de conocimiento grande, ni resuelve la memoria compartida de un equipo entero.
Las plataformas de IA tienden a ofrecer memoria automática propia, y ayuda. El archivo manual mantiene dos ventajas que ninguna de ellas entrega: es inspeccionable (se puede leer exactamente lo que la herramienta “sabe” y corregir lo que esté mal) y es portable (la memoria pertenece al proyecto, no al proveedor: cambiar de herramienta no borra lo aprendido).
Para empezar hoy
- Cree un
MEMORIA-PROJETO.mden la raíz del proyecto con tres secciones: preferencias, lecciones aprendidas, convenciones. - Acuerde el ritual con el asistente: leer el archivo al inicio de la sesión y confirmar en una línea.
- Durante el trabajo, anote lo que pase la prueba de los siete días, y solo eso.
- Al final de la sesión, consolide: fusionar con lo que existe (nunca duplicar), fechar e incrementar la versión.
- El progreso de la tarea va a un archivo de estado separado; el secreto no va a ninguno de los dos.
Un modelo más grande no resuelve el olvido entre sesiones; un archivo simple lo resuelve. La memoria de proyecto no es solo contexto reutilizado: es la diferencia entre un asistente que trabaja en su proyecto y uno que vuelve a empezar en él cada mañana.
Fuentes
- Pieza basada en experiencia propia: la práctica descrita está en uso en este blog, con el archivo de memoria del proyecto en la séptima versión en la fecha de publicación (verificado el 2026-07-27). No se citó ningún número ni ninguna afirmación de terceros.
