La memoria es arquitectura

---

1.1El problema

En N1 le diste a Magallanes una compaction que preserva lo que no debe perderse: estado, decisiones, problemas abiertos. Funciona. Lo viste en la traza: el resumen entra, el historial viejo se descarta, el run sigue. Dentro del hilo, Magallanes ya no pierde el hilo.

Hoy el proceso muere a mitad de encargo. Es la avería de este nivel: el lab mata a Magallanes en el turno 18 de un encargo de unos 35. Lo relanzas. Y no queda nada.

No queda el resumen de la compaction. No queda el plan. No quedan las fuentes que ya evaluó y descartó. Magallanes de serie re-busca lo que buscó, relee lo que leyó, reescribe lo que escribió. El encargo empieza de cero por segunda vez.

Quizá pienses que la solución es un mejor resumen. No lo es. La compaction salvó el run; nada salva lo aprendido entre runs. El resumen vive y muere con el hilo del proceso.

Eso no se arregla con prosa más densa en el <summary>. Se arregla con arquitectura: con piezas que viven fuera del proceso y sobreviven a su muerte. Esta lección te da el mapa de esas piezas. Aún no las cableas —eso es L2, L3 y L4—; hoy decides cuál resuelve cada necesidad.

---

1.2Qué vas a poder hacer

Al terminar serás capaz de:

• Clasificar una necesidad de memoria con la taxonomía CoALA: working, episodic, semantic o procedural.
• Decidir si esa necesidad pertenece a short-term (checkpointer, thread-scoped) o a long-term (Store, cross-thread).
• Elegir la estrategia de escritura: hot path (en el turno) o background (diferida), con la justificación escrita.
• Construir el mapa de memoria de un agente: una tabla con necesidad → tipo → mecanismo → hot/background.

Necesitas saber antes:

• De N1 (nivel palancas-y-compaction): qué tres cosas preservaba tu nodo de compaction y por qué. Lo recuperamos en 1.3.
• De N0·L3 (El presupuesto de tu agente): qué partida del contexto crecía por turno. También en 1.3.
• El esqueleto congelado de Magallanes: el grafo de LangGraph y sus 3 tools (buscar, leer, escribir_seccion).

Empatía por adelantado: esta lección introduce cuatro etiquetas nuevas de golpe. Parecen jerga. No memorices las definiciones. La tabla del worked example es el ancla: cada etiqueta es una columna de una decisión que ya tomabas a ciegas.

---

1.3Recupera

Antes de seguir, responde de memoria. Esto reactiva lo previo y engancha lo nuevo.

1. De N1: tu nodo de compaction preservaba explícitamente tres cosas. ¿Cuáles eran y por qué esas tres?
2. De N1: lo que el resumen descarta, ¿qué destino tiene? ¿Reaparece en algún sitio?
3. De N0·L3: en Magallanes, ¿qué partida del presupuesto crecía más rápido por turno?

Comprueba tu respuesta

1. Estado, decisiones y problemas abiertos. El prompt de compaction por defecto pide incluir "anything that would be helpful, including the state, next steps, learnings etc." en el resumen. Son las tres cosas cuya pérdida obliga a re-trabajar. · fuente: corpus B.4 (doc de compaction, tier 1).
2. Ninguno, por defecto. Lo que el resumen descarta se descarta de verdad: la compaction descarta los mensajes anteriores tras generar el bloque resumen. Esa es exactamente la laguna que abre este nivel. · fuente: corpus B.4.
3. El historial y los tool results acumulados en él. El loop ReAct es append-only: cada resultado de tool se queda. Esa pendiente es la que la compaction ataca dentro del hilo. · fuente: corpus A.6 (contexto append-only).

Fija el tercer punto. La compaction comprime ese historial dentro del hilo. Lo que necesitas hoy es preservar lo aprendido fuera del hilo. Misma intención, otro scope.

---

1.4El concepto

Dónde encaja la memoria en el mapa del curso

En N0 viste las palancas de Lance Martin sobre el contexto. Una de ellas es write — "saving it outside the context window to help an agent perform a task" — scratchpads y memories. · fuente: corpus B.2 (Lance Martin, 23 jun 2025, tier 2).

N2 es el nivel de esa palanca. Todo lo de aquí es escribir información fuera de la ventana de contexto para que el agente la recupere después. La pregunta no es si escribir fuera, sino qué tipo de memoria es cada cosa y dónde vive.

La taxonomía CoALA

Aquí están las cuatro etiquetas. CoALA es una taxonomía de la memoria de agentes con cuatro tipos. Viene del paper Cognitive Architectures for Language Agents (arXiv:2309.02427, tier 1). Las definiciones son verbatim del paper:

• Working — "active and readily available information… for the current decision cycle". Lo que el agente tiene delante ahora mismo para decidir el siguiente paso.
• Episodic — "experience from earlier decision cycles". Lo que pasó en interacciones anteriores: qué hizo y cómo salió.
• Semantic — "knowledge about the world and itself". Hechos estables: cómo es el mundo, cómo es el propio agente.
• Procedural — implícita en los pesos del modelo, o explícita en código y reglas. El cómo se hacen las cosas.

· fuente: corpus C.1 (CoALA, tier 1).

Analogía: la memoria de un agente es como la documentación de un equipo de ingeniería. El acta de la reunión de hoy es working: lo que tienes delante en esta sesión. El postmortem de un incidente es episodic: qué pasó la última vez y qué aprendimos. La wiki es semantic: hechos estables del sistema. El runbook es procedural: el procedimiento, paso a paso.

Límite de la analogía: la wiki no se consulta sola. Un humano decide abrirla. En el agente, la política de recuperación es parte del diseño, no buena voluntad: si no programas cuándo y qué se recupera, no se recupera. Volvemos a esto en L3.

Los dos scopes: short-term vs long-term

CoALA dice qué tipo de memoria. LangGraph dice dónde vive. Operacionaliza la taxonomía con dos scopes, y la distinción es la decisión central del nivel:

• Short-term = thread-scoped. Lo gestiona el checkpointer: persiste el estado de un hilo (thread_id). Sirve la continuidad de una sesión.
• Long-term = cross-thread. Lo gestiona el Store: guarda información bajo namespaces, accesible desde cualquier hilo. Sirve la continuidad entre sesiones.

El corpus lo resume en una frase: "el checkpointer resuelve la continuidad de sesión; el Store, la continuidad de la relación". · fuente: corpus C.1 (docs LangGraph, tier 1).

LangGraph mapea los tipos de CoALA a mecanismos concretos: semantic → perfiles y hechos; episodic → few-shots de interacciones exitosas; procedural → system prompt y reglas. · fuente: corpus C.1.

Dentro del scope short-term, el agente puede además escribir notas estructuradas —estado, decisiones, pendientes— en herramientas dedicadas que L2 implementa. En la tabla de 1.5 aparecen como "NOTES (thread)".

Aquí está el puente con tu problema de 1.1. La compaction de N1 vive en el estado del hilo: es short-term. Cuando el proceso muere, el InMemorySaver muere con él y el resumen se va. Lo que sobrevive a la muerte del proceso necesita persistir en disco (checkpointer persistente) o vivir cross-thread (Store). · fuente: corpus F.1 (LangGraph v1.2.4, tier 1). Esa es la arquitectura que falta.

La estrategia de escritura: hot path vs background

Falta una decisión más por cada pieza: cuándo se escribe. El corpus distingue dos estrategias:

• Hot path — el agente escribe dentro del turno. La información está disponible al instante. Coste: añade latencia y carga al agente durante la tarea.
• Background — la escritura es diferida, en un paso aparte tras el run. No añade latencia a la tarea. Coste: tienes que decidir la frecuencia, y la información no está al instante.

· fuente: corpus C.1 (docs LangGraph, tier 1).

La regla práctica: escribe en hot path lo que el agente debe poder consultar dentro del mismo encargo (su plan, sus pendientes). Escribe en background lo que puede esperar al cierre y no quieres que cargue al agente mientras trabaja (el destilado de qué fuentes resultaron fiables).

Lo que NO es memoria long-term

Es común confundir dos cosas con memoria long-term que no lo son. Marca la diferencia ahora, porque las dos confusiones tumban dimensiones de la rúbrica de este nivel.

Contraejemplo 1 — la compaction NO es memoria long-term. El resumen de N1 es working memory comprimida: vive en el estado del hilo y muere con él. Comprimir el historial es una palanca distinta (compress, no write). La compaction y la memoria son piezas complementarias —lo verás en L4—, pero no son la misma cosa.

Contraejemplo 2 — un log con todas las trazas NO es memoria. Volcar cada turno "por si acaso" no es memoria: sin política de qué escribir y de qué recuperar, es un vertedero. Y ese vertedero tiene un riesgo que aún no has visto: si alguien mete basura ahí, el agente la sirve como contexto fiable. Es el memory poisoning de L4. La idea esencial del nivel: un store sin política de escritura es un vertedero que, además, envenena.

---

1.5Míralo funcionar

Vamos a construir el mapa de memoria de Magallanes: una tabla que clasifica cinco necesidades reales y decide la pieza para cada una. Esto es el corazón de la lección — no es código, es la decisión de diseño que el código de L2–L4 ejecutará.

Antes de leer la tabla fila a fila, lee las cinco necesidades primero, de corrido. Lo difícil no es ninguna fila suelta. Es ver que cada una cae en un tipo y un scope distintos. Primero hazte una idea del conjunto.

Las cinco necesidades reales de Magallanes:

1. Retomar un encargo a mitad, tras un kill del proceso (el plan, qué quedó pendiente).
2. No repetir búsquedas dentro del mismo encargo (qué ya buscó y descartó).
3. Recordar entre encargos qué fuentes del corpus son fiables por tema (lo aprendido evaluando documentos).
4. Conservar las preferencias de formato del informe entre encargos (cómo le gusta al usuario el entregable).
5. Aplicar siempre las reglas de citación (cada afirmación con su doc_id).

Ahora el mapa. Tres columnas de decisión por necesidad, cada una justificada:

Necesidad	Tipo CoALA	Scope · mecanismo	Escritura	Por qué
1. Retomar el encargo tras el kill	working	short-term · checkpointer	(lo repone el checkpointer)	El estado del hilo es working memory; el checkpointer persistente lo repone al relanzar con el mismo thread_id.
2. No repetir búsquedas en el encargo	working	short-term · NOTES (thread)	hot path	El plan y lo descartado son del encargo en curso; el agente los necesita al instante en cada turno → se escriben en caliente.
3. Fuentes fiables por tema	semantic	long-term · Store	background	Hecho estable verificado, útil entre encargos; destilarlo puede esperar al cierre → background, sin cargar al agente mientras trabaja.
4. Preferencias de formato	procedural	long-term · Store / system prompt	hot path o config	Regla estable cross-encargo; si es fija va al system prompt, si la aprende del usuario va al Store.
5. Reglas de citación	procedural	en el system prompt	(no es memoria de runtime)	Es una regla fija del agente, no algo que aprenda o recupere. Vive en las instrucciones, no en un store.

Lee la tabla por columnas, no por filas. Mira la columna tipo CoALA: la misma palabra ("memoria") esconde cuatro cosas distintas. Mira la columna scope: dos necesidades viven en el hilo (mueren con él si no persistes), tres lo trascienden. Mira la columna escritura: lo que el agente consulta dentro del turno va en caliente; lo que puede destilarse al cierre va en background.

Fíjate en la fila 5. Las reglas de citación no son memoria de runtime: son una regla fija que vive en el system prompt. Meterlas en un store sería convertir una instrucción en un dato que se recupera — más coste, ningún beneficio. No todo "lo que el agente debe saber" es memoria.

Self-explanation

Antes de leer la respuesta, intenta tú: ¿por qué "fuentes fiables por tema" (fila 3) es semantic y no episodic? ¿Qué cambiaría para que fuera episodic?

Razónalo y comprueba

Es semantic porque lo que guardas es un hecho estable sobre el mundo: "el documento doc-014 es fiable para el subtema de financiación". No guardas la experiencia de cómo llegaste a esa conclusión; guardas la conclusión, atemporal. Encaja con la definición de CoALA: "knowledge about the world". · fuente: corpus C.1.

Sería episodic si guardaras la experiencia de un encargo concreto: "en el encargo 7 el doc-014 me dio la respuesta de la sección 3". Eso es "experience from earlier decision cycles": la traza de una interacción, no un hecho destilado. · fuente: corpus C.1.

La diferencia operativa está en cómo la recuperas. La semantic, por tema (search por "financiación"). La episodic, por similitud con la situación actual: qué hice la última vez que me enfrenté a algo parecido. LangGraph mapea episodic a few-shots de interacciones exitosas. · fuente: corpus C.1.

Si dijiste "es episodic porque viene de encargos pasados", revisa. El origen es pasado, sí — pero lo que persistes es el hecho destilado (fiable/no fiable), no el episodio. El tipo lo fija qué guardas, no de dónde lo sacaste.

---

1.6Hazlo tú

Andamiaje decreciente: primero completas un mapa parcial, luego construyes uno entero de cero.

Ejercicio 1 — completa el mapa (celdas vacías)

Cuatro necesidades nuevas de Magallanes, ya parcialmente clasificadas. Completa las celdas vacías y justifica cada una en una frase.

Necesidad	Tipo CoALA	Scope · mecanismo	Escritura
a. La estructura de secciones que ya cerró en este encargo	working	short-term · NOTES	?
b. Que el usuario prefiere informes en bullet points, no prosa	?	long-term · Store	background
c. Un resumen de una fuente leída, útil solo en este encargo	working	?	hot path
d. Que cierta API de búsqueda devuelve ruido para queries cortas	semantic	long-term · Store	?

Elaborative interrogation — antes de mirar: ¿alguna de estas NO debería persistirse fuera del turno? ¿Cuál y por qué?

Comprueba tu respuesta

• a. Escritura: hot path. Es del encargo en curso y el agente la consulta cada vez que va a abrir una sección nueva (para no reabrir una cerrada) → al instante, en caliente.
• b. Tipo: procedural. Es una regla de cómo producir el entregable, aprendida del usuario. Cross-encargo, en el Store, destilada en background.
• c. Scope · mecanismo: short-term · NOTES (thread). Es working, útil solo aquí; muere con el encargo y eso está bien — no contamina el Store con algo efímero.
• d. Escritura: background. Es un hecho estable que destila al cierre; no necesita estar disponible al instante dentro del turno en que lo descubres.

Sobre la pregunta: la candidata a NO persistir fuera del turno es c — pero sí cabe en las NOTES del encargo (thread), porque ayuda dentro de este run. Lo que sería un error es subirla al Store cross-encargo: un resumen útil solo aquí no es conocimiento del mundo, es ruido en la memoria larga. Persistir en el thread sí, en el Store no.

Feedback formativo: si acertaste el tipo de b (procedural, no semantic), dominas la distinción más sutil del nivel — "cómo producir el informe" es procedimiento, no hecho. Si lo marcaste semantic, repasa 1.4: semantic es qué es verdad del mundo; procedural es cómo se hace.

Ejercicio 2 — un mapa de cero (sin andamiaje)

Coge un agente de tu propio trabajo (o uno que conozcas bien). Identifica cinco necesidades de memoria reales y construye su mapa completo: necesidad → tipo CoALA → scope/mecanismo → hot/background, con la justificación de cada celda escrita.

Reglas que hacen válido el mapa:

• Al menos una necesidad de cada scope (una short-term, una long-term).
• Al menos una que NO debería ser memoria de runtime (vive en el system prompt) — y di por qué.
• Cada elección de hot/background justificada por el coste: ¿qué encarecería la alternativa?

No hay solución cerrada; reutiliza el patrón de la tabla de 1.5. El criterio de calidad es que un revisor pueda discrepar de una celda leyendo tu justificación, no adivinándola.

---

1.7Comprueba

Sin pistas. Gate de maestría: clasificar cinco escenarios, uno de ellos trampa.

Para cada escenario, da las tres decisiones (tipo CoALA + scope/mecanismo + hot/background) y justifica en una frase. Uno de los cinco es una trampa: algo que no debería persistirse porque pertenece al contexto del turno.

1. Magallanes descubre, leyendo doc-031, que contradice a doc-014 en una fecha clave. Quieres que en futuros encargos sepa que doc-031 no es fiable para fechas.
2. A mitad del encargo actual, Magallanes ha decidido el orden de los ocho subtemas. Quieres que al retomar tras un kill no rehaga ese orden.
3. El usuario, por tercer encargo seguido, pide el informe con un resumen ejecutivo de tres frases al inicio.
4. El resultado bruto de la última llamada a buscar("rutas comerciales"): la lista de diez doc_id que devolvió este turno.
5. La regla de que toda afirmación numérica del informe debe llevar su doc_id entre paréntesis.

Criterio de corrección + feedback

1. Semantic · long-term (Store) · background. Hecho estable verificado sobre una fuente; útil entre encargos; destila al cierre. (Variante aceptable: marcar la proveniencia, anticipando L4.)
2. Working · short-term (NOTES, thread) · hot path. El plan del encargo en curso; el agente lo consulta cada turno; el checkpointer + las NOTES lo reponen tras el kill.
3. Procedural · long-term (Store) · background. Preferencia de formato aprendida del usuario; cómo producir el entregable, no un hecho del mundo; destila al cierre.
4. TRAMPA — NO se persiste. Es working memory del turno: vive en el estado del hilo mientras el agente decide qué leer. Subirlo al Store sería convertir un resultado intermedio en memoria larga — un resultado re-recuperable con buscar(), que solo pagaría renta en la ventana. Pertenece al contexto del turno y se queda ahí.
5. Procedural · system prompt · no es memoria de runtime. Regla fija del agente, no algo que aprenda o recupere; vive en las instrucciones.

Feedback formativo: si marcaste el 4 como la trampa y diste una razón sobre el coste de recuperarlo, dominas lo esencial — distinguir lo que merece persistir de lo que es ruido es la decisión que separa una arquitectura de un vertedero. Si persististe el 4 en el Store, repasa el contraejemplo 2 de 1.4: sin política, todo resultado "por si acaso" envenena la memoria. Gate: necesitas el 4 identificado como trampa y al menos tres de los otros cuatro con el scope correcto.

---

1.8Conecta

Acabas de hacer explícita una decisión que tomabas a ciegas. "Darle memoria a un agente" no es una cosa: son cuatro tipos, dos scopes y dos estrategias de escritura. Cada necesidad cae en una combinación concreta.

Este mapa es la dimensión 2 de la rúbrica del checkpoint C2, hecha política. C2 te pedirá exactamente esto convertido en código: qué escribe el agente y cuándo (hot path vs background, justificado), qué recupera y cuándo. Hoy hiciste el mapa; el resto del nivel lo cablea.

La ruta es directa:

• L2 implementa las NOTES del encargo en curso (las filas working/short-term del mapa). El agente escribe su plan y lo recupera al retomar.
• L3 monta el Store cross-encargo (las filas semantic/long-term), con sus políticas de escritura y recuperación y la lista de qué NO guardar.
• L4 lo somete a la avería del nivel: el kill del proceso, medido. Y audita la cara oscura del vertedero: el poisoning.

Cierra el arco de 1.1. El kill que borraba todo no se arregla con un mejor resumen. Se arregla con piezas que viven fuera del proceso: el checkpointer persistente repone el hilo, las NOTES devuelven el plan, el Store conserva lo aprendido. Lo que hoy es un mapa, en L4 será un agente que absorbe un reinicio sin re-trabajo.

---

1.9Reflexiona

Tómate un minuto. Responder esto por escrito consolida mejor que releer.

• ¿Qué aprendiste? Resume en una frase la diferencia entre short-term y long-term, y qué la decide.
• ¿Qué sigue sin estar claro? ¿Distingues semantic de procedural sin dudar? Si no, vuelve a 1.4: semantic es qué es verdad, procedural es cómo se hace.
• ¿Qué harías distinto? La próxima vez que alguien diga "voy a darle memoria al agente", ¿qué tres preguntas le harías antes de aceptar que eso es un plan?

Esto requiere práctica. La intuición de "qué tipo y qué scope" llega construyendo mapas y cableándolos, no leyendo las definiciones. En L2 conviertes la primera fila de tu mapa en código que sobrevive a una compaction.

---