Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Ya he contado por qué la memoria de un LLM no cabe en un solo archivo, y por qué el contexto es el activo que el PM debe construir. Eran artículos sobre el por qué.
Este habla del cómo. Voy a abrir el capó de mi motor de contexto — el sistema que vive en una carpeta 02-CONTEXT/ de mi vault — y seguir una misión real de principio a fin. En cada etapa, explicaré el bloque que entra en juego: la misión, el focus, las directrices, la lista de tareas, la cola offline, y los tres tipos de memoria.
El objetivo: que alguien que nunca haya visto este sistema entienda cómo está organizado, y sobre todo por qué está organizado así. Porque cada carpeta, cada archivo, responde a un problema que encontré trabajando con una IA en temas que duran semanas.
El principio de partida: el disco es la memoria
Una cosa que hay que dejar clara antes de todo lo demás. En este sistema, el sistema de archivos es la memoria principal de la IA. No la conversación.
Una conversación con un LLM es volátil. Se cierra la pestaña, todo se pierde. La ventana de contexto es finita, y cuanto más se llena, más se degrada la atención — es el fenómeno del Lost in the Middle del que he hablado en otro lugar. Así que en lugar de guardar todo en la conversación, se escribe todo en disco, en archivos divididos por naturaleza de información. Y en cada sesión, solo se recarga lo estrictamente necesario.
Un contexto es, pues, una carpeta. Una carpeta = una misión. No hay ninguna memoria transversal implícita entre dos contextos: lo que la IA sabe sobre el proyecto A no se filtra hacia el proyecto B. Cada misión tiene su propia cabeza.
Aquí, simplificado, tiene el aspecto de un contexto:
<contexto>/
├── 00_mission/ ← el marco estable: por qué estamos aquí, las reglas
├── 01_active/ ← el estado vivo: dónde estamos, hoy
├── 02_checkpoints/ ← las fotos de etapa
├── 03_sources/ ← el contenido bruto
├── 04_notes/ ← las ideas extraídas, relacionadas entre sí
├── 05_memory/ ← la memoria consolidada
├── 06_index/ ← el índice máquina, para que la IA se oriente
└── 07_outputs/ ← los entregables
La lógica de organización es simple pero estricta: lo que es estable (la misión, las reglas) está separado de lo que cambia en cada sesión (el estado actual), a su vez separado de el contenido bruto (las fuentes), de lo que se extrae de él (las notas) y de lo que se produce (los entregables). Nada está mezclado. Veremos que esta separación no es cosmética: es ella la que hace el razonamiento trazable en el tiempo.
Para hacer todo esto concreto, voy a seguir una misión que realmente llevé a cabo (un ejemplo simple, para facilitar la lectura): PM016 — escribir posts de LinkedIn a partir de tres artículos que publiqué en una revista de marketing. Una misión de producción de contenido, corta, pero que activa la mayoría de los bloques.
Abrir un contexto: lo que la IA carga, y lo que deja en disco
Inicio una sesión. Lo primero que hace la IA no es leerlo todo. Es leer un archivo de configuración: el manifiesto de carga (load_manifest.json). Este archivo le dice qué cargar, y qué hay que dejar en disco.
Contiene tres listas:
always_load— el núcleo, cargado cada vez. La misión, el scope, las directrices, los riesgos, el estado actual, el plan, el focus, la lista de tareas, las decisiones, las contradicciones, la ficha de reanudación, la síntesis.load_on_demand— todo lo que queda en disco y solo se carga si la tarea lo exige: las decenas de fuentes, las notas atómicas, los diarios de sesión.- Salvaguardas: no más de 12 archivos activos, aproximadamente 1200 líneas como máximo en la ventana de contexto del LLM.
Es una bandeja de cirujano. Los instrumentos esenciales ya están sacados; los demás están a mano, pero no se cubre la mesa. Un experto humano no relee todo su expediente antes de cada reunión — ha interiorizado lo esencial y va a buscar un documento concreto cuando lo necesita. Un LLM no puede interiorizar: solo tiene lo que se le da. De ahí la importancia de darle el subconjunto correcto, no todo.
En la práctica, la apertura de un contexto se hace mediante un comando — escribo /context_use pm016 — y la IA ejecuta el manifiesto: lee el núcleo, lee el último checkpoint, y está operativa. Sabe dónde estamos sin que haya tenido que reexplicarle nada.
La misión y el focus: el objetivo no es lo mismo que la atención
Zoom en las dos carpetas de cabeza — la estable y la viva:
00_mission/ ← el marco estable
├── mission.md el objetivo (no cambia)
├── scope.md el perímetro
├── directives.md cómo debe trabajar la IA
├── risks.md las amenazas a vigilar
└── glossary.md el vocabulario de la misión
01_active/ ← el estado vivo (cambia en cada sesión)
├── focus.md la atención del momento
├── current_state.md dónde estamos
├── current_plan.md adónde vamos
├── todo.md las acciones futuras
├── decisions.md lo que se ha decidido
├── contradictions.md lo que todavía no encaja
├── resume_work.md la ficha de reanudación
└── offline.md el buzón de entrada
Aquí está la primera sutileza, y probablemente la más importante de entender.
Hay dos archivos que parecen "aquello sobre lo que trabajamos", pero que no tienen nada que ver.
El primero es la misión (00_mission/mission.md). Es el objetivo. Es estable. Para PM016, la misión cabe en una frase: "escribir posts de LinkedIn basados en los tres artículos que publiqué en la revista nº 16". Esta frase no cambia durante toda la vida del contexto. Es el rumbo. El archivo vive en 00_mission/, la carpeta de las cosas estables.
El segundo es el focus (01_active/focus.md). Es la atención del momento. Cambia en cada sesión, a veces varias veces dentro de una sesión. El focus es "hoy, trabajamos en el desglose de las ideas del artículo 2 en posts distintos". No es el objetivo — es el subproblema sobre el que apuntamos el foco ahora. El archivo vive en 01_active/, la carpeta de las cosas vivas.
¿Por qué separar los dos? Porque confundir el objetivo con la atención es la mejor manera de derivar. Si la IA toma el focus del día por el objetivo de la misión, corre el riesgo de redefinir toda la misión en torno a un detalle. A la inversa, si solo tiene el objetivo ante los ojos, es demasiado vaga: "escribe posts de LinkedIn" no dice sobre qué nos concentramos en este instante. La misión da la dirección, el focus da la profundidad de campo. Se puede rehacer el focus diez veces sin tocar nunca la misión. Es exactamente como un humano: tu puesto (tu misión) no cambia porque pases la tarde en una tarea concreta (tu focus).
Alrededor de la misión, en 00_mission/, hay tres archivos más de encuadre.
El scope delimita lo que está en el perímetro y lo que no — la barrera contra la deriva del tema.
Los riesgos (risks.md) son la rejilla de las amenazas que pesan sobre la misión. En PM016, es modesto; pero en una verdadera oportunidad de producto, este archivo sigue los cuatro grandes riesgos de Marty Cagan — valor, usabilidad, viabilidad técnica, viabilidad de negocio. La idea: tener permanentemente ante los ojos las preguntas que pueden hacer fracasar el proyecto, y marcar cada riesgo a medida que un elemento lo ilumina o lo agrava. Una sección vacía = un riesgo aún no documentado, por tanto un punto ciego asumido.
El glosario (glossary.md) fija el vocabulario de la misión, para que las mismas palabras conserven el mismo sentido del principio al final. Es el mismo reflejo que en mi contexto de comunidad de propietarios, donde acabé externalizando todos los términos técnicos y acrónimos en un archivo dedicado: sin eso, cada uno — el humano y la IA — acaba usando las mismas palabras con sentidos diferentes.
Un punto importante sobre todos estos archivos, y es quizás el más contraintuitivo del sistema: no se rellenan de golpe al inicio. Se rellenan progresivamente, a lo largo de los intercambios. Y "intercambio" no significa solo "aportar un documento". La mayoría de las veces significa hablar. Hablo con la IA, pienso en voz alta, le doy un contexto que tengo en la cabeza — y es ella quien organiza ese flujo en el sitio correcto: este punto es un riesgo de viabilidad, este término merece una entrada de glosario, esta frase delimita el scope. Un riesgo no escrito se convierte en una línea en risks.md porque lo mencioné hablando, no porque abrí el archivo para rellenarlo. Es ahí donde el contexto deja de ser una carpeta para clasificar y se convierte en un secretario particular que toma nota de lo que pienso en voz alta.
Las directrices: codificar un conocimiento que la IA no tiene
Otro archivo del núcleo estable: las directrices (00_mission/directives.md).
Una directriz no habla del tema de la misión. Habla de la forma de trabajar. Es la diferencia entre los ingredientes y la receta.
Un ejemplo extraído de otro de mis contextos, donde hago procesar centenares de correos de una comunidad de propietarios: "cuando dos personas llevan el mismo apellido, usa el sentido del correo para indicar su nombre y su empresa" (dos proveedores tenían el mismo apellido). No es una información sobre la comunidad. Es una regla de procesamiento. Codifica un conocimiento que solo yo poseo, y que la IA aplica luego sistemáticamente — sin olvidar, sin cansarse.
Para PM016, una directriz típica sería: "cada post debe defender una sola idea atómica, nunca un resumen del artículo entero". Es una restricción de producción que establezco una vez, y que vale para los veintisiete posts.
Las directrices están en el núcleo always_load: se recargan, pues, en cada sesión. Una regla que se estableció en la semana 1 se aplica todavía en la semana 6, sin que yo tenga que repetirla. Es acumulativo. Cuanto más avanza una misión, más se refinan sus directrices, y más trabaja la IA como yo.
Detalle de uso: para añadir una directriz en medio de una conversación, simplemente prefijo mi mensaje con alpha directive : ... y la IA la consolida en el archivo. Existen un puñado de palabras clave como esa (decision :, contradiction :, todo :, checkpoint, fin de session) — atajos para organizar una información en el archivo correcto sin tener que decirlo explícitamente. Son solo comodidades; el corazón del sistema son los conceptos, no las palabras clave.
La lista de tareas: las acciones futuras no contaminan el razonamiento presente
La lista de tareas (01_active/todo.md) es un archivo simple pero que resuelve un problema real.
Cuando se trabaja en un tema, surgen constantemente ideas de acciones futuras. "Habrá que verificar este dato." "Habría que convertir este post en carrusel." "Pensar en releer la versión inglesa." Si se deja flotar estas acciones en la conversación, pasan dos cosas: o se olvidan, o contaminan el razonamiento en curso atrayendo la atención en todas las direcciones.
La lista de tareas es el lugar donde se depositan estas acciones para ya no tener que retenerlas en la mente. Es un backlog. Cada tarea tiene un identificador (T-NNN) y un estado. Se alimenta escribiendo todo : .... Y porque forma parte del núcleo cargado en cada sesión, ninguna acción se pierde entre dos sesiones.
Es la misma lógica que para todo lo demás: sacar una información de la memoria volátil de la conversación para depositarla en un lugar estable y nombrado.
La cola offline: hablar al contexto cuando duerme
Aquí hay un bloque en el que no se piensa al principio, y que se vuelve rápidamente indispensable: el archivo offline (01_active/offline.md).
El problema: las ideas no vienen solo cuando se está sentado ante la IA, con el contexto abierto. Una idea sobre PM016 me cruza la mente un domingo por la noche, cuando no tengo ninganas ganas de abrir una sesión completa. ¿Dónde ponerla?
En el archivo offline. Es un buzón de entrada. Deposito un mensaje — una idea, una corrección, un recordatorio — sin abrir ninguna sesión. El archivo duerme con el contexto.
Luego, al inicio de la sesión siguiente, el flujo de trabajo prevé una etapa concreta: si offline.md no está vacío, procesar su contenido como un mensaje entrante, y luego vaciar el archivo. La IA lee mi mensaje del domingo por la noche como si lo acabara de escribir, lo tiene en cuenta, actúa sobre él, y reinicia el buzón. Nada se pierde, y no tuve que abrir una sesión solo para anotar una idea.
Es una forma asíncrona de hablar a un contexto. El contexto se convierte en algo a quien puedo dejar una nota, incluso cuando no está "encendido".
Las fuentes y las notas: del contenido bruto al conocimiento reutilizable
Hasta aquí, hemos hablado del pilotaje. Ahora, el contenido.
Zoom en la cadena que va del bruto al conocimiento:
03_sources/ ← el contenido bruto
├── SRC-001.md la ficha (transcripción explotable)
└── raw/ el original tal cual (el PDF, ilegible para la IA)
04_notes/ ← el conocimiento extraído
├── atomic/ una idea = una nota (NOTE-0001, 0002…)
└── thematic/ las síntesis que relacionan varias notas
Cuando aporto contenido — para PM016, el PDF de los tres artículos — no va a volcarse en la conversación. Va a 03_sources/, el contenido bruto. Cada fuente recibe una ficha y un identificador (SRC-001, SRC-002…). El PDF original, directamente ilegible para la IA, se conserva tal cual en una subcarpeta raw/, y una ficha .md proporciona una transcripción explotable. Siempre se sabe de dónde viene cada información.
Luego viene el trabajo de extracción. A partir de las fuentes, la IA produce notas atómicas en 04_notes/atomic/. Una nota atómica captura una única unidad de pensamiento: un hecho, una definición, una hipótesis, un patrón, una contradicción. Para PM016, el análisis de los tres artículos produjo veintidós notas. Aquí hay una, real:
NOTE-0022 — Arbitrar sin volverse ciego: el cursor marco vs autonomía Patrón: dar a una responsabilidad suficiente autoridad para arbitrar crea un riesgo nuevo — la centralización ciega. […] La coherencia no es la homogeneidad. Ejemplo Nike: universos muy diferentes (running, fútbol, baloncesto…) coexisten sin uniformizarlo todo.
Esta nota es autónoma: se entiende sin reabrir el artículo. Está referenciada (apunta a SRC-001, página 67). Y está relacionada: al fondo, una sección ## Backlinks la conecta con la nota temática the-brand-man. Es Zettelkasten — unidades de pensamiento relacionadas entre sí, donde la inteligencia emerge de los vínculos, no de la acumulación.
Hay una regla que me impongo aquí, y que es más sutil de lo que parece: una nota atómica nunca es contenido preformateado para el entregable. Aunque el objetivo de la misión sea producir posts de LinkedIn, una nota no debe ser un "gancho" o una "frase impactante". La nota captura un conocimiento neutro y verdadero. El formato al servicio del objetivo se hace únicamente en los entregables. La cadena es estricta: sources (bruto) → notas (conocimiento neutro) → outputs (entregable orientado). Mientras se está en las notas, el objetivo de la misión no tiene todavía nada que decir. Si no, se envenena la propia materia prima.
Esta regla parece rígida. En realidad, es ella la que hace las notas poderosas — porque un conocimiento neutro es agnóstico del entregable, por tanto reutilizable para cualquiera de ellos.
Tomemos una misión de producto en lugar de PM016. A partir de un mismo conjunto de notas atómicas — un reto del cliente, una restricción de adopción, un patrón de mercado — puedo generar soportes muy diferentes: una presentación para un comité de dirección, documentación de soporte, un artículo de blog, una sales narrative, un onboarding. Cada entregable toma y combina los bloques que necesita de este corpus común. Si hubiera formateado estas notas para la presentación, solo servirían para la presentación. Al mantenerlas neutras, sirven a las cinco. El formato, el ángulo, el tono: todo eso llega al último momento, en 07_outputs/, una vez que se sabe qué entregable se produce.
Y la reutilizabilidad no se detiene en la misión. Los contextos no son silos estancos. Una nota producida para un contexto puede iluminar otro — porque se pueden relacionar contextos afines entre sí. Incluso puedo abrir un contexto para ir a auditar otro: recorrer sus notas y detectar las buenas ideas a retomar. Un bloque de conocimiento escrito una vez puede así alimentar un entregable hoy, otro entregable mañana, y una decisión en un tercer contexto en seis meses. Es exactamente la promesa de partida: el entregable es desechable, la nota es un activo.
Cuando varias notas convergen, se escribe una nota temática en 04_notes/thematic/ — una síntesis de un ángulo o una tensión. Para PM016, una por artículo.
Las tres memorias: episódica, semántica, y las fotos de etapa
Zoom en los tres lugares de memoria — tres escalas de tiempo:
05_memory/
├── journal/ lo que ocurrió, día a día (la historia)
└── synthesis.md lo que se retiene (la lección)
02_checkpoints/ el estado completo en un instante T (la foto de reanudación)
Es aquí donde se juega la segunda gran sutileza del sistema. Un cerebro humano no tiene una memoria, tiene varias, que funcionan a escalas de tiempo diferentes: la que retiene lo que pasa ahora, la que almacena los eventos vividos, y la que consolida los saberes duraderos. El sistema reproduce esta arquitectura con tres objetos distintos, que no hay que confundir.
El diario (memoria episódica). En 05_memory/journal/, un archivo por día de trabajo. Cuenta lo que ocurrió: lo que se hizo ese día, en qué orden, qué decisiones se tomaron, qué bloqueó. Es el relato cronológico. Se va a él cuando se pregunta "¿pero qué habíamos decidido el martes, y por qué?". Está fechado, es secuencial, nunca se reescribe.
La síntesis (memoria semántica). En 05_memory/synthesis.md, un solo archivo. No cuenta lo que ocurrió — condensa lo que se retiene. Las conclusiones estables, las convicciones validadas, los patrones extraídos de decenas de sesiones. Es la memoria a largo plazo, liberada de la cronología. Un product manager senior no redescubre en cada proyecto que los usuarios mienten en las entrevistas: se ha convertido en un saber semántico. La síntesis es eso. Forma parte del núcleo cargado en cada sesión, porque es el condensado más útil para retomar el hilo.
Los checkpoints (las fotos de etapa). En 02_checkpoints/, un archivo por día como máximo. Un checkpoint es una instantánea completa del estado del contexto en un momento dado. El ángulo de redacción es muy preciso, y es lo que hace su valor: "si un LLM llegara ahora sin haber leído nada, ¿qué debe saber para reanudar sin error y sin empezar de nuevo?" El checkpoint es la red de seguridad de la reanudación.
La distinción diario / síntesis es la que más a menudo se escapa. El diario es la historia; la síntesis es la lección. Se necesitan los dos, exactamente por la razón que me llevó, en mis primeros intentos, a separar la agregación de un log cronológico: quería a la vez saber dónde estamos (la síntesis) y poder remontar el hilo (el diario). Sobrescribir uno con el otro es perder o bien la memoria, o bien la trazabilidad.
Y es precisamente lo que hace el sistema auditable. Un cerebro olvida — es su fuerza. Un sistema de archivos, en cambio, no olvida nada. De la síntesis, se sube al checkpoint. Del checkpoint, a los diarios. De los diarios, a las notas. De las notas, a las fuentes brutas. Cuando alguien pregunta "¿por qué esta decisión?", la respuesta nunca es "porque lo dijo la IA". Es una cadena de pruebas: fuente → nota → decisión.
El ciclo de una sesión, de principio a fin
Ahora que tenemos los bloques, aquí está la película completa de una sesión sobre PM016.
Al inicio. La IA lee el manifiesto, carga el núcleo, lee el último checkpoint. Verifica el archivo offline: si contiene una nota que dejé entre dos sesiones, la procesa y luego la vacía. En pocos segundos, sabe dónde estamos. La ficha de reanudación (resume_work.md) le da incluso la primera acción a hacer.
Durante la sesión. Hablamos — a menudo en voz alta, ante la pantalla. Y a lo largo de la conversación, la IA organiza en continuo. Llega una nueva fuente → 03_sources/. Emerge una idea duradera → una nota atómica en 04_notes/. Se toma una decisión → decisions.md. Aparece una contradicción → contradictions.md (no se alisa artificialmente, se deja visible). Una acción futura → la lista de tareas. Cada vez que se crea un archivo, el README.md de su carpeta y el índice máquina se actualizan. El contexto se mantiene constantemente al día, sin esfuerzo de mi parte.
Al final de la sesión. Escribo /context_close. La IA dispara el ritual de cierre: escribe el diario del día, actualiza el estado actual y la ficha de reanudación, promueve hacia la síntesis lo que merece volverse duradero, y crea un checkpoint si se alcanza un umbral. Luego hace el commit de todo. La próxima sesión podrá reanudar exactamente donde esta se detuvo.
Existe también una compactación en el camino (/context_push): cuando el estado actual se infla, cuando la lista de tareas se vuelve ilegible, o cuando se da vueltas en círculos, se condensa, se deduplica, se prioriza, se archiva lo que ya no sirve — sin perder nunca la trazabilidad.
Pero el /context_push tiene un papel más vital todavía, y es una trampa en la que se cae inevitablemente al descubrir el sistema. Cuando una sesión dura mucho tiempo, la conversación acaba por superar la ventana del LLM. En ese momento, el LLM hace su propia compactación: resume silenciosamente los intercambios antiguos para hacer sitio. Y todo lo que no había sido todavía escrito en disco en ese instante — una decisión evocada oralmente, una idea lanzada de pasada, un matiz importante — se aplana, deforma, o simplemente se pierde. El LLM no avisa; cree haber guardado lo esencial, pero es él quien ha elegido qué era esencial.
El /context_push es la contramedida: fuerza la persistencia en disco antes de que el LLM compacte su memoria de trabajo. Empujando regularmente, se garantiza que todo lo que importa ya está escrito en los archivos — en el sitio correcto, referenciado, trazado — de modo que la compactación del LLM ya no hace perder nada importante. Es el principio fundador del artículo, aplicado a lo largo de la sesión: lo que vive únicamente en la conversación está en suspense; solo lo que está en disco está realmente memorizado.
El olvido sin la pérdida
Un último punto, porque dice mucho de la filosofía del sistema. No hay supresión brutal.
Cuando una información ya no es útil, no se borra. Se saca de la carga por defecto, se compacta, o se archiva. Cuando una idea reemplaza a otra, no se sobreescribe: se marca superseded, se conserva el antiguo identificador, y se hace apuntar el antiguo hacia el nuevo. Solo se suprime realmente en caso de error manifiesto o de duplicado no ambiguo.
¿Por qué tanta precaución? Porque la auditabilidad es todo el valor del sistema. El día en que una convicción de producto deba defenderse, debo poder remontar hasta su fuente, aunque date de dos meses y haya sido "superseded" desde entonces. Un razonamiento cuya historia se ha borrado ya no es un razonamiento — es una opinión sin prueba.
Lo que el contexto es realmente
En el fondo, este motor de contexto no es un sistema de organización. Es una arquitectura de memoria para una inteligencia que no la tiene de forma nativa.
Cada bloque responde a un límite del LLM: el manifiesto responde a la ventana finita; las tres memorias responden al olvido entre sesiones; las notas atómicas responden al Lost in the Middle; la separación fuentes/notas/entregables responde a la necesidad de trazabilidad; el archivo offline responde al hecho de que el pensamiento no se detiene cuando se cierra la sesión.
Y el resultado es lo que describía en mis artículos anteriores: el entregable ya no es el punto de partida del trabajo, es un subproducto. Lo que tiene valor es el contexto en sí mismo — esa memoria estructurada, trazable, reutilizable, que se enriquece sesión a sesión y acaba produciendo mucho más de lo que se le pide.
Para PM016, el objetivo eran veintisiete posts de LinkedIn. Pero lo que queda, una vez publicados los posts, es un contexto: veintidós ideas atómicas relacionadas, tres síntesis temáticas, fuentes trazadas. Un contenido que podré reabrir en seis meses para un entregable completamente diferente. El post era el objetivo. El contexto es el activo.
Para saber más
Del archivo único al sistema de contextos: por qué la memoria de un LLM no cabe en un solo documento El PM como arquitecto del Contexto Un archivo, unas directrices, y Claude hace el resto — cómo estructuré 500 correos sin esfuerzo ¿Qué es una nota atómica? ¿Qué es una nota temática?