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 porqué.

Este habla del cómo. Voy a levantar 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 foco, las directrices, la lista de tareas, la cola offline y los tres tipos de memoria.

El objetivo: que alguien que nunca ha 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 me he encontrado trabajando con una IA en temas que duran semanas.

El principio de partida: el disco es la memoria

Una cosa que conviene fijar antes que nada. 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. Cierras la pestaña y todo se pierde. La ventana de contexto es finita y, cuanto más la llenas, más se degrada la atención — es el fenómeno del Lost in the Middle del que he hablado en otro sitio. Así que, en lugar de guardarlo todo en la conversación, se escribe todo en disco, en archivos separados por naturaleza de la información. Y en cada sesión solo se recarga lo estrictamente necesario.

Un contexto es, por tanto, una carpeta. Una carpeta = una misión. No hay ninguna memoria transversal implícita entre dos contextos: lo que la IA sabe del proyecto A no se filtra hacia el proyecto B. Cada misión tiene su propia cabeza.

Así es, en versión simplificada, un contexto:

<contexto>/
├── 00_mission/     ← el marco estable: por qué estamos aquí, las reglas
├── 01_active/      ← el estado vivo: en qué punto estamos, hoy
├── 02_checkpoints/ ← las fotos de etapa
├── 03_sources/     ← la materia bruta
├── 04_notes/       ← las ideas extraídas, enlazadas 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 ordenació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), que a su vez está separado de la materia bruta (las fuentes), de lo que se extrae de ella (las notas) y de lo que se produce (los entregables). Nada se mezcla. Veremos que esta separación no es cosmética: es la que hace que el razonamiento sea trazable en el tiempo.

Para que todo esto resulte concreto, voy a seguir una misión que llevé a cabo de verdad (un ejemplo sencillo, 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

Arranco 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). Ese archivo le dice qué cargar y, al contrario, qué debe dejar en disco.

Contiene tres listas:

• always_load — el núcleo, que se carga siempre. La misión, el alcance, las directrices, los riesgos, el estado actual, el plan, el foco, la lista de tareas, las decisiones, las contradicciones, la ficha de reanudación, la síntesis.
• load_on_demand — todo lo que se 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.
• Unos límites de seguridad: no más de 12 archivos activos, unas 1200 líneas como máximo en la ventana de contexto del LLM.

Es una mesa de instrumental quirúrgico. Los instrumentos esenciales ya están fuera; los demás quedan al alcance de la mano, pero no cubren la mesa. Un experto humano no se relee todo el expediente antes de cada reunión — tiene 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 adecuado, no todo.

En la práctica, abrir un contexto se hace con un comando —tecleo /context_use pm016— y la IA ejecuta el manifiesto: lee el núcleo, lee el último checkpoint y ya está operativa. Sabe en qué punto estamos sin que yo haya tenido que volver a explicarle nada.

La misión y el foco: el objetivo no es lo mismo que la atención

Primer plano de las dos carpetas de cabecera — 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 que 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 en qué punto estamos
├── current_plan.md  hacia dónde vamos
├── todo.md          las acciones futuras
├── decisions.md     lo que hemos zanjado
├── contradictions.md lo que todavía no encaja
├── resume_work.md   la ficha de reanudación
└── offline.md       la bandeja de entrada

Aquí llega la primera sutileza, y probablemente la más importante de entender.

Hay dos archivos que parecen "aquello en lo que estamos trabajando", 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". Esa frase no cambia en toda la vida del contexto. Es el rumbo. El archivo vive en 00_mission/, la carpeta de las cosas estables.

El segundo es el foco (01_active/focus.md). Es la atención del momento. Cambia en cada sesión, a veces varias veces dentro de una misma sesión. El foco es "hoy trabajamos en repartir las ideas del artículo 2 en posts distintos". No es el objetivo: es el subproblema sobre el que dirigimos 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 acabar a la deriva. Si la IA toma el foco 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 a la vista, se queda demasiado vaga: "escribe posts de LinkedIn" no dice sobre qué nos concentramos en este instante. La misión da la dirección, el foco da la profundidad de campo. Se puede rehacer el foco diez veces sin tocar nunca la misión. Es exactamente como en un humano: tu puesto (tu misión) no cambia porque pases la tarde en una tarea concreta (tu foco).

