Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
La necesidad
Trabajar con un LLM sobre un tema complejo —una oportunidad de producto, un seguimiento estratégico, un proceso de discovery— supera rápidamente la simple conversación. Acumulas fuentes, decisiones, hipótesis, contradicciones. Vuelves al día siguiente y el LLM lo ha olvidado todo. Copias y pegas un archivo context.md cada vez más grande, y en un momento dado, ya no funciona.
El problema no es que al LLM le falte inteligencia. Es que le falta memoria estructurada.
Cómo llegué hasta aquí
Empecé como todo el mundo. En ChatGPT, conversando. El problema apareció pronto: en cada intercambio, la IA regeneraba el documento entero. O solo una parte, pero sin acceso a lo anterior. Le decía "muéstrame lo que hicimos antes", lo regeneraba todo, perdíamos un tiempo enorme y el contenido acababa por divergir.
El siguiente paso fue pasarme a Claude Code —una herramienta que permite conversar con un LLM mientras este escribe directamente en un archivo Markdown. De vez en cuando le pedía que reestructurara, podía releer con facilidad o incluso modificar yo mismo el texto. Era mejor. Pero un archivo largo seguía sin ser suficiente.
Y sobre todo, apareció un problema de fondo: el archivo está organizado o para el humano o para la IA —nunca para ambos. La IA necesita referencias para retomar una sesión donde la dejó, memorizar decisiones, recuperar fuentes. El humano necesita agregar información, validarla, dividirla por tema o por riesgo. No la misma estructura, no las mismas necesidades.
Así que tuve dos archivos. Uno para la IA, otro para el humano. Aguantó un tiempo. Pero los dos acabaron por inflarse, y había de todo en cada uno —fuentes, decisiones, hipótesis, directrices, mezcladas en el mismo flujo.
Empecé a separar. Un archivo de directrices aparte, que no hablaba de una feature sino de cómo debe trabajar la IA. Luego un archivo de definiciones. Luego otros. Y en un momento, el clic: ya no había que pensar en archivos, sino en un sistema de organización. Y puesto que los LLM están inspirados en el cerebro humano, quizás su memoria debería estarlo también.
Aquí tienes, en versión simplificada, cómo luce un contexto estructurado:
<contexte>/
├── 00_mission/
│ ├── mission.md ← por qué estamos aquí
│ ├── directives.md ← cómo debe trabajar la IA
│ └── load_manifest.json ← qué cargar, en qué orden
├── 01_active/
│ ├── active.md ← estado actual + plan
│ └── decisions.md ← decisiones tomadas y por qué
├── 02_checkpoints/ ← fotos de etapa del contexto
├── 03_sources/
│ └── source_catalog.md ← índice de fuentes brutas
├── 04_notes/ ← notas atómicas, interconectadas
├── 05_memory/
│ ├── journal/ ← lo que ocurrió (memoria episódica)
│ └── synthesis.md ← lo que se retiene a largo plazo
└── 07_outputs/ ← livrables producidos
Cada carpeta tiene un rol preciso. Nada está mezclado. Y sobre todo, no se carga todo en cada sesión —se carga el núcleo (00_mission + 01_active), y el resto a demanda.
Lo que importa de verdad es el contexto
Pero antes de explicar por qué esta estructura funciona, hay que plantear una verdad más amplia.
Lo que hace que alguien destaque en un ámbito raramente es la técnica. Es la profundidad del contexto que ha interiorizado.
Un buen comercial no vende mejor porque domine un guion. Vende mejor porque comprende los retos de su cliente —sus restricciones, sus miedos, su vocabulario, lo que no dice. Un buen product manager no hace un mejor producto porque conozca los frameworks. Lo hace porque ha comprendido el contexto del usuario —sus hábitos, sus fricciones, lo que sortea a falta de algo mejor. Un sociólogo no comprende un movimiento social leyendo estadísticas. Lo comprende captando el contexto vivido de un grupo —sus códigos, sus tensiones internas, su relación con el mundo.
El contexto es lo que transforma información en comprensión. Lo demás —la decisión, la acción, la producción— se deriva casi mecánicamente.
Y eso es exactamente lo que falta cuando trabajas con un LLM sobre un tema prolongado.
No se puede meter todo en un solo archivo
El cerebro humano no funciona cargando todo lo que sabe en cada instante. Descompone. Organiza. Separa lo que es estable de lo que está en curso. Distingue una fuente bruta de una convicción personal. Olvida los detalles para quedarse con los patrones.
Un LLM es igual —pero peor. Su ventana de contexto es finita. Y cuanto más se llena, más se degrada su atención sobre lo que queda enterrado en el medio. No es una intuición: investigadores de Stanford lo demostraron en Lost in the Middle (Liu et al., 2024). Su conclusión: un LLM recupera mucho mejor una información situada al principio o al final de su contexto que una enterrada en el medio. Cargar un archivo de 3000 líneas esperando que "lo entienda todo" es como leerle un libro entero en voz alta a alguien pidiéndole que recuerde cada frase.
Lo que hace falta es cargar solo lo que importa para la tarea en curso. Y para eso, hay que haber dividido el conocimiento en piezas navegables.
Cargar lo mínimo, con el máximo impacto
Si el problema está claro —no se puede cargar todo— la pregunta pasa a ser: ¿qué cargar, y cómo?
La solución es tener un núcleo compacto que se carga sistemáticamente: la misión (por qué estamos aquí), el estado actual (dónde estamos), el plan (hacia dónde vamos), las decisiones tomadas, las contradicciones abiertas y una ficha de reanudación. Este núcleo cabe en unos pocos archivos cortos. Da al LLM todo lo que necesita para ser operativo de inmediato, sin ruido.
Luego, según la necesidad de la sesión, se carga a demanda: una fuente concreta que se quiere analizar, una nota que se quiere enriquecer, un checkpoint antiguo que se quiere comparar. El resto —las decenas de fuentes, las notas atómicas, los diarios de sesión— permanece en disco, accesible pero fuera de la ventana de contexto.
Para que esto funcione, hace falta un mecanismo que le diga a la IA qué cargar, en qué orden y con qué prioridad. Ese es el rol de un manifiesto de carga —una especie de lista de reproducción del contexto. Primero: la misión y el estado actual (el núcleo, siempre). Luego: los archivos recomendados según la fase en curso. Por último: los archivos disponibles pero cargados solo si la sesión lo requiere. Es como el instrumental de un cirujano: los instrumentos esenciales ya están en la mesa, los demás están al alcance, pero no se pone todo sobre la mesa.
Es exactamente lo que hace un experto humano. No relee todo su expediente antes de cada reunión. Ha interiorizado lo esencial, y busca un documento concreto cuando lo necesita. La diferencia es que un LLM no puede interiorizar —solo tiene lo que le damos. De ahí la importancia de darle el subconjunto correcto, no todo.
Separar las fuentes de lo que producimos
Un error frecuente: mezclar todo. La transcripción de una entrevista, la hipótesis que se extrae de ella, la decisión que se toma, el livrable que se genera —todo en el mismo archivo, en el mismo flujo.
El problema es la trazabilidad. Cuando todo está mezclado, ya no se sabe de dónde viene cada cosa. Ya no se sabe si una afirmación es un hecho contrastado o una interpretación. Ya no se sabe si una decisión sigue siendo válida o ha sido reemplazada.
Separar las fuentes (la materia bruta) de la memoria (lo que se retiene) y de los outputs (lo que se entrega) no es burocracia. Es lo que permite mantener un razonamiento fiable a lo largo del tiempo.
Un contexto bien estructurado produce más de lo que se le pide
Un problema clásico en product management: se escriben muchos documentos, pero nunca se encuentra lo que se busca. Las notas de discovery duermen en un Google Doc. El brief de producto está en Notion. El acta de la reunión estratégica está en algún sitio de Slack. La información existe, pero está dispersa, sin conexión, inutilizable.
Cuando se estructura un contexto alrededor de un tema —separando fuentes, notas, decisiones, memoria— ocurre algo poderoso. Ese contexto se convierte en una base reutilizable. A partir del mismo núcleo de conocimiento, se pueden generar livrables muy distintos: un brief de release, user stories, un pack de comunicación (resumen, newsletter, post de LinkedIn), una presentación para el comité directivo.
No se reescribe todo cada vez. Se combinan los bloques correctos del contexto para responder a una necesidad concreta. El LLM no inventa nada —ensambla lo que ya está ahí, con la granularidad y el ángulo adecuados. Es la diferencia entre dictar un documento desde cero y pedirle a un asistente que ya conoce todo el expediente que lo adapte a un nuevo formato.
Aquí es donde la estructuración pasa de "buena práctica" a ventaja real: un contexto bien organizado no es solo legible, es productivo.
El fin del secuencial
El product management clásico funciona por fases: primero la discovery, luego se redactan las specs, luego se entrega, luego se comunica. Cada etapa espera a la anterior. Queda limpio en un diagrama, pero es lento —y no refleja la realidad del terreno.
Con un sistema de contextos y un LLM, esta secuenciación desaparece. La discovery nunca se detiene del todo. Se dialoga continuamente con la IA para afinar, cuestionar, reformular. El contexto madura permanentemente, y los livrables mejoran a medida que madura —no al final de una fase, sino durante. Puedes sacar un primer brief ya en la segunda sesión, hacerlo evolucionar conforme el contexto se enriquece, y el livrable final no es más que la última iteración de un documento que ha crecido con la reflexión.
Pero el efecto más interesante está en otro sitio. Cuando se trabaja así, se abren muchos contextos. Oportunidades de producto, exploraciones, seguimientos. Algunos nunca llegarán a convertirse en una funcionalidad. No "sirven para nada" en el sentido clásico del término. Salvo que estos contextos no están aislados. Están conectados. Una exploración sobre los hábitos de mantenimiento industrial alimenta una reflexión sobre la gestión de activos. Un seguimiento sobre los modelos de pricing SaaS ilumina una oportunidad sobre la monetización de un módulo. Tres contextos que parecían independientes convergen un día hacia un cuarto, que no habría sido tan rico sin ellos.
Es un cambio de postura. Ya no se trabaja en modo "una idea → un livrable". Se cultiva una red de contextos que se fertilizan mutuamente. Y el día en que hay que tomar una decisión de producto, el terreno ya está preparado.
Ideas precisas, interconectadas
Esta red de contextos funciona a gran escala. Pero dentro de cada contexto, el mismo principio se aplica a la escala de las ideas.
Lo que hace la inteligencia —humana o artificial— no es acumular conocimiento. Es conectar ideas precisas entre sí. Y sobre todo, ideas lejanas.
Un ejemplo. En el ámbito de la optimización de horarios —asignar salas, recursos, franjas bajo múltiples restricciones— uno de los enfoques más eficaces se llama recocido simulado. En 1983, Kirkpatrick, Gelatt y Vecchi publicaron en Science un artículo fundacional: demostraron que un proceso de metalurgia —calentar un metal y enfriarlo lentamente para que sus átomos encuentren una configuración estable— puede trasponerse en un algoritmo de optimización combinatoria. No hay relación evidente entre una fundición y un horario de salas —y sin embargo, esa transferencia cambió todo un campo de investigación. La conexión existe, a condición de haberla captado.
Es exactamente la promesa del Zettelkasten —ese sistema de notas atómicas inventado por el sociólogo alemán Niklas Luhmann, quien describía su caja de fichas como un «compañero de comunicación» (Luhmann, 1981). Cada idea está aislada, es precisa y está conectada explícitamente con otras. No se almacenan bloques de texto. Se almacenan unidades de pensamiento, cada una con sus enlaces. Y es en esos enlaces donde emerge la inteligencia: cuando una nota sobre un fenómeno físico cruza una nota sobre un problema de planificación, cuando una observación de campo se une a una hipótesis teórica leída seis meses antes.
Aplicado a un sistema de contextos para LLM, esto significa: no escribir largas síntesis monolíticas, sino notas cortas, bien tituladas, bien interconectadas. Cada nota es un punto. La red de enlaces entre esos puntos es el mapa. Y es ese mapa el que permite —a un humano como a un LLM— hacer conexiones que un archivo plano nunca permitiría.
Es también la intuición detrás de A-MEM (Xu et al., 2025) —un sistema de memoria para agentes LLM directamente inspirado en el Zettelkasten. Notas estructuradas, indexadas dinámicamente, interconectadas. Una arquitectura que da a la IA los medios para navegar por su propia memoria en lugar de cargarlo todo de golpe.
Memoria a corto plazo, memoria a largo plazo, y el derecho a remontar el hilo
Un cerebro humano no tiene una sola memoria. Tiene varias, que funcionan a diferentes escalas de tiempo. Esto es lo que Atkinson y Shiffrin formalizaron ya en 1968 con su modelo multi-almacén: un registro sensorial, una memoria a corto plazo, una memoria a largo plazo. Endel Tulving refinó después la distinción en 1972 separando memoria episódica y semántica. En concreto: la memoria de trabajo retiene lo que ocurre ahora —una conversación, un cálculo en curso. La memoria episódica almacena los eventos vividos —lo que hiciste el martes, lo que dijo el cliente en la reunión. Y la memoria a largo plazo consolida las verdades duraderas —los reflejos, las convicciones, los patrones interiorizados a fuerza de experiencia. Un conductor experimentado ya no piensa en cómo cambiar de marcha. Un product manager senior no redescubre en cada proyecto que los usuarios mienten en las entrevistas. Esos saberes se han convertido en automatismos.
Un sistema de contextos para LLM reproduce esta arquitectura. El diario de sesión es la memoria episódica: lo que ocurrió, cuándo, en qué orden. La síntesis consolidada es la memoria a largo plazo: las conclusiones estables, las decisiones validadas, los patrones extraídos de decenas de sesiones. Y los checkpoints son las fotos de etapa —el estado completo del contexto en un momento dado.
Pero hay una diferencia fundamental con el cerebro humano. Un cerebro olvida —es incluso su fortaleza, le evita saturarse. Un sistema de archivos, en cambio, no olvida nada. Y ahí es donde entra la auditabilidad. En un sistema bien estructurado, cada información refinada —una convicción de producto, una decisión estratégica, una hipótesis validada— puede rastrearse. De la síntesis, se remonta al checkpoint que la produjo. Del checkpoint, se remonta a las sesiones. De las sesiones, se remonta a las fuentes brutas —la entrevista, el artículo, el dato.
Es el mismo principio que en ciencia: una conclusión solo tiene valor si se puede remontar al método y a los datos que la produjeron. Cuando un stakeholder pregunta "¿por qué esta decisión?", la respuesta no es "porque lo dijo la IA". Es "aquí está el camino: fuente → análisis → síntesis → decisión". Todo es rastreable, todo es verificable. La memoria no es una caja negra —es una cadena de pruebas.
Lo que cambia en concreto
Antes, mi trabajo como product manager consistía en buena parte en producir documentos. Mucha documentación. Algunas piezas requerían experiencia —encuadre estratégico, arbitrajes de arquitectura, priorización. Pero muchas otras eran producción de contenido a partir de información ya existente: documentación de soporte, artículos de blog, newsletters, notas de release, comunicación interna. Trabajo necesario, pero ampliamente automatizable cuando se dispone de un contexto sólido.
Hoy, eso está en vías de automatización. No porque la IA sea "mágica", sino porque un contexto fuerte, coherente y completo permite generar esos livrables de forma casi autónoma. La documentación de soporte se deduce de las decisiones y las specs. La newsletter se construye a partir de las notas de release y el contexto de producto. Algunos livrables están automatizados casi al 100 %. Otros —las user stories, por ejemplo— todavía requieren revisión humana, pero el primer borrador ya es sólido.
El cambio más profundo no está en la producción. Está en la materia prima. Antes, se escribían documentos para hacer productos. Se redactaban livrables para poder entregar software. Era el livrable lo que importaba —el documento final, fijo, validado.
Hoy, se escriben contextos. Se conversa con la IA —a menudo en voz alta, frente a la pantalla— para crear, enriquecer, afinar el contexto. El livrable ya no es el punto de partida del trabajo, es un subproducto. Lo que tiene valor es el contexto en sí mismo —y como hemos visto, la red de contextos conexos que se fertilizan entre sí.
Hacia dónde lleva esto
Lo que se perfila es un cambio de postura del product manager. Se pasa de alguien que hace muchas cosas solo —discovery, specs, comunicación, coordinación— a alguien que gestiona un equipo de IA. Se conversa, se explica el contexto, se cuestionan los resultados, se arbitra. El día a día se parece menos a la redacción y más al management.
Y es un ejercicio exigente. Explicar un contexto a una IA que no sabe nada del tema obliga a verificar que uno mismo lo comprende. Reexplicar, reformular, precisar —es un espejo implacable. Si el contexto está difuso en tu cabeza, el resultado estará difuso. La IA no compensa la aproximación, la amplifica.
Naval Ravikant habla de specific knowledge —ese saber que no se puede enseñar, que no se reduce a un proceso. Se puede enseñar contabilidad. Se puede incluso automatizarla, confiársela a una IA. Pero existen competencias que no sabemos formalizar. ¿Por qué cierta persona es excelente en un ámbito que no conseguimos reproducir? Es conocimiento específico —construido por la experiencia, la intuición, el contexto vivido.
Creo que es ahí donde el humano se recentra. La IA se encarga de lo que es formalizable: la producción de contenido, la agregación, la presentación. El humano conserva lo que no lo es: la opinión. Porque hacer producto es cruzar datos cuantitativos y cualitativos, contrastar señales débiles —pero al final, es tener una convicción. Y una convicción no se delega.
Tener una opinión es a veces asumir riesgos desmesurados. En una startup, algunos eligen tener un 1 o 2 % de posibilidades de convertirse en unicornio —y un 99 % de posibilidades de fracasar. ¿Qué IA tomaría esa decisión? Asumir riesgos, mantener posiciones tajantes, apostar por una visión que los datos aún no validan —una IA no sabe hacer eso. No hoy, al menos. Y es precisamente eso lo que da a un editor de software su cultura, su color, su ADN. Lo que hace que un producto no sea intercambiable con otro, aunque las features se parezcan. No es la IA quien crea esa diferencia —es el humano que hay detrás.
Este sistema de contextos no es un fin en sí mismo. Es una herramienta para que el humano pueda concentrarse en lo que mejor hace —pensar, decidir, tener un punto de vista— delegando el resto a una IA que por fin tiene los medios para recordar.
Este sistema gestiona el upstream —la reflexión, la estructuración, la decisión. Pero en el downstream, otra transformación está en marcha.
Todos lo hemos vivido: una documentación se produce en el momento de la especificación, luego el desarrollo avanza, se toman arbitrajes, se hacen ajustes sobre la marcha —y nadie tiene tiempo de volver a actualizar cada spec, cada changelog, cada documento de soporte. El resultado es siempre el mismo: la documentación y el código acaban por divergir. Cuanto más envejece el producto, más crece la brecha.
Hoy, la IA permite invertir ese flujo. Cuando el código es suficientemente limpio y documentado, se puede convertir en la fuente a partir de la cual se reconstruye todo lo demás: actualizar una documentación de soporte tras una entrega, generar un changelog más fiable, o reconstituir una especificación funcional a partir del estado real del producto en lugar de a partir de un documento antiguo.
Es lo que se puede llamar un enfoque code centric. El código ya no es solo el livrable final —se convierte en el elemento central, la fuente de verdad alrededor de la cual gravitan y se regeneran los demás artefactos del producto. La misma lógica vale para el diseño: si somos capaces de reconstruir un design system a partir del código real y mantenerlo actualizado, la maqueta cambia de estatus —ya no sigue siendo una representación fija, se convierte en una base explotable.
Exploro esta idea con más detalle en este artículo.
Para saber más
El PM como arquitecto del Contexto Añadir una memoria de sesión como en OpenClaw