La memoria que sobrevive (mastery gate C2)
producirás el entregable completo del checkpoint C2 sobre Magallanes: agente con memoria (notas + store con políticas), demo del reinicio sin re-trabajo, trade-off medido contra full-context y auditoría de poisoning con mitigación aplicada. Importa porque en producción los reinicios no avisan, y "mi agente tiene memoria" no es una afirmación: es algo que se demuestra con una tabla.
6.1El problema
En producción, los reinicios no avisan. Un deploy reemplaza el pod a media tarde. Un OOM-kill mata el proceso por presión de memoria. Una rotación rutinaria de infraestructura recicla la máquina. Tu agente corre encargos de horas.
La pregunta de aceptación de cualquier revisor serio será una sola: "¿sobrevive a un reinicio sin re-trabajo, y cómo lo demuestras?". No "¿tiene memoria?" —demasiado vago—. La pregunta operativa es si, tras el kill, retoma donde estaba o reempieza pagando los mismos tokens dos veces.
En L4 mataste a Magallanes en el turno 18 de un encargo de ~35 y lo viste sobrevivir. Hoy no añades una pieza nueva. Hoy juntas las cuatro que ya tienes —notas, store, políticas, supervivencia— en un solo artefacto que un revisor pueda leer y firmar. Ese artefacto es el checkpoint C2.
Esta lección no enseña un concepto. Integra el nivel: te da la estructura del entregable, la rúbrica con la que se juzga y un ejemplo defectuoso que corregirás antes de hacer el tuyo.
6.2Qué vas a poder hacer
Al terminar serás capaz de:
- Estructurar el entregable C2 como artefacto de ingeniería, con sus cinco partes en orden de ataque.
- Aplicar la rúbrica C2 dimensión a dimensión sobre un entregable ajeno, emitiendo feedback formativo por cada una.
- Producir tu propio entregable C2 sobre Magallanes: arquitectura de memoria, demo del reinicio, trade-off medido y auditoría de poisoning.
- Defender cada decisión de política con su justificación escrita, no con "está implícito en el código".
Necesitas traer de las lecciones previas:
- De L1 (
/cursos/context-engineering/memoria/la-memoria-es-arquitectura): la taxonomía CoALA y los dos scopes (thread vs cross-thread). - De L2 (
/cursos/context-engineering/memoria/note-taking-estructurado): las notas con estructura (estado, decisiones, pendientes). - De L3 (
/cursos/context-engineering/memoria/el-store-externo): el Store con sus políticas write y select. - De L4 (
/cursos/context-engineering/memoria/sobrevivir-al-reinicio): el kill del lab, la métrica de re-trabajo y la auditoría de poisoning. - Del sweep de N0 (
/cursos/context-engineering/diagnostico/el-context-sweep): el baseline congelado que la dimensión 4 vuelve a ejecutar.
6.3Recupera
Antes de montar el entregable, responde de memoria. Esto mezcla a propósito las categorías confundibles del nivel: el gate las va a mezclar también.
- Una necesidad: "recordar entre encargos qué fuentes del corpus son fiables por tema". Clasifícala: tipo CoALA, mecanismo, hot path o background.
- Una entrada del store:
{doc_id: "doc-099", veredicto: "fiable"}, escrita tras leer un solo documento sin contrastarlo. ¿Pasa tu política de write? - Tras el kill en el turno 18, ¿qué pieza repone el estado del grafo y qué pieza devuelve el plan?
- Un post de vendor: "91% menos latencia". ¿Qué matiz le falta para que el número signifique algo?
Y el retrieval espaciado del método: re-ejecuta el sweep baseline de N0 sobre tu Magallanes actual. Lo necesitas para la dimensión 4 y conviene lanzarlo ahora, mientras lees.
Comprueba tus respuestas
- Semantic, no episodic: es conocimiento estable sobre el mundo (qué fuente es fiable), no la experiencia de un encargo concreto. Mecanismo: Store (cross-thread). Escritura: background — el veredicto puede destilarse tras cerrar el informe, sin latencia en el turno. · fuente: corpus C.1 (CoALA + LangGraph short/long-term).
- No. Viola la política de write de L3: es un dato sin verificar. La regla que lo para: persistir solo veredictos contrastados en ≥1 encargo o con origen de confianza. Guardar "fiable" tras una lectura es exactamente el vector de poisoning de L4. · fuente: corpus C.7 (vector clásico de memory poisoning).
- El checkpointer repone el estado del grafo si invocas con el mismo
thread_id; conPostgresSaversobrevive al proceso, conInMemorySaverno.leer_notasdevuelve estado, decisiones y pendientes sin releer el historial. · fuente: corpus F.1 + esqueleto congelado N2. - Le falta el baseline: ¿menos latencia contra qué? El claim de Mem0 compara contra full-context (pasar ~26K tokens de conversación entera: 1,44s vs 17,12s p95), no contra otros sistemas de memoria. · fuente: corpus C.5.
6.4El entregable C2 como artefacto de ingeniería
El checkpoint C2 no es un ejercicio suelto. Es un artefacto de ingeniería: un documento que demuestra una propiedad del sistema con evidencia reproducible, igual que un informe de pruebas demuestra que un puente aguanta la carga. Su valor no está en afirmar "Magallanes tiene memoria", sino en dejar que otro lo verifique sin tu presencia.
La analogía: el entregable C2 es como el acta de aceptación de una obra. No dice "la casa está bien"; lista cada sistema (eléctrico, fontanería, estructura) con su prueba superada y su medición. Dónde falla la analogía: el acta de obra la firma un inspector externo con norma fija. Aquí tú redactas la prueba y la rúbrica, así que el rigor depende de no corregirte a la baja a ti mismo.
La estructura, en orden de ataque
El entregable tiene cinco partes. El orden en que las escribes importa menos que el orden en que las construyes:
- Arquitectura de memoria con su mapa de políticas. Qué piezas usas (checkpointer, notas, Store), qué tipo CoALA cubre cada una, y la tabla de políticas: qué escribe, cuándo, hot path o background, qué recupera y cuándo.
- Demo del reinicio con tabla de re-trabajo. El kill del lab en el turno 18, el Magallanes de serie contra el Magallanes con memoria, y el re-trabajo medido sobre la traza Langfuse: búsquedas repetidas, documentos releídos, secciones reescritas.
- Comparativa contra full-context con el sweep. El baseline de N0 re-ejecutado, ahora con una columna nueva: tu agente con memoria frente a llevarlo todo en contexto. Tokens, latencia, calidad, en tabla.
- Auditoría de poisoning con la mitigación aplicada. Un escenario de contaminación plantado y probado, no descrito; la mitigación (proveniencia, scoping o decay) aplicada y verificada en la traza.
- Conclusión accionable. Qué demuestra el conjunto y qué decidirías distinto en producción.
El orden de ataque sensato: primero 1→2 (la arquitectura y su supervivencia), luego 3 (medir el trade-off vs full-context), luego 4 (auditar el riesgo), al final 5 (la conclusión). Intentar las cinco a la vez bloquea.
La rúbrica C2, dimensión a dimensión
Cinco dimensiones, todas obligatorias en espíritu. Esto es lo que la rúbrica evalúa, y el error típico que tumba cada una.
Dimensión 1 — Note-taking efectivo. Magallanes retoma desde sus notas sin releer todo el historial; las notas tienen estructura (estado, decisiones, pendientes). Error que la tumba: notas-diario que apilan "hice X, luego Y" y crecen linealmente con los turnos. El síntoma: la nota engorda turno a turno en vez de sobrescribir el estado.
Dimensión 2 — Store con políticas. Qué y cuándo escribe (hot path vs background, justificado) y qué y cuándo recupera; namespacing correcto. Error que la tumba: el store vertedero, o políticas "implícitas en el código" que no sabes explicar fuera de él.
Dimensión 3 — Supervivencia demostrada. Reinicio sin pérdida de estado, medido: tarea completada frente a re-trabajo. Error que la tumba: una "supervivencia" que re-inyecta el historial completo. Eso no es sobrevivir; es re-trabajo encubierto pagado en tokens.
Dimensión 4 — Trade-off medido. Coste, latencia y calidad contra full-context, con números. Error que la tumba: el trade-off narrado sin tabla. "Ahorra tokens" no es un dato; "1,8K vs 26K" lo sería —pero ese es el de Mem0, no el tuyo: el tuyo sale del sweep.
Dimensión 5 — Riesgo auditado. Un escenario de poisoning probado y una mitigación aplicada (proveniencia, scoping o decay). Error que la tumba: describir el riesgo sin plantar el escenario ni aplicar el fix. "El store es superficie de ataque" es cierto y no demuestra nada.
Es común leer estas cinco dimensiones y sentir que pesan demasiado para una entrega. No es así por casualidad: cada una corresponde a una lección que ya implementaste. La dimensión no añade trabajo nuevo; te pide enseñar el que ya hiciste.
6.5Míralo funcionar: leer un entregable con la rúbrica
Antes de redactar el tuyo, vas a juzgar uno ajeno. Leer con la rúbrica delante es la mejor preparación: ves qué la satisface y qué la deja coja, sin el sesgo de defender lo propio.
Este entregable de ejemplo es de una variante de Magallanes, calibrado a propósito: fuerte en las dimensiones 1, 3 y 4; flojo en la 2 y la 5. Léelo entero una vez, luego repasa el feedback por dimensión.
El entregable de ejemplo (resumido)
Parte 1 — Arquitectura. Magallanes usa
PostgresSaver(hilo), las dos tools de notas (leer_notas/escribir_notas) y unPostgresStorepara fuentes. Mapa: working→checkpointer, working del encargo→notas, semantic→store. Política: "el store guarda lo que el agente decide guardar tras cada lectura".Parte 2 — Demo del reinicio. Kill en el turno 18. Magallanes de serie: 9 búsquedas repetidas, 6 documentos releídos, 2 secciones reescritas. Magallanes con memoria, reanudado con el mismo
thread_id: 0 búsquedas repetidas, 0 documentos releídos, 0 secciones reescritas. Tabla con ambas columnas sobre traza Langfuse.Parte 3 — Trade-off. Sweep de N0 re-ejecutado. Con memoria: ~1,9K tokens de contexto medio, 2,1s de latencia, calidad 0,88. Full-context: ~24K tokens, 9,4s, calidad 0,71 (cae por context rot). Tabla con las tres métricas a cuatro longitudes.
Parte 4 — Auditoría. "El store es superficie de ataque: un atacante podría inyectar una memoria falsa que el agente luego usaría. Habría que añadir proveniencia."
Parte 5 — Conclusión. Magallanes sobrevive al reinicio sin re-trabajo y cuesta menos que full-context.
Feedback formativo, dimensión a dimensión
Esta es la estructura que tú emitirás en tu propia auto-revisión: [fortaleza específica + por qué importa] + [brecha concreta] + [siguiente paso].
Dim 1 — Note-taking. Fortaleza: la demo de la parte 2 prueba 0 secciones reescritas, lo que solo ocurre si las notas devolvieron el plan intacto tras el kill —eso es exactamente lo que mide la dimensión—. Brecha: el entregado no muestra la nota en sí, solo su efecto. Siguiente paso: pega una nota real del run con sus tres campos (estado, decisiones, pendientes) para que el revisor vea la estructura, no solo el resultado.
Dim 2 — Store con políticas. Fortaleza: el mapa CoALA está completo y asigna cada necesidad a una pieza. Brecha grave: "guarda lo que el agente decide guardar tras cada lectura" no es una política —es la ausencia de una—. No dice qué merece persistir, ni si va en hot path o background, ni qué recupera al abrir un encargo. Es el store vertedero de L3, y guardar tras cada lectura sin verificar es el vector de poisoning de L4. Siguiente paso: escribe la tabla write/select de L3 con cinco columnas (qué, cuándo, namespace, hot/background, qué recupera) y justifica por qué el destilado va en background.
Dim 3 — Supervivencia. Fortaleza: la tabla contrasta serie contra memoria con números sobre traza, y el re-trabajo cae a 0 sin re-inyectar el historial —es supervivencia real, no encubierta—. Brecha: falta la variante de reanudar como thread nuevo (solo notas + store, sin checkpointer) para mostrar qué se conserva y qué no. Siguiente paso: añade esa tercera columna; distingue lo que repone el checkpointer de lo que conservan notas y store.
Dim 4 — Trade-off. Fortaleza: las tres métricas están y la comparación es contra el baseline correcto (full-context), con la calidad cayendo por context rot —el trade-off es real y va en la dirección esperada—. Brecha: la tabla resume; no muestra la forma a las cuatro longitudes del sweep. Siguiente paso: incluye la curva de las cuatro longitudes, no solo el agregado; el codo es el dato que prioriza.
Dim 5 — Riesgo. Fortaleza: identifica correctamente que el store es superficie de ataque. Brecha grave: describe el riesgo y no lo prueba. No hay escenario plantado, no hay search sirviendo la entrada contaminada en una traza, no hay mitigación aplicada —solo "habría que añadir proveniencia"—. Es justo el error que tumba la dimensión. Siguiente paso: planta la entrada {doc_id: "doc-099", veredicto: "fiable"} sobre un documento con un dato falso, captura en la traza cómo el search la sirve, aplica el filtro de proveniencia en el select y vuelve a correr para mostrar que ya no la sirve.
Self-explanation
Antes de leer la respuesta, razónalo tú: ¿por qué la mitigación de la dimensión 5 va en el select y no solo en el write?
Razónalo y comprueba
Porque el write solo controla lo que tú escribes. El ataque MINJA inyecta memorias maliciosas mediante queries, sin tocar el store directamente: el agente lee contenido envenenado y lo guarda él mismo. Si tu única defensa está en el write, ya la has pasado —fue el propio agente quien escribió—. · fuente: corpus C.7 (MINJA, arXiv:2503.03704: inyección solo con queries; ISR >90% en la mayoría de configuraciones del paper).
El select es la segunda barrera: aunque entre basura, el filtro de proveniencia decide qué se sirve de vuelta al contexto. Filtrar en el select (solo entradas verificadas en ≥1 encargo previo o de origen de confianza) para el ataque que ya consiguió escribir. Las dos barreras paran ataques distintos: el write para lo que tú escribes mal; el select, lo que el agente fue inducido a escribir.
Si pensaste "con un buen write basta", revisa el vector clásico: el agente lee un README malicioso, guarda un resumen, y semanas después actúa sobre la memoria contaminada —el atacante ya no está, y tu write nunca lo vio como sospechoso—. · fuente: corpus C.7.
6.6Hazlo tú = checkpoint C2
Sin andamiaje. Este es el entregable. Produces, sobre Magallanes, las cinco partes de 6.4, evaluadas con la rúbrica de cinco dimensiones de C2.
La tarea es una sola: dar a Magallanes memoria que sobrevive y demostrarlo. Concretamente:
- Arquitectura + políticas. Note-taking estructurado (las tools de notas de L2) + store cross-sesión con políticas write/select explícitas (L3). Entrega la tabla de políticas, no el código suelto.
- Tarea multi-sesión que sobrevive al kill. Lanza un encargo de ~35 turnos, activa el flag del lab (kill en el turno 18), reanuda con el mismo
thread_idy demuestra que retoma sin re-trabajo y con estado consistente. Tabla de re-trabajo sobre Langfuse. - Trade-off medido contra full-context. Re-ejecuta el sweep de N0. Compara Magallanes-con-memoria contra llevarlo todo en contexto: tokens, latencia, calidad, a las cuatro longitudes.
- Auditoría de memory poisoning. Planta un escenario de contaminación, pruébalo en la traza, aplica una mitigación y verifica que detiene el ataque.
- Conclusión accionable. Qué demuestra el conjunto y qué decidirías distinto si fuese tu agente en producción.
El esqueleto que cableas es el congelado del nivel. Recuérdalo antes de empezar:
1# magallanes_n2.py — superficie congelada del nivel (APIs del corpus §F)
2from langgraph.graph import StateGraph, MessagesState, START, END
3from langgraph.checkpoint.postgres import PostgresSaver # sobrevive al kill (L4)
4from langgraph.store.postgres import PostgresStore # long-term, persistente
5
6def buscar(query: str) -> list[dict]: ...
7def leer(doc_id: str) -> str: ...
8def escribir_seccion(titulo: str, contenido: str) -> str: ...
9def leer_notas() -> str: ... # estado, decisiones, pendientes
10def escribir_notas(contenido: str) -> str: ... # sobrescribe (no apila historia)
11
12# Persistencia que sobrevive al proceso (L4):
13with PostgresStore.from_conn_string(DB_URI) as store:
14 store.setup() # crea tablas + migraciones (idempotente)
15 with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
16 checkpointer.setup()
17 builder = StateGraph(MessagesState)
18 ...
19 graph = builder.compile(checkpointer=checkpointer, store=store)
20
21 # Reanudar tras el kill: MISMO thread_id → el checkpointer repone el estado.
22 result = graph.invoke(
23 {"messages": [{"role": "user", "content": ENCARGO}]},
24 config={"configurable": {"thread_id": "encargo-007"}},
25 )La métrica de re-trabajo se cuenta sobre la traza Langfuse, no a ojo. Recuerda el CallbackHandler de N0:
1# Instrumentar el run para contar el re-trabajo sobre la traza (corpus F.7)
2from langfuse.langchain import CallbackHandler
3
4handler = CallbackHandler()
5result = graph.invoke(
6 {"messages": [{"role": "user", "content": ENCARGO}]},
7 config={"configurable": {"thread_id": "encargo-007"}, "callbacks": [handler]},
8)
9# Re-trabajo = búsquedas repetidas + documentos releídos + secciones reescritas,
10# contados sobre los tool calls de la traza antes y después del kill.Elaborative interrogation — antes de correr la demo, predice: si reanudas el encargo como un thread nuevo (solo notas + store, sin pasar el thread_id viejo al checkpointer), ¿qué pierdes y qué conservas?
Comprueba tu predicción
Conservas dos cosas: las notas del encargo (si las escribiste en un store o archivo no atado al thread, recuperables por id de encargo) te devuelven estado, decisiones y pendientes; y el Store te devuelve los veredictos de fuentes, porque es cross-thread por diseño. Eso ya evita re-buscar y re-aprender.
Pierdes el estado interno del grafo: el turno exacto, el mensaje a medio formar, la posición precisa en el loop. Eso solo lo repone el checkpointer con el mismo thread_id. · fuente: corpus C.1 (checkpointer = continuidad de sesión; Store = continuidad de la relación) + F.1.
La lección de la variante: las tres piezas cubren scopes distintos y no son intercambiables. Las notas y el store te dan continuidad del trabajo y de lo aprendido; solo el checkpointer te da continuidad del estado de ejecución. Un diseño que solo guarda notas sobrevive al reinicio con re-trabajo bajo —pero no nulo—, porque reconstruye el estado del grafo desde la nota en vez de reponerlo.
Feedback: si predijiste que pierdes todo, revisa: el store es cross-thread por construcción y no se entera del cambio de thread. Si predijiste que no pierdes nada, revisa qué repone exactamente el checkpointer en L4 —el estado del grafo no vive en las notas—.
6.7Mastery gate: la rúbrica C2
Este es el gate. Tu entregable se juzga con las cinco dimensiones, cada una con feedback formativo: fortaleza específica, brecha concreta, siguiente paso.
Usa esta lista para auto-evaluarte antes de entregar. Sé tan duro contigo como fuiste con el entregado de 6.5.
- Dim 1 — Note-taking. ¿Pegaste una nota real con sus tres campos? ¿La demo prueba que retoma sin releer el historial? Si tu nota crece turno a turno, es diario: sobrescribe el estado, no apiles historia.
- Dim 2 — Store con políticas. ¿Tienes la tabla write/select con las cinco columnas? ¿Justificas hot path vs background para cada entrada? Si tu política es "guarda lo que decida guardar", no tienes política: tienes un vertedero.
- Dim 3 — Supervivencia. ¿Tu tabla de re-trabajo contrasta serie contra memoria con números sobre traza? ¿El re-trabajo cae sin re-inyectar el historial? Si reanudas volcando todo el historial al contexto, es re-trabajo encubierto.
- Dim 4 — Trade-off. ¿Mostraste tokens, latencia y calidad contra full-context a las cuatro longitudes del sweep? ¿Se ve el codo? Si solo narras "ahorra tokens", falta el dato.
- Dim 5 — Riesgo. ¿Plantaste el escenario, lo probaste en la traza y aplicaste la mitigación? ¿Verificaste que el
selectya no sirve la entrada contaminada? Si solo describes el riesgo, la dimensión cae.
El orden de ataque, una vez más, porque importa cuando aprieta el tiempo. Primero 1→2 (la arquitectura y su supervivencia), luego 3 (medir el trade-off vs full-context), luego 4 (auditar el riesgo), al final 5 (la conclusión). Es el primer checkpoint del curso con cinco dimensiones obligatorias en espíritu; intentarlas en paralelo bloquea. En secuencia, cada una se apoya en la anterior.
Una nota sobre el listón. Aprobar C2 no es tener las cinco perfectas. Es que ninguna esté tumbada por su error típico: ninguna nota-diario, ninguna política implícita, ninguna supervivencia encubierta, ningún trade-off sin tabla, ninguna auditoría sin escenario probado. Esa es la diferencia entre "lo conté" y "lo demostré".
6.8Conecta
Cierra el arco que abrimos en L1. Allí el kill borraba todo: estado del grafo, plan, fuentes evaluadas. Magallanes re-trabajaba el encargo desde cero. Hoy ese mismo kill es un evento rutinario que tu agente absorbe —deploy, OOM, rotación de pods, da igual—.
La curva del sweep de N0 tiene ahora una columna nueva: "con memoria". Por primera vez en el curso, Magallanes mejora entre sesiones, no solo dentro de una. La compaction de N1 salvaba el run; la memoria de N2 salva lo aprendido a través de los runs. Son la misma política de preservación en dos scopes distintos.
Acabas de demostrar lo que ningún benchmark público te da. LOCOMO mide productos de vendor; tu tabla de re-trabajo mide tu agente con tus tools sobre tu corpus. La disputa Mem0↔Zep sigue abierta a junio de 2026, sin réplica independiente —y tu kill-test vale más para tu decisión que cualquier porcentaje de ese debate—. · fuente: corpus C.5 (disputa LOCOMO sin réplica independiente).
Y abre N3 (/cursos/context-engineering/tools-y-jit). La palanca write de Lance Martin está dominada: Magallanes escribe fuera de la ventana y lo recupera cuando hace falta. · fuente: corpus B.2. El siguiente cuello de botella es select: qué metes en el contexto y cuándo. El lab de N3 inflará a Magallanes con 40 tools redundantes y conocimiento precargado, y tocará adelgazarlo —retrieval just-in-time en vez de cargarlo todo por si acaso—.
6.9Reflexiona
Tómate un minuto. Escribir esto consolida más que releer.
- ¿Qué aprendiste? Resume en una frase por qué "mi agente tiene memoria" no es un claim y "aquí está la tabla de re-trabajo tras el kill" sí lo es.
- ¿Qué sigue sin estar claro? ¿Distingues lo que repone el checkpointer de lo que conservan las notas y el store? Si no, vuelve a 6.6 y a L4.
- ¿Qué harías distinto? La próxima vez que alguien te diga "mi agente recuerda entre sesiones", ¿qué tres preguntas le harías antes de creerlo?
Esto requiere práctica. La intuición de "qué scope cubre qué pieza" llega montando y matando agentes, no leyendo sobre ellos. El entregable de C2 es esa práctica hecha gate. Lo que demuestras hoy es lo que en producción te ahorra explicar un re-trabajo de horas a las tres de la mañana.