Alrededor de la misión, en 00_mission/, hay otros tres archivos que enmarcan el trabajo.

El alcance delimita lo que entra en el perímetro y lo que no — la barrera contra la deriva del tema.

Los riesgos (risks.md) son el cuadro de amenazas que pesan sobre la misión. En PM016 es modesto; pero en una oportunidad de producto de verdad, este archivo sigue los cuatro grandes riesgos de Marty Cagan — valor, usabilidad, factibilidad y viabilidad de negocio. La idea: mantener permanentemente a la vista las preguntas que pueden hacer fracasar el proyecto, e ir marcando cada riesgo a medida que algún elemento lo aclara o lo agrava. Una sección vacía = un riesgo todavía sin documentar, es decir, un punto ciego asumido.

El glosario (glossary.md) fija el vocabulario de la misión, para que las mismas palabras conserven el mismo sentido de principio a fin. Es el mismo reflejo que en mi contexto de la comunidad de propietarios, donde acabé sacando todos los términos técnicos y las siglas a un archivo dedicado: sin eso, cada cual —el humano igual que la IA— acaba usando las mismas palabras con sentidos distintos.

Un punto importante sobre todos estos archivos, y quizá lo más contraintuitivo del sistema: no se rellenan de golpe al arrancar. Se van llenando poco a poco, a lo largo de los intercambios. Y "intercambio" no significa solo "aportar un documento". La mayoría de las veces significa hablar. Converso con la IA, pienso en voz alta, le doy un contexto que tengo en la cabeza — y es ella la que coloca ese flujo en el sitio adecuado: este punto es un riesgo de viabilidad, este término merece una entrada de glosario, esta frase delimita el alcance. Un riesgo no escrito se convierte en una línea de risks.md porque lo he mencionado hablando, no porque haya abierto el archivo para rellenarlo. Ahí es donde el contexto deja de ser una carpeta que ordenar 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 sacado de otro de mis contextos, donde le hago procesar cientos de correos de la comunidad de propietarios: "cuando dos personas comparten el mismo apellido, usa el contenido 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 tratamiento. Codifica un conocimiento que solo yo tengo, y que la IA aplica después de forma sistemática — sin olvidarse, 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 pongo una vez y que vale para los veintisiete posts.

Las directrices están en el núcleo always_load: se recargan, por tanto, en cada sesión. Una regla que establecimos en la semana 1 se sigue aplicando en la semana 6, sin que yo tenga que repetirla. Es acumulativo. Cuanto más avanza una misión, más se afinan sus directrices y más trabaja la IA como yo.

Detalle de uso: para añadir una directriz en plena conversación, basta con que prefije mi mensaje con alpha directive : ... y la IA la consolida en el archivo. Hay un puñado de palabras clave como esa (decision :, contradiction :, todo :, checkpoint, fin de session) — atajos para colocar una información en el archivo correcto sin tener que decirlo explícitamente. No son más que 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

El archivo todo.md (01_active/todo.md) es un archivo sencillo que, sin embargo, resuelve un problema real.

Cuando trabajas en un tema, surgen ideas de acciones futuras todo el rato. "Habrá que comprobar esa cifra." "Deberíamos convertir este post en un carrusel." "Acordarse de releer la versión inglesa." Si dejas que esas acciones floten en la conversación, pasan dos cosas: o se olvidan, o contaminan el razonamiento en curso tirando de la atención en todas direcciones.

La lista de tareas es el sitio donde dejas esas acciones para no tener que seguir sosteniéndolas en la cabeza. Es un backlog. Cada tarea tiene un identificador (T-NNN) y un estado. Se alimenta escribiendo todo : .... Y como 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 dejarla en un lugar estable y con nombre.

La cola offline: hablarle al contexto cuando duerme

Aquí hay un bloque en el que no piensas al principio y que pronto se vuelve indispensable: el archivo offline (01_active/offline.md).

El problema: las ideas no llegan solo cuando estás sentado delante de la IA, con el contexto abierto. Una idea sobre PM016 me cruza la cabeza un domingo por la noche, cuando no tengo ninguna gana de abrir una sesión completa. ¿Dónde la meto?

En el archivo offline. Es una bandeja de entrada. Dejo ahí un mensaje —una idea, una corrección, un recordatorio— sin abrir ninguna sesión. El archivo duerme con el contexto.

Luego, al arrancar la sesión siguiente, el flujo de trabajo prevé un paso preciso: si offline.md no está vacío, tratar su contenido como un mensaje entrante y después vaciar el archivo. La IA lee mi mensaje del domingo por la noche como si acabara de teclearlo, lo tiene en cuenta, actúa en consecuencia y deja la bandeja a cero. No se pierde nada, y no he tenido que abrir una sesión solo para apuntar una idea.

Es una manera asíncrona de hablarle a un contexto. El contexto se convierte en algo a lo que puedo dejarle una nota, incluso cuando no está "encendido".

Las fuentes y las notas: de la materia bruta al conocimiento reutilizable

Hasta aquí hemos hablado del pilotaje. Ahora, el contenido.

Primer plano de la cadena que va de lo bruto al conocimiento:

03_sources/          ← la materia bruta
├── 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 enlazan varias notas

Cuando aporto materia —para PM016, el PDF de los tres artículos— no se vierte en la conversación. Va a 03_sources/, la materia bruta. Cada fuente recibe una ficha y un identificador (SRC-001, SRC-002…). El PDF original, que la IA no puede leer directamente, se conserva tal cual en una subcarpeta raw/, y una ficha .md ofrece una transcripción explotable. Siempre sabemos de dónde viene cada información.

Después 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 sola 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í va una, real:

NOTE-0022 — Arbitrar sin quedarse ciego: el cursor entre marco y 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 distintos (running, fútbol, baloncesto…) conviven sin uniformarlo todo.

Esta nota es autónoma: se entiende sin volver a abrir el artículo. Está referenciada (apunta a SRC-001, página 67). Y está enlazada: al pie, una sección ## Backlinks la conecta con la nota temática the-brand-man. Es Zettelkasten — unidades de pensamiento enlazadas entre sí, donde la inteligencia emerge de los enlaces, 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 materia preformateada para el entregable. Aunque el objetivo de la misión sea producir posts de LinkedIn, una nota no debe ser un "gancho" ni una "frase lapidaria". La nota captura un conocimiento neutro y verdadero. La puesta en forma al servicio del objetivo se hace únicamente en los entregables. La cadena es estricta: sources (bruto) → notes (conocimiento neutro) → outputs (entregable orientado). Mientras estamos en las notas, el objetivo de la misión todavía no tiene voz. Si no, envenenas tu propia materia prima.

Esta regla parece rígida. En realidad, es la que hace que las notas sean potentes — porque un conocimiento neutro es agnóstico del entregable y, 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 distintos: un pitch para un comité de dirección, una documentación de soporte, un artículo de blog, una sales narrative, un onboarding. Cada entregable coge y combina los bloques que necesita de ese corpus común. Si hubiera formateado esas notas para el pitch, solo servirían para el pitch. Manteniéndolas neutras, sirven para los cinco. La puesta en forma, el ángulo, el tono: todo eso llega en el último momento, en 07_outputs/, una vez que sabemos qué entregable producimos.

Y la reutilización 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 enlazar entre sí contextos conexos. Incluso puedo abrir un contexto para ir a auditar otro: recorrer sus notas y detectar las buenas ideas que merece la pena recuperar. 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 dentro de 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 de una tensión. Para PM016, una por artículo.

Las tres memorias: episódica, semántica y las fotos de etapa

Primer plano de 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 de ello (la lección)

02_checkpoints/      el estado completo en un instante T (la foto de reanudación)

Aquí se juega la segunda gran sutileza del sistema. Un cerebro humano no tiene una memoria, tiene varias, que funcionan a escalas de tiempo distintas: la que retiene lo que pasa ahora, la que almacena los acontecimientos vividos y la que consolida los saberes duraderos. El sistema reproduce esa arquitectura con tres objetos distintos que, sobre todo, 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, dónde nos atascamos. Es el relato cronológico. Vas ahí cuando te preguntas "pero ¿qué habíamos decidido el martes, y por qué?". Está fechado, es secuencial y nunca se reescribe.

La síntesis (memoria semántica). En 05_memory/synthesis.md, un único archivo. No cuenta lo que ocurrió — condensa lo que se retiene de ello. Las conclusiones estables, las convicciones validadas, los patrones extraídos de decenas de sesiones. Es la memoria a largo plazo, despojada de la cronología. Un product manager sénior no redescubre en cada proyecto que los usuarios mienten en las entrevistas: eso 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 ahí reside su valor: "si un LLM llegara ahora mismo sin haber leído nada, ¿qué debe saber para retomar sin errores y sin empezar de cero?". 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. Necesitamos las dos, exactamente por la razón que me había empujado, en mis primerísimos intentos, a separar la agregación de un registro cronológico: quería a la vez saber en qué punto 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 eso lo que hace que el sistema sea auditable. Un cerebro olvida — esa es su fuerza. Un sistema de archivos, en cambio, no olvida nada. De la síntesis se remonta 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í va la película completa de una sesión de PM016.

Al arrancar. La IA lee el manifiesto, carga el núcleo, lee el último checkpoint. Comprueba el archivo offline: si contiene una nota que dejé entre dos sesiones, la procesa y después lo vacía. En unos segundos sabe en qué punto estamos. La ficha de reanudación (resume_work.md) le da incluso la primera acción que hacer.

Durante la sesión. Conversamos — a menudo en voz alta, delante de la pantalla. Y a lo largo de la conversación, la IA va ordenando sin parar. Llega una fuente nueva → 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 la limamos artificialmente, la mantenemos visible). Una acción futura → la lista de tareas. Cada vez que se crea un archivo, se actualizan el README.md de su carpeta y el índice máquina. El contexto se mantiene constantemente al día, sin esfuerzo por mi parte.

Al final de la sesión. Tecleo /context_close. La IA lanza el ritual de cierre: escribe el diario del día, actualiza el estado actual y la ficha de reanudación, promueve a la síntesis lo que merece volverse duradero y crea un checkpoint si se alcanza un umbral. Después hace un commit de todo. La sesión siguiente podrá retomar exactamente donde esta se detuvo.

Existe también una compactación sobre la marcha (/context_push): cuando el estado actual engorda, cuando la lista de tareas se vuelve ilegible o cuando damos vueltas en círculo, se condensa, se deduplica, se prioriza y se archiva lo que ya no sirve — sin perder nunca la trazabilidad.

Pero /context_push tiene un papel aún más vital, y es una trampa en la que uno cae sin remedio al descubrir el sistema. Cuando una sesión dura mucho, la conversación acaba desbordando la ventana del LLM. En ese momento, el LLM hace su propia compactación: resume en silencio los intercambios antiguos para hacer sitio. Y todo lo que en ese instante todavía no se había escrito en disco —una decisión comentada de viva voz, una idea lanzada de pasada, un matiz importante— queda recortado, deformado o simplemente perdido. El LLM no te avisa; cree haber conservado lo esencial, pero es él quien ha elegido qué era lo esencial.

/context_push es la defensa: fuerza la persistencia en disco antes de que el LLM compacte su memoria de trabajo. Empujando con regularidad, garantizamos que todo lo que cuenta ya está escrito en los archivos —en el sitio adecuado, con su fuente, trazado—, de modo que la compactación del LLM ya no hace perder nada importante. Es el principio fundacional del artículo, aplicado a lo largo de la sesión: lo que vive únicamente en la conversación tiene los días contados; solo lo que está en disco está memorizado de verdad.

El olvido sin la pérdida

Un último punto, porque dice mucho de la filosofía del sistema. No existe la eliminación brutal.

Cuando una información deja de ser útil, no se borra. Se saca de la carga por defecto, se compacta o se archiva. Cuando una idea sustituye a otra, no se sobrescribe: se marca como superseded, se conserva el identificador antiguo y se hace que el antiguo apunte al nuevo. Solo se elimina de verdad en caso de error manifiesto o de duplicado inequívoco.

¿Por qué tantas precauciones? Porque la auditabilidad es todo el valor del sistema. El día en que haya que defender una convicción de producto, tengo que poder remontar hasta su fuente, aunque date de hace dos meses y desde entonces haya quedado "superseded". Un razonamiento al que se le ha borrado el historial ya no es un razonamiento — es una opinión sin pruebas.

Lo que el contexto es de verdad

En el fondo, este motor de contexto no es un sistema de ordenació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 mismo — esa memoria estructurada, trazable, reutilizable, que se enriquece sesión tras sesión y que 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 enlazadas, tres síntesis temáticas, fuentes trazadas. Una materia que podré reabrir dentro de seis meses para un entregable completamente distinto. El post era el objetivo. El contexto es el activo.