Sobrevivir al reinicio

4.1El problema

Activas el flag del lab. A mitad de un encargo de unos 35 turnos, en el turno 18, el proceso muere. Un OOM-kill, un deploy, una rotación de pods: en producción da igual la causa. El encargo iba por la mitad.

Relanzas el Magallanes de serie. Y empieza otra vez desde cero. Repite 9 búsquedas que ya había hecho. Relee 6 documentos que ya había leído. Reescribe 2 secciones que ya había cerrado. No es un bug del modelo: es que no quedó nada del run anterior. El estado del grafo vivía en memoria del proceso, y el proceso murió.

Has construido tres piezas para este momento exacto. En L2 le diste a Magallanes sus notas del encargo. En L3 le montaste un Store con políticas para lo que sobrevive entre encargos. Hoy las sometes a la prueba de fuego del nivel: el kill. La pregunta no es si funcionan por separado. Es si, juntas, hacen que el reinicio sea un no-evento.

Y hay una segunda mitad incómoda. Ese Store que llenaste con veredictos de fuentes es ahora algo que un atacante puede contaminar. La memoria que te ahorra trabajo también es la memoria que te puede traicionar. Las dos caras se auditan hoy.

4.2Qué vas a poder hacer

Al terminar serás capaz de:

• Migrar el checkpointer de Magallanes de InMemorySaver a PostgresSaver y reanudar un encargo tras un kill con el mismo thread_id.
• Medir el re-trabajo tras el reinicio sobre la traza Langfuse: búsquedas repetidas, documentos releídos, secciones reescritas.
• Distinguir una supervivencia real de una que re-inyecta el historial entero —re-trabajo encubierto pagado en tokens.
• Auditar un escenario de memory poisoning sobre tu Store y aplicar una mitigación con justificación.

Necesitas saber antes:

• De N2·L1 (/cursos/context-engineering/memoria/la-memoria-es-arquitectura): short-term (checkpointer, thread-scoped) vs long-term (Store, cross-thread). Lo recuperamos en 4.3.
• De N2·L2 (/cursos/context-engineering/memoria/note-taking-estructurado): la estructura de tus notas y por qué sobreviven a una compaction.
• De N2·L3 (/cursos/context-engineering/memoria/el-store-externo): tu política de write/select y la lista de qué NO guardar.
• Del nivel /cursos/context-engineering/palancas-y-compaction: que tu compaction preserva estado, decisiones y problemas abiertos dentro del hilo.

4.3Recupera

Antes de seguir, responde de memoria. Esto reactiva las tres piezas y engancha el kill que viene.

1. Tras el kill, ¿qué pieza repone el estado del grafo y qué papel juega el thread_id al reanudar?
2. ¿Qué pieza le devuelve el plan y los pendientes sin releer todo el historial?
3. ¿Qué pieza conserva lo aprendido si el encargo se relanza como thread nuevo?
4. Una de las tres NO sobrevive con InMemorySaver. ¿Cuál y por qué?

4.4El concepto

El reinicio como test de integración

Hasta aquí probaste cada pieza por separado. El reinicio las prueba juntas. Es un test de integración de tu arquitectura de memoria, no un test de unidad. La avería del nivel —el kill a mitad de encargo— es la entrada; el re-trabajo medido es la salida.

Tres piezas responden a tres preguntas distintas tras el kill.

Pieza 1 — reanudar el hilo. El checkpointer repone el estado del grafo. Con InMemorySaver, ese estado vive en memoria del proceso y muere con él. Por eso el lab migra de backend a PostgresSaver: persiste el checkpoint en Postgres. Al reanudar con el MISMO thread_id, el grafo vuelve a donde estaba. · fuente: corpus F.1 + api-nivel2.

Pieza 2 — retomar el trabajo. El checkpointer repone el grafo, pero el grafo no es el plan. leer_notas devuelve estado, decisiones y pendientes sin releer el historial. Sabe qué subtemas cerró y cuáles faltan. · fuente: N2·L2.

Pieza 3 — no re-aprender. Si el encargo se relanza como thread nuevo, el checkpointer no ayuda: es de otro hilo. El Store sí, porque es cross-thread. Devuelve los veredictos de fuentes que destilaste. Magallanes no re-evalúa lo que ya juzgó. · fuente: corpus F.1.

Compaction y memoria son la misma política en dos scopes

Aquí está la idea que une este nivel con el anterior. La compaction comprime el historial dentro del hilo; la memoria persiste lo crítico fuera de él. No son rivales: son la misma política de preservación aplicada a dos scopes distintos.

La memoria persiste lo crítico a través de los límites de la compaction. · fuente: corpus C.3 + B.4. Cada vez que la compaction comprime, lo que merecía sobrevivir ya está en las notas o en el Store. La compaction sin memoria pierde entre sesiones; la memoria sin compaction desborda dentro de ellas.

La analogía: un investigador que pasa a limpio sus apuntes al cerrar el día (compaction) y guarda las conclusiones en un archivador (memoria). Dónde falla la analogía: el archivador físico no se contamina solo; tu Store sí puede recibir entradas envenenadas —segunda mitad de la lección.

La métrica del nivel: re-trabajo

"Sobrevive" no es una sensación. Es un número. El re-trabajo es el trabajo que el agente repite tras el reinicio porque perdió el rastro de lo ya hecho. Se cuenta sobre la traza, no a ojo:

• búsquedas repetidas — buscar(query) con una query ya lanzada antes del kill.
• documentos releídos — leer(doc_id) sobre un doc_id ya leído.
• secciones reescritas — escribir_seccion(titulo, ...) sobre un título ya cerrado.

La traza Langfuse del run antes y después del kill da las cuentas. · fuente: corpus F.7. El Magallanes de serie da re-trabajo casi total; el Magallanes con arquitectura, cercano a cero.

Contraejemplo: el reinicio que re-inyecta el historial

Cuidado con esta trampa, porque parece supervivencia y no lo es. Un reinicio que "funciona" volviendo a meter el historial completo en el contexto NO es supervivencia. Es re-trabajo encubierto, pagado en tokens en vez de en tool calls.

El loop ReAct es append-only: el historial crece sin techo si nadie lo gestiona. · fuente: corpus A.6 (ACON). Reanudar re-inyectando todo el historial te devuelve al problema que la memoria venía a resolver. El trade-off de la dimensión 4 de la rúbrica lo destapa: cuesta más tokens y más latencia que retomar desde las notas.

La cara oscura: memory poisoning

Tu Store ya no es solo una optimización. Es una superficie de ataque. El memory poisoning es la inyección de contenido malicioso en la memoria del agente. El agente actúa sobre él más tarde, cuando el atacante ya no está presente.

El vector clásico: el agente lee contenido malicioso —un README manipulado—, guarda un resumen en memoria, y luego actúa sobre la memoria contaminada. · fuente: corpus C.7. La separación temporal lo hace peligroso: el ataque y su efecto no coinciden en el tiempo. La auditoría del momento del ataque puede no ver nada raro.

La evidencia académica: MINJA (arXiv:2503.03704, mar 2025) demuestra que se pueden inyectar memorias maliciosas solo mediante queries, sin acceso directo al store. El ISR supera el 90% en la mayoría de configuraciones del paper. · fuente: corpus C.7. Es común suponer que envenenar la memoria exige acceso al backend; MINJA muestra que no.

Las defensas convergen en cuatro familias (corpus C.7). Proveniencia / trust scores: de dónde viene cada entrada y cuánto fiarse. Particionado por scope: aislar namespaces. Decay temporal: caducar lo viejo. Monitorizar drift: detectar cuándo el agente exhibe comportamiento anómalo. Hoy aplicas la primera.

4.5Míralo funcionar

El lab tiene dos actos. Acto 1: supervivencia. Acto 2: auditoría de poisoning. Es código con varias piezas; lee cada bloque entero una vez antes de la explicación línea a línea. Lo difícil no es ninguna línea suelta, es ver cómo el thread_id cose el run partido.

Acto 1 — migrar el checkpointer a Postgres

El cambio que hace posible la supervivencia es de una línea conceptual: cambiar InMemorySaver por PostgresSaver. Las firmas salen de F.1 y de api-nivel2.

1# magallanes_n2.py — supervivencia: el checkpointer persistente
2from langgraph.graph import StateGraph, MessagesState
3from langgraph.checkpoint.postgres import PostgresSaver   # persistente: sobrevive al kill
4from langgraph.store.postgres import PostgresStore        # cross-thread, también persistente
5
6DB_URI = "postgresql://postgres:postgres@localhost:5432/graticula"
7
8# El checkpointer va como context manager. setup() crea las tablas (idempotente).
9with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
10    checkpointer.setup()
11    with PostgresStore.from_conn_string(DB_URI) as store:
12        store.setup()
13
14        builder = StateGraph(MessagesState)
15        # ... nodos del grafo congelado: las 3 tools + leer_notas/escribir_notas ...
16        graph = builder.compile(checkpointer=checkpointer, store=store)
17
18        # Lanzar el encargo. El thread_id identifica este hilo.
19        graph.invoke(
20            {"messages": [{"role": "user", "content": ENCARGO}]},
21            config={"configurable": {"thread_id": "encargo-007"}},
22        )
23        # ... el flag del lab mata el proceso en el turno 18 ...

Tres cosas de este bloque:

• PostgresSaver.from_conn_string(DB_URI) abre el checkpointer como context manager. setup() crea las tablas la primera vez y no hace nada las siguientes —es idempotente. · fuente: corpus F.1 + api-nivel2.
• InMemorySaver no aparece. Guarda en memoria del proceso; el kill se lo lleva. Postgres es el backend que sobrevive.
• El thread_id ("encargo-007") es la clave del hilo. Lo necesitas igual al reanudar.

Acto 1 — reanudar tras el kill

El proceso murió en el turno 18. Relanzas. Invocas con el MISMO thread_id: el checkpointer restaura el estado del último checkpoint y el grafo retoma desde ahí.

1# reanudar.py — mismo thread_id → el checkpointer repone el estado del grafo
2with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
3    with PostgresStore.from_conn_string(DB_URI) as store:
4        graph = builder.compile(checkpointer=checkpointer, store=store)
5
6        # MISMO thread_id: el checkpointer restaura el estado del último checkpoint.
7        graph.invoke(
8            {"messages": [{"role": "user", "content": ENCARGO}]},
9            config={"configurable": {"thread_id": "encargo-007"}},
10        )
11        # Magallanes retoma desde donde quedó; leer_notas da el plan; el Store, los veredictos.

No se pasa un nuevo encargo porque el checkpointer restaura el estado del grafo; el thread_id es el identificador del hilo guardado. El modelo recibe el contexto completo del checkpoint, no el historial entero: eso es exactamente la diferencia con el full-context del ejercicio 1.

Mira el detalle que importa: el thread_id es idéntico al del lanzamiento. Ese string es lo único que conecta el run partido. Cámbialo y el checkpointer no encontrará el hilo: arrancaría de cero, como el Magallanes de serie.

Acto 1 — la tabla de re-trabajo

Cuentas el re-trabajo sobre la traza Langfuse del run reanudado: cuántas búsquedas, lecturas y escrituras repiten algo de antes del kill. · fuente: corpus F.7. Estos números son ilustrativos; tu run dará los suyos. Lo que importa es la diferencia entre las dos configuraciones.

re-trabajo tras el kill (turno 18 de ~35)
configuración                          | búsquedas rep. | docs releídos | secciones reesc.
---------------------------------------+----------------+---------------+-----------------
Magallanes de serie (InMemorySaver)    |       9        |       6       |        2
Magallanes con PostgresSaver + notas   |       0        |       0       |        0
  + Store

Lee la diferencia, no los dígitos exactos. El de serie repite casi todo: perdió el estado del grafo, el plan y los veredictos. El de arquitectura retoma limpio. Esa fila inferior es lo que la rúbrica C2 llama supervivencia demostrada.

Acto 1 — la variante: thread nuevo sin checkpointer

Hay un tercer caso que distingue qué pieza hace qué. Reanudas como thread NUEVO: sin checkpointer del hilo viejo, solo con notas y Store.

1# Variante: thread_id NUEVO. El checkpointer no repone nada de "encargo-007".
2graph.invoke(
3    {"messages": [{"role": "user", "content": ENCARGO}]},
4    config={"configurable": {"thread_id": "encargo-007-bis"}},
5)
6# leer_notas SÍ devuelve el plan (las notas no dependen del thread).
7# El Store SÍ devuelve los veredictos (es cross-thread).
8# Lo que se PIERDE: el estado fino del grafo (el tool call a medio ejecutar al morir).

Esto separa los scopes. Las notas y el Store son cross-thread: sobreviven aunque cambies el thread_id. El estado fino del grafo —el paso exacto donde estaba— es thread-scoped: solo el checkpointer con el mismo thread_id lo repone. Por eso el diseño completo usa las tres piezas.

Acto 2 — plantar el veneno

Ahora la auditoría. Plantas a mano una entrada contaminada en el Store, como si un README malicioso hubiera colado un veredicto falso. Las firmas de Store salen de F.1 y api-nivel2.

1# auditoria_poisoning.py — plantar una entrada envenenada y ver si el select la sirve
2ns = ("magallanes", "fuentes", "tema-x")
3
4# Entrada envenenada: marca como "fiable" un documento con un dato falso plantado.
5store.put(ns, "doc-099", {
6    "doc_id": "doc-099",
7    "veredicto": "fiable",
8    "resumen_1_linea": "Confirma el dato X (plantado, falso).",
9})
10
11# Al abrir un encargo del tema, el select la devuelve junto a las legítimas.
12hits = store.search(ns, query="dato X", limit=5)
13for h in hits:
14    print(h.value["doc_id"], h.value["veredicto"])
15# Magallanes lee "doc-099 / fiable" y la usa SIN re-verificar. El atacante ya no está.

Observa en la traza cómo search sirve la entrada envenenada como contexto y Magallanes actúa sobre ella sin re-verificar. No hay nada en la entrada que la distinga de una legítima. Ese es exactamente el escenario MINJA en miniatura: la memoria contaminada actúa cuando el atacante ya se fue. · fuente: corpus C.7.

Acto 2 — la mitigación: proveniencia en el select

Aplicas la primera defensa de C.7: un campo de proveniencia en cada entrada. Y un filtro en el select que solo admite entradas de confianza.

1# Cada entrada lleva su proveniencia: cómo se ganó la confianza.
2store.put(ns, "doc-014", {
3    "doc_id": "doc-014",
4    "veredicto": "fiable",
5    "resumen_1_linea": "Fuente primaria, verificada en 2 encargos.",
6    "proveniencia": "verificada",     # vs "sin_verificar" | "externa"
7    "encargos_confirmada": 2,
8})
9
10# El select filtra: solo entradas verificadas en ≥1 encargo previo.
11hits = store.search(ns, query="dato X", limit=5,
12                    filter={"proveniencia": "verificada"})
13# La entrada "doc-099" (sin proveniencia verificada) ya no se sirve.

Razónalo antes de leer

Antes de leer la respuesta, intenta tú: ¿por qué la mitigación va en el select y no solo en el write?

4.6Hazlo tú

Andamiaje decreciente: mides el trade-off, pruebas una segunda mitigación y, sin guía, auditas tu propia política.

Ejercicio 1 — el trade-off vs full-context (dim 4)

Re-ejecuta el sweep baseline de N0 (/cursos/context-engineering/diagnostico/el-context-sweep) en dos modos sobre el mismo encargo multi-sesión:

1. Magallanes con memoria — notas + Store, retomando tras el kill.
2. Full-context — todo el historial re-inyectado en el contexto al reanudar, sin memoria.

Mide tokens, latencia y calidad en una tabla. El esqueleto del sweep ya lo tienes de C0; aquí añades la columna "con memoria". Edita el promptfooconfig.yaml del sweep (ver F.8 / starter kit de N0) para añadir la condición de memoria. · fuente: api-nivel2 F.8.

Antes de ejecutar, predice: ¿qué modo gastará más tokens al reanudar, y por qué la calidad puede no compensar la diferencia?

Ejercicio 2 — una segunda mitigación

Sobre el escenario plantado del 4.5, diseña y prueba una mitigación distinta de la proveniencia. Opción A: decay temporal (caducar entradas viejas). Opción B: scoping por namespace (aislar lo no verificado aparte). · fuente: corpus C.7. Demuestra con la traza que la entrada doc-099 deja de servirse.

Pista: el Store admite expiración por entrada vía el parámetro ttl de put (segundos; None = sin expiración). · fuente: api-nivel2 (BaseStore.put). Para scoping, usa un namespace ("magallanes", "fuentes", "cuarentena") y excluye ese prefijo del select.

Ejercicio 3 — sin andamiaje: audita tu política de L3

Coge la política de write/select que escribiste en N2·L3. Audítala contra el poisoning:

• ¿Qué entrada envenenada pasaría tu write? Construye una que tu regla aprobaría.
• ¿Qué devolvería tu select si esa entrada estuviera dentro?
• ¿Qué regla nueva la habría detenido?

No hay solución cerrada. Reutiliza el patrón del 4.5.

Normaliza el error: es común que el primer intento de reanudación duplique el último tool call que estaba en curso al morir. Revisa qué quedó a medias en el estado del grafo antes de culpar al checkpointer. El checkpointer repone lo que guardó; si un tool call se cortó a mitad, el estado refleja ese corte.

4.7Comprueba

Sin pistas. Gate de maestría: una checklist de supervivencia sobre un diseño ajeno.

Un compañero te pasa este diseño de agente con memoria para validar. Tiene tres huecos que lo hunden en el kill y en el poisoning. Encuéntralos y corrígelos.

Diseño del compañero:
- Checkpointer: InMemorySaver.
- Notas: un archivo append-only donde el agente añade "hice X, luego Y" cada turno.
- Store: store.put(ns, doc_id, {"doc_id": ..., "veredicto": ...}) sin más campos.
  Select: store.search(ns, query=encargo, limit=20).

1. Predice qué pierde en el kill del turno 18 y cuánto re-trabajo genera.
2. Identifica qué entrada envenenada pasaría su select.
3. Corrige cada hueco.

4.8Conecta

Acabas de ejecutar tres dimensiones de la rúbrica C2 de una vez. La dim 3 (supervivencia demostrada): la tabla de re-trabajo a cero. La dim 4 (trade-off medido): la comparativa vs full-context con números. La dim 5 (riesgo auditado): el escenario de poisoning probado y la mitigación aplicada.

El gate del nivel (L6) las pedirá juntas y documentadas, sobre tu Magallanes completo. Hoy las corriste por separado; allí las integras en un solo entregable.

Y mira lo que pasó con la curva del sweep. En N0 medía a Magallanes dentro de una sesión. Hoy le añadiste una columna nueva: "con memoria, tras el kill". Es la primera vez en el curso que Magallanes mejora entre sesiones, no solo dentro de una. El kill que en 4.1 le borraba todo es ahora un evento rutinario que absorbe.

Cierra el arco que abrimos en 4.1. Tenías un agente que, al morir el proceso, re-trabajaba el encargo entero. Ahora tienes una tabla de re-trabajo a cero, con thread_id y seed fijos, y un Store que filtra el veneno antes de servirlo. El seed es la semilla aleatoria fijada para reproducibilidad del modelo. La avería del nivel está vencida y medida.

Antes de cerrar, una pregunta legítima: ¿no hay un framework que dé todo esto hecho —MemGPT, Mem0, Zep? L5 los lee con lupa, con sus benchmarks de vendor y la disputa LOCOMO como caso de estudio. La misma lupa crítica que ya aplicaste a los benchmarks de modelos en N0·L1 (/cursos/context-engineering/diagnostico/el-mito-de-la-ventana-infinita).

4.9Reflexiona

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

• ¿Qué aprendiste? Resume en una frase por qué un reinicio que re-inyecta el historial no es supervivencia.
• ¿Qué sigue sin estar claro? ¿Tienes clara la diferencia entre lo que repone el checkpointer (estado del grafo, thread-scoped) y lo que aportan notas y Store (cross-thread)? Si no, vuelve a 4.4, las tres piezas.
• ¿Qué harías distinto? La próxima vez que alguien diga "mi agente sobrevive a un reinicio", ¿qué dos preguntas le harías antes de aceptarlo? (Pista: una sobre el re-trabajo medido, otra sobre el poisoning del store.)

Esto requiere práctica. La intuición de "qué pieza repone qué" llega matando procesos y leyendo trazas, no leyendo la teoría. En L6 reúnes este reinicio, el trade-off y la auditoría en el entregable del checkpoint C2.