Sliding Window y Vague Fría : cuando el contexto del agente explota y hay que archivar sin perder

Publicado el 26 April 2026

Resumen

Después de 48 sesiones en un solo proyecto y 150+ en total, el sistema de gobernanza Eager/Lazy que había construido con cuidado empezaba a ahogarse. Los archivos de agentes, supuestos de ser ligeros, pesaban 5200 líneas acumuladas. El contexto auto-cargado aumentaba más rápido que mi capacidad para controlarlo. Este artículo cuenta cómo conceptualicé un mecanismo de respaldo — entre ventana deslizante y ola fría idéntica — para mantener un contexto activo ligero sin perder nada.

Señal: 5200 Líneas

Estoy en plena sesión 048 sobre`magic-stick`, mi proyecto de construcción de ISO Linux en vivo. Opencode me observa. Como siempre, ha cargado automáticamente mis archivos Eager al comienzo de la sesión —AGENT.adoc, PROMPT_REPRISE.adoc, .agents/INDEX.adoc. Nada anormal

Pero algo no cuadra. Las respuestas son más lentas. El razonamiento es más difuso. El agente olvida detalles que tenía a la vista hace dos mensajes.

Abro una terminal y tecleo :

wc -l .agents/INDEX.adoc .agents/SESSIONS_HISTORY.adoc \
  .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc

260 líneas para INDEX. 55 para SESSIONS_HISTORY.1756 para COMPLETED_TASKS_ARCHIVE.

El dossier`sessions/`ajoute aún ~3200 líneas. Total:5200 líneasde contexto que se cargan, de una manera u otra, en el cerebro temporal del agente

La estrategia Eager/Lazy que había teorizado en el artículo anterior funciona — pero tiene un defecto de nacimiento que no había anticipado: no tieneno hay mecanismo de envejecimiento. Cada sesión agrega una línea a INDEX, un párrafo a COMPLETED_TASKS, un archivo en sessions/. Nunca sale nada. El contexto es una bola de nieve que crece con cada nueva sesión.

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false

title Crecimiento del Contexto del Agente — Sesiones 1 a 48
rectangle "Sesión 1-10" as S10 #E8F5E9
rectangle "Sesión 11-20" as S20 #C8E6C9
rectangle "Sesión 21-30" as S30 #A5D6A7
rectangle "Sesión 31-40" as S40 #81C784
rectangle "Sesión 41-48" as S48 #66BB6A

note right of S10
INDEX : ~50 líneas
SESSIONS : ~10 líneas
ARCHIVE : ~100 líneas
**Total : ~300 líneas**
end note

note right of S20
INDEX : ~100 líneas
SESSIONS : ~20 líneas
ARCHIVE : ~400 líneas
**Total : ~800 líneas**
end note

note right of S30
INDEX : ~160 líneas
SESSIONS : ~30 líneas
ARCHIVE : ~900 líneas
**Total : ~1800 líneas**
end note

note right of S40
  INDEX : ~220 lignes
  SESSIONS : ~45 lignes
  ARCHIVE : ~1400 lignes
  **Total : ~3200 lignes**
end note

note right of S48
INDEX : **260 líneas**
SESSIONS : **55 líneas**
ARCHIVE : **1756 líneas**
**Total : 5200 líneas** ⚠️
end note

S10 -[#green]-> S20
S20 -[#green]-> S30
S30 -[#FF9800]-> S40
S40 -[#red]-> S48

@enduml

No es un error, es una consecuencia directa del procedimiento de finalización de sesión que archiva meticulosamente cada detalle. El sistema es víctima de su propio éxito.

El Diagnóstico: Triple Redundancia

Le pido al agente que diagnostique el problema. Su respuesta es inmediata y quirúrgica.

Archivo

Líneas

rol

problema

.agents/INDEX.adoc

260+

EAGER (cargado automático)

Tabla de todas las sesiones desde la 001 —+1 línea por sesión

.agents/SESSIONS_HISTORY.adoc

55

EAGER

Tabla resumen —redundancia con INDEX

COMPLETED_TASKS_ARCHIVE_2026-04.adoc

1756

EAGER (implícito)

Detalles completos de todas las sesiones de abril

.agents/sessions/*.adoc

[No French text was provided for translation, so no output is generated per instructions.]

PEREZOSO (supuesto)

Archivos individuales, perono utilizadasPorque todo ya está en COMPLETED_TASKS

El agente identifica cuatro causas raíz:

  1. COMPLETED_TASKS_ARCHIVE absorbe todo— En lugar de apuntar a los archivos`.sessions/`, copia íntegramente cada sesión.

  2. INDEX.adoc cumple la función de un historial completo— La tabla "Sesiones Recientes" contiene 30+ entradas.

  3. SESSIONS_HISTORY.adoc redundante— Misma info que INDEX, formato diferente.

  4. La regla LAZY no se cumple— COMPLETED_TASKS es implícitamente EAGER porque contiene todo.

Su propuesta es radical: limitar INDEX a 10 sesiones, vaciar COMPLETED_TASKS, mover SESSIONS_HISTORY a LAZY puro. Ganancia inmediata :~1900 líneas ahorradas.

Es limpio, eficiente, lógico. Pero tengo un problema con este enfoque.

¿Por qué rechacé la solución evidente?

La solución del agente es la de un ingeniero que optimiza una caché. Limitar. Truncar. Eliminar las redundancias.

Pero estas "redundancias" no lo son. Cada archivo de gobernanza captura unángulo diferentesobre la misma realidad :

  • ÍNDICE= vista macro, tablero ejecutivo

  • HISTORIAL_DE_SESIONES= tabla cronológica lineal, puntuada

  • ARCHIVO_DE_TAREAS_COMPLETADAS= narrativa detallada con métricas

  • sessions/*.adoc" = archivos individuales, contexto completo

No es una duplicación tonta. Es de laperspectiva múltiple estructurada. Es exactamente lo que necesitamos para destilar — para que más tarde, un humano (o un LLM futuro mejor entrenado) pueda cruzar los ángulos y extraer patrones.

Imagina a un científico de datos que te dice: «Eliminemos 3 columnas de 6, están correlacionadas». ¿Qué le respondes? Que la correlación no es redundancia cuando cada columna captura una dimensión diferente del mismo fenómeno. Que es precisamente esta riqueza dimensional la que hace que el conjunto de datos sea explotable.

Es mi intuición. Y la defiendo contra la racionalidad fría del agente.

__ No veo un saco de todo silencioso en mi idea. No rellenamos todo, desplazamos el resultado estructurado del procedimiento de fin de sesión — cada archivo con su ángulo, sus redundancias que en realidad son un enriquecimiento. Es este material multidimensional que será mejor para la destilación. (blank)

El agente encaja el golpe. Y se corrige.

La Proposición : Onda Fría Idéntica

Entonces el agente propone un mecanismo más fino, que respeta mi intuición de conjunto de datos rico mientras resuelve el problema técnico del contexto que explota.

El principio es simple y se inspira directamente del patrónAlmacenamiento en caliente/tibio/fríoaplicado a la gestión de archivos:

  • Caliente (ANSIO)= las 10 sesiones más recientes en INDEX, PROMPT_REPRISE de la sesión N+1, los 2 últimos archivos de sesión

  • Cálido (PEREZOSO)= SESSIONS_HISTORY reciente, SCRIPT_VERIFICATION, toda la documentación de referencia

  • frío (copia/)= todo lo demás, desplazadointacto, sin transformación, sin reindexación

----
----
----
----
----
----
.agents/
├── INDEX.adoc                         → Sessions N-9 à N (10 dernières)
├── SESSIONS_HISTORY.adoc              → Sessions N-9 à N
├── SCRIPT_VERIFICATION.adoc           → Dernière vérif (pas d'historique)
├── PROMPT_REPRISE.adoc                → Session N+1 uniquement
├── sessions/                          → Sessions N-1 à N uniquement
└── backup/
    └── Y2026-sessions-001-039/          ← Vague froide, COPIE INTÉGRALE
        ├── INDEX.adoc                  → Sessions 001 à 039 (complet)
        ├── SESSIONS_HISTORY.adoc       → Sessions 001 à 039 (complet)
        ├── COMPLETED_TASKS_ARCHIVE.adoc → Sessions 001 à 039 (complet)
        └── sessions/                   → 001.adoc, 002.adoc...
----

La clave del mecanismo:**La copia de seguridad no es un índice central, es una copia fiel de la ola pasada**. Cuando se supera el horizonte de las 10 sesiones activas, no se elimina nada. No se reindexa nada. No se fusiona nada. Se toma el paquete de archivos de agentes tal como estaba en la sesión N-10, y se mueve a`backup/`.

Los archivos activos, por su parte, están truncados:

* INDEX : solo las últimas 10 líneas (ventana deslizante)
* SESSIONS_HISTORY : lo mismo
* COMPLETED_TASKS_ARCHIVE : nuevo archivo para el período en curso
* sessions/ : únicamente las 2 últimas sesiones

[plantuml, format=svg, id=diag-hot-warm-cold, alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Arquitectura Hot / Warm / Cold del Agente de Contexto
package "HOT (EAGER)\nCargado automáticamente\n~300 líneas" as HOT #FFCDD2 {
  file "INDEX.adoc\n(10 sesiones)" as IDX_HOT
  file "PROMPT_REPRISE\n(sesión N+1)" as PRO_HOT
  file "AGENT.adoc\n(reglas absolutas)" as AG_HOT
}

package "WARM (LAZY)\nCargado bajo demanda\n~500 líneas" as WARM #FFF9C4 {
  file "SESSIONS_HISTORY\n(10 últimos)" as HIS_WARM
  file "SCRIPT_VERIFICATION\n(última)" as VER_WARM
  file "PROCEDURES.adoc\n(templates)" as PRO_WARM
  file "*_REFERENCE.adoc\n(documento técnico)" as REF_WARM
}

package "COLD (backup/)\nNunca cargado\nSólo lectura humana" as COLD #BBDEFB {
  folder "Y2026-001-039/" as WAVE {
    file "ÍNDICE (completo)" as IDX_COLD
    file "SESSIONS_HISTORY\n(completo)" as HIS_COLD
    file "COMPLETED_TASKS\n(completado)" as ARCH_COLD
    folder "sesiones/ (001-039)" as SESS_COLD
  }
  folder "Y2026-040-???\n(futuro)" as FUTURE
}

HOT --> WARM : "Agente sube\nsi es necesario"
WARM --> COLD : "Nunca automático\nEl ser humano va allí solo"

note bottom of COLD
  Règle : COPIE INTÉGRALE
  Pas de transformation
  Pas de réindexation
  Read-only après archivage
end note

@enduml
----

El beneficio inmediato es masivo: el contexto EAGER pasa de**~5200 líneas a ~300 líneas**. Una división por 17. Sin haber perdido una sola línea de datos históricos.

== ¿Por qué no es un cajón de sastre?

El agente, en su primera iteración, temía que`backup/`Se convierta en una caja negra — una carpeta donde se archivan documentos que nunca volveremos a leer. Es un temor legítimo. Pero descansa sobre un error de concepto.

Un cajón de sastre es cuando se tiran archivos.**sin estructura, sin convención, sin lógica de agrupación**. Aquí, el backup está estructurado por período (Y2026-001-039), y cada carpeta de backup contiene**la misma estructura**que el expediente`.agents/`activo: INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/

No es un cajón de sastre. Es un**instantánea horodatada**. Se podría incluso decir que es un mecanismo de versionado simplificado — con la salvedad de que no versiona los archivos individualmente, sino el paquete completo de la gobernanza en un momento dado.

Cuando quieras recuperar una información antigua, no necesitas un índice central. Tienes dos opciones:

1. **grep` dirigido**:`grep -r "zsh" backup/Y2026-001-039/`— y encuentras todo lo que menciona zsh en el período, sin importar el ángulo (INDEX, SESSIONS_HISTORY, archivo de sesión).
2. **Reintegración manual**: copias temporariamente la carpeta de backup en el contexto activo, y le pides al agente que analice este período específico.

El índice es implícito. Está en la misma estructura de los archivos — cada uno ya siendo un índice desde su propio ángulo.

== La metáfora de las estanterías

Para hacer el mecanismo intuitivo, lo he conceptualizado en tres estantes :

* **Estantería 1 (EAGER)**— el plan de trabajo. Lo que necesito *ahora*. INDEX reciente, PROMPT_REPRISE, reglas absolutas. Ligero, inmediato, crítico.
* **Estantería 2 (LAZY)**— la biblioteca de consulta. Lo que puedo buscar bajo petición. Referencias técnicas, historial reciente, procedimientos. Más voluminoso, pero no cargado en memoria.
* **Bodega (backup/)**— los archivos fríos. Todo lo que ha pasado pero que no quiero desechar. El agente nunca entra allí. El ser humano baja cuando quiere destilar.

El agente propuso inicialmente una cuarta estantería — un`index-backup.adoc`que sería LAZY y contendría un índice de todo el backup. Lo rechacé. Sería una redundancia más en un sistema que ya sufre de crecimiento lineal. La estructura de los archivos archivados ya es un índice.

== El sensor de dos disparadores

La conceptualización era sólida, pero quedaba un punto ciego:**¿Cuándo exactamente desencadenar la rotación?**El artículo inicial lo identificaba como una pregunta abierta. Dos días después, la respuesta está codificada en los archivos de gobernanza de seis proyectos: un sensor con dos disparadores.

=== El Desencadenador Automático — `N % 10 == 0

El primer desencadenante es matemático. Cuando el número de sesión es múltiplo de 10 — sesión 10, 20, 30, 40 — la rotación de backup se ejecuta automáticamente dentro del procedimiento de fin de sesión, justo después del paso 6.

¿Por qué 10? Es el compromiso entre dos fuerzas opuestas: una ventana demasiado corta (5 sesiones) pierde el contexto necesario para la continuidad; una ventana demasiado larga (20 sesiones) no resuelve el problema de sobrepeso del contexto. Diez sesiones, a un ritmo de una a dos sesiones por día, cubren aproximadamente una semana de trabajo — suficiente para que el agente recuerde las decisiones recientes, pero no suficiente para que el contexto explote.

=== El Desencadenante por Umbral — 500 Líneas EAGER

El segundo disparador es dinámico. Independientemente del número de sesión, si los archivos EAGER acumulados superan**500 líneas**, la rotación se dispara.

Este umbral protege contra el escenario en el que las sesiones son excepcionalmente productivas — mucho contenido escrito en pocas sesiones. Una sesión que produce 120 líneas de contenido editorial hace crecer COMPLETED_TASKS_ARCHIVE mucho más rápido que una sesión de depuración que corrige dos líneas. El umbral de 500 líneas, medido vía`wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc`, detecta esta asimetría.

=== El Desencadenador Manual — "copia de seguridad de rotación

Finalmente, el humano mantiene el control. Las palabras clave`rotation backup`, `backup rotation` ou `lance la rotation backup`Activan el procedimiento a petición, independientemente del final de la sesión. Útil cuando se siente que el contexto se vuelve pesado pero aún no se ha alcanzado un múltiplo de 10, o cuando se desea archivar una fase de trabajo antes de comenzar una nueva.

[plantuml, format=svg, id=diag-capteur-trigger, alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Sensor de Rotación Backup — Los Tres Desencadenadores
start

:Procédure de fin de session;
note right: Mots-clés "fin de la sesión"\nou "paramos aquí"

:Étapes 1 à 6\n(archivage standard);
note right
  1. Archive sessions/N.adoc
  2. MAJ PROMPT_REPRISE
  3. MAJ SESSIONS_HISTORY
  4. MAJ INDEX.adoc
  5. MAJ TEST_COVERAGE
  6. MAJ COMPLETED_TASKS
end note

if (N % 10 == 0\nOU\nEAGER cumulé > 500 lignes ?) then (oui)
  :⚙️ Rotation Backup\n(étape 7);
  note right
    1. Créer backup/Y20XX-sessions-X-Y/
    2. Copier intégrale INDEX + HISTORY
       + COMPLETED_TASKS + sessions/
    3. Tronquer actifs à 10 sessions
    4. Ajouter _Localisation active_
  end note
else (non)
  :Pas de rotation;
endif

:Checklist [✅] x 7\n(si applicable);

stop

@enduml
----

Este diagrama muestra la inserción exacta del sensor en el procedimiento de finalización de sesión. El paso 7 es opcional — solo se ejecuta si una de las dos condiciones es verdadera — pero se *verificada* sistemáticamente. La lista de verificación final incluye`[✅] 7. Backup roté (si applicable)`.

=== El Bucle Cerrado

Este sensor cierra el bucle abierto por el artículo anterior. La gobernanza Eager/Lazy había resuelto el problema de la memoria del agente entre dos sesiones. El mecanismo Hot/Warm/Cold ha resuelto el problema de la memoria que aumenta. El sensor de dos desencadenantes resuelve el problema del *cuándo* — quitando al humano la carga mental de vigilar el tamaño del contexto.

[plantuml, format=svg, id=diag-boucle-fermee, alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Las Tres Capas de la Gobernanza de Agentes
left to right direction

package "Capa 1 — Memoria\n(Artículo 0108)" as C1 #E8F5E9 {
  rectangle "**EAGER**\nPanel de control\nCargado automáticamente" as EAG
  rectangle "**LAZY**\nManual del propietario\nCargado bajo demanda" as LAZ
  EAG -[hidden]right-> LAZ
}

package "Capa 2 — Envejecimiento\n(Artículo 0110)" as C2 #FFF9C4 {
  rectangle "**HOT**\n10 sesiones activas\n~300 líneas" as HOT
  rectangle "**WARM**\nReferencias\nProcedimientos" as WRM
  rectangle "**FRÍO**\nbackup/\nOla fría" as CLD
  HOT -[hidden]right-> WRM
  WRM -[hidden]right-> CLD
}

package "Capa 3 — Desencadenante\n(Hoy)" as C3 #BBDEFB {
  rectangle "**Automático**\nN % 10 == 0" as AUTO
  rectangle "**Umbral**\n> 500 líneas" as SEUIL
  rectangle "**Manuel**\ncopia de seguridad rotativa" as MAN
  AUTO -[hidden]right-> SEUIL
  SEUIL -[hidden]right-> MAN
}

C1 --> C2 : "La memoria crece\n→ hace falta un mecanismo\nde envejecimiento"
C2 --> C3 : "El envejecimiento\n→ hace falta un desencadenador\npara ejecutarlo"

note bottom of C3
  ✅ Déployé sur 6 projets
  magic-stick · bakery-gradle
  plantuml-gradle · cheroliv.com
  jhipster-gradle-plugins
  quizz-benchmark-gradle
end note

@enduml
----

Las tres capas se apilan lógicamente. La primera le da una memoria al agente. La segunda impide que esa memoria ahogue al agente. La tercera automatiza el mantenimiento de esa memoria para que el humano no tenga que pensar en ello.

=== La migración efectiva en cheroliv.com

El mecanismo no se quedó teórico. Sobre`cheroliv.com`, la primera rotación de copia de seguridad se ejecutó el 29 de abril de 2026 — las sesiones -6 a 2 se han migrado a`.agents/backup/Y2026-sessions-neg6-a-002/`:

|===
|Archivo |Antes de la rotación |Después de la rotación |ganancia |`.agents/INDEX.adoc` |19 sesiones listadas |10 sesiones (3-12) |-9 entradas |`.agents/SESSIONS_HISTORY.adoc` |18 sesiones |10 sesiones |-8 entradas |`COMPLETED_TASKS_ARCHIVE` |161 líneas (sesiones 1-12) |135 líneas (sesiones 3-12) |-26 líneas |`sessions/` |20 archivos |10 archivos |-10 archivos |**copia de seguridad/** |inexistente |1 ola fría (10 sesiones archivadas) |+1 paquete frío
|===

La ganancia en líneas era modesta — el proyecto es joven, 12 sesiones — pero lo importante es que el**el mecanismo está establecido**. La próxima rotación automática se activará en la sesión 20, o antes si se alcanzan las 500 líneas EAGER.

== La Lección Humano-Agente

Esta sesión 048 me ha enseñado algo fundamental sobre la colaboración con un agente IA.

El agente tiene un sesgo natural: busca**optimizar**, à **simplificar**, à **eliminar las redundancias**. Es el sesgo de un sistema entrenado para producir respuestas limpias y concisas. Ante un conjunto de datos rico y multidimensional, su primer reflejo es reducirlo a su forma más simple.

El ser humano, por su parte, tiene una intuición diferente: presiente que la redundancia estructurada es una**ventaja**, no es un defecto. Que la diversidad de ángulos sobre una misma realidad es precisamente lo que permitirá, más tarde, una destilación de calidad.

No es que el agente esté equivocado. Es que su 'óptimo' no es el mío. El agente optimiza para el**presente**— el contexto inmediato, la respuesta rápida a la pregunta planteada. El ser humano optimiza para el**futuro**— la capacidad de encontrar, cruzar, destilar en tres meses o tres años.

____ Lo que quiero es el material bruto. Tus reflexiones, tus dudas, tus respuestas a mis preguntas. No tu síntesis. La síntesis, sé hacerla mejor que tú. Quiero la materia prima. ____

Esta frase que le dije al final de la sesión lo resume todo. El agente es una herramienta de producción. El humano es la herramienta de destilación. La gobernanza no está hecha para que el agente lo entienda todo solo — está hecha para que el humano pueda, más tarde, trabajar el material producido.

La ola fría idéntica es la traducción arquitectónica de esta filosofía: no se tira nada, no se fusiona nada, no se reindexa nada. Se desplaza el paquete intacto. La destilación vendrá más tarde, a mano, por el humano.

== La continuación lógica del artículo anterior

Si has leídolink:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[el artículo sobre la estrategia Eager/Lazy], reconocerá la progresión natural :

1. **Artículo 0108**El gobierno Eager/Lazy: *cómo* estructurar el contexto del agente en dos niveles de disponibilidad
2. **Este artículo 0110**— El mecanismo de backup : *comment* hacer envejecer este contexto sin perderlo cuando se vuelve demasiado voluminoso

El primer artículo respondía a la pregunta: « El agente no recuerda nada entre dos sesiones, ¿cómo darle una memoria?

Esto responde a la pregunta que inevitablemente se deriva de la primera: «La memoria crece en cada sesión, ¿cómo impedir que ahogue al agente sin borrarla?

La respuesta está en un patrón:**Caliente/Templado/Frío**, aplicado a los archivos de gobernanza. Y en principio:**nunca perder nada, siempre relocalizar todo**.

== Enlaces

* Artículo anterior :link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Gobernar un agente IA con AsciiDoc]
* Mi sitio: https://cheroliv.com
* El proyecto`magic-stick`: https://github.com/cheroliv/magic-stick

---

Un buen sistema de gobernanza nunca elimina datos. Los ordena.
----
----

La clave del mecanismo:**La copia de seguridad no es un índice central, es una copia exacta de la ola pasada**. Cuando se supera el horizonte de las 10 sesiones activas, no se elimina nada. No se reindexa nada. No se fusiona nada. Se toma el paquete de archivos de agentes tal como estaba en la sesión N-10 y se lo mueve a`backup/`.

Los archivos activos, por su parte, están truncados:

* INDEX: solo las 10 últimas líneas (sliding window)
* SESSIONS_HISTORY : lo mismo
* COMPLETED_TASKS_ARCHIVE : nuevo archivo para el período en curso
* sessions/ : únicamente las 2 últimas sesiones

[plantuml, format=svg, id=diag-hot-warm-cold, alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Arquitectura Hot / Warm / Cold del Contexto del Agente
package "HOT (EAGER)\nCargado automáticamente\n~300 líneas" as HOT #FFCDD2 {
  file "INDEX.adoc\n(10 sesiones)" as IDX_HOT
  file "PROMPT_REANUDACIÓN\n(sesión N+1)" as PRO_HOT
  file "AGENT.adoc\n(reglas absolutas)" as AG_HOT
}

package "WARM (LAZY)\nCargado bajo demanda\n~500 líneas" as WARM #FFF9C4 {
  file "SESSIONS_HISTORY\n(últimas 10)" as HIS_WARM
  file "SCRIPT_VERIFICATION\n(última)" as VER_WARM
  file "PROCEDIMIENTOS.adoc\n(plantillas)" as PRO_WARM
  file "*_REFERENCE.adoc\n(doc técnica)" as REF_WARM
}

package "COLD (backup/)\nNunca cargado\nLectura humana únicamente" as COLD #BBDEFB {
  folder "Y2026-001-039/" as WAVE {
    file "ÍNDICE (completo)" as IDX_COLD
    file "SESSIONS_HISTORY\n(completo)" as HIS_COLD
    file "TAREAS_COMPLETADAS\n(completo)" as ARCH_COLD
    folder "sessions/ (001-039)" as SESS_COLD
  }
  folder "Y2026-040-???\n(futuro)" as FUTURE
}

HOT --> WARM : "Agente remonta\nsi es necesario"
WARM --> COLD : "Nunca automático\nEl humano va allí solo"

note bottom of COLD
  Règle : COPIE INTÉGRALE
  Pas de transformation
  Pas de réindexation
  Read-only après archivage
end note

@enduml
----

El beneficio inmediato es masivo: el contexto EAGER pasa de**~5200 líneas a ~300 líneas**. Una división por 17. Sin haber perdido ni una sola línea de datos históricos.

== ¿Por qué esto no es un cajón de sastre?

El agente, en su primera iteración, temía que`backup/`devienne una caja negra — una carpeta donde se tiran archivos que nunca volveremos a leer. Es un miedo legítimo. Pero se basa en una confusión.

Un cajón de sastre, es cuando se tiran archivos**sin estructura, sin convención, sin lógica de agrupación**. Aquí, la copia de seguridad está estructurada por período (Y2026-001-039), y cada carpeta de copia de seguridad contiene**la misma estructura**que el expediente`.agents/`activo : INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/.

No es un saco de todo. Es un**instantánea horodatada**. Incluso podríamos decir que es un mecanismo de versionado simplificado — salvo que no versiona los archivos individualmente, sino el paquete completo de la gobernanza en un momento dado.

Cuando quieras encontrar información antigua, no necesitas un índice central. Tienes dos opciones:

1. **grep` dirigido**:`grep -r "zsh" backup/Y2026-001-039/`— y encuentras todo lo que menciona zsh en el período, cualquiera que sea el ángulo (INDEX, SESSIONS_HISTORY, archivo de sesión).
2. **Reintegración manual**: copias temporalmente la carpeta de backup en el contexto activo, y le pides al agente que analice este período específico.

El índice es implícito. Está en la propia estructura de los archivos — cada uno ya es un índice desde su propio ángulo.

== La metáfora de las estanterías

Para hacer el mecanismo intuitivo, lo he concebido en tres estantes :

* **Estantería 1 (EAGER)**— el plan de trabajo. Lo que necesito *ahora*. ÍNDICE reciente, PROMPT_REPRISE, reglas absolutas. Ligero, inmediato, crítico.
* **Estantería 2 (LAZY)**— la biblioteca de consulta. Lo que puedo ir a buscar bajo petición. Referencias técnicas, historial reciente, procedimientos. Más voluminoso, pero no cargado en memoria.
* **Cueva (backup/)**— los archivos fríos. Todo lo que ha pasado pero que no quiero tirar. El agente nunca entra allí. El ser humano baja cuando quiere destilar.

El agente ha propuesto inicialmente una cuarta estantería — un`index-backup.adoc`que sería LAZY y contendría una tabla de contenidos de todo el backup. Me negué. Sería una redundancia más en un sistema que ya sufre un crecimiento lineal. La estructura de los archivos archivados ya es un índice.

== El Sensor de Dos Disparadores

La conceptualización era sólida, pero quedaba un punto ciego:**¿Cuándo exactamente activar la rotación?**El artículo inicial lo identificaba como una pregunta abierta. Dos días después, la respuesta está codificada en los archivos de gobernanza de seis proyectos: un sensor de dos disparadores.

=== El desencadenador automático — `N % 10 == 0

El primer desencadenante es matemático. Cuando el número de sesión es un múltiplo de 10 — sesión 10, 20, 30, 40 — la rotación de copia de seguridad se ejecuta automáticamente dentro del procedimiento de fin de sesión, justo después del paso 6.

¿Por qué 10? Es el compromiso entre dos fuerzas opuestas: una ventana demasiado corta (5 sesiones) pierde el contexto necesario para la continuidad; una ventana demasiado larga (20 sesiones) no resuelve el problema de sobrecarga del contexto. Diez sesiones, a un ritmo de una a dos sesiones por día, cubren aproximadamente una semana de trabajo — suficiente para que el agente recuerde las decisiones recientes, pero no tanto para que el contexto explote.

=== El Disparador por Umbral — 500 líneas EAGER

El segundo desencadenante es dinámico. Independientemente del número de sesión, si los archivos EAGER acumulados superan**500 líneas**, la rotación se activa

Este umbral protege contra el escenario en el que las sesiones son excepcionalmente productivas — mucho contenido escrito en pocas sesiones. Una sesión que produce 120 líneas de contenido editorial hace que COMPLETED_TASKS_ARCHIVE crezca mucho más rápido que una sesión de depuración que corrige dos líneas. El umbral de 500 líneas, medido vía`wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc`, capta esta asimetría.

=== El Desencadenador Manual — "rotación de copia de seguridad

Finalmente, el ser humano mantiene el control. Las palabras clave`rotation backup`, `backup rotation` ou `lance la rotation backup`desencadenan el procedimiento a petición, independientemente del fin de la sesión. Útil cuando sientes que el contexto se vuelve pesado pero todavía no estás en un múltiplo de 10, o cuando quieres archivar una fase de trabajo antes de comenzar una nueva.

[plantuml, format=svg, id=diag-capteur-trigger, alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Sensor de Rotación de Respaldo — Los Tres Disparadores
start

:Procédure de fin de session;
note right: Mots-clés "fin de sesión"\nou "Lo dejamos aquí"

:Étapes 1 à 6\n(archivage standard);
note right
  1. Archive sessions/N.adoc
  2. MAJ PROMPT_REPRISE
  3. MAJ SESSIONS_HISTORY
  4. MAJ INDEX.adoc
  5. MAJ TEST_COVERAGE
  6. MAJ COMPLETED_TASKS
end note

if (N % 10 == 0\nOU\nEAGER cumulé > 500 lignes ?) then (oui)
  :⚙️ Rotation Backup\n(étape 7);
  note right
    1. Créer backup/Y20XX-sessions-X-Y/
    2. Copier intégrale INDEX + HISTORY
       + COMPLETED_TASKS + sessions/
    3. Tronquer actifs à 10 sessions
    4. Ajouter _Localisation active_
  end note
else (non)
  :Pas de rotation;
endif

:Checklist [✅] x 7\n(si applicable);

stop

@enduml
----

Este diagrama muestra la inserción exacta del sensor en el procedimiento de finalización de la sesión. El paso 7 es opcional — se ejecuta solo si una de las dos condiciones es verdadera — pero se verifica sistemáticamente *verificada*. La lista de verificación final incluye`[✅] 7. Backup roté (si applicable)`.

=== El bucle cerrado

Este sensor cierra el bucle abierto por el artículo anterior. La gobernanza Eager/Lazy había resuelto el problema de la memoria del agente entre dos sesiones. El mecanismo Hot/Warm/Cold resolvió el problema de la memoria que crece. El sensor de dos desencadenadores resuelve el problema del *cuándo* — quitando al humano la carga mental de supervisar el tamaño del contexto.

[plantuml, format=svg, id=diag-boucle-fermee, alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Las Tres Capas de la Gobernanza de Agentes
left to right direction

package "Capa 1 — Memoria\n(Artículo 0108)" as C1 #E8F5E9 {
  rectangle "**EAGER**\nPanel de control\nCargado automáticamente" as EAG
  rectangle "**LAZY**\nManual del propietario\nCargado bajo demanda" as LAZ
  EAG -[hidden]right-> LAZ
}

package "Capa 2 — Envejecimiento\n(Artículo 0110)" as C2 #FFF9C4 {
  rectangle "**HOT**\n10 sesiones activas\n~300 líneas" as HOT
  rectangle "**WARM**\nReferencias\nProcedimientos" as WRM
  rectangle "**COLD**\nbackup/\nOla de frío" as CLD
  HOT -[hidden]right-> WRM
  WRM -[hidden]right-> CLD
}

package "Capa 3 — Activador\n(Hoy)" as C3 #BBDEFB {
  rectangle "**Auto**\nN % 10 == 0" as AUTO
  rectangle "**Umbral**\n> 500 líneas" as SEUIL
  rectangle "**Manuel**\nrotación de copias de seguridad" as MAN
  AUTO -[hidden]right-> SEUIL
  SEUIL -[hidden]right-> MAN
}

C1 --> C2 : "La memoria crece\n→ se necesita un mecanismo\nde envejecimiento"
C2 --> C3 : "El envejecimiento\n→ se necesita un desencadenante\npara ejecutarlo"

note bottom of C3
  ✅ Déployé sur 6 projets
  magic-stick · bakery-gradle
  plantuml-gradle · cheroliv.com
  jhipster-gradle-plugins
  quizz-benchmark-gradle
end note

@enduml
----

Las tres capas se apilan lógicamente. La primera proporciona memoria al agente. La segunda evita que esta memoria ahogue al agente. La tercera automatiza el mantenimiento de esa memoria para que el humano no tenga que pensar en ello.

=== La Migración Efectiva en cheroliv.com

El mecanismo no se ha quedado teórico. En`cheroliv.com`, la primera rotación de respaldo se ejecutó el 29 de abril de 2026 — las sesiones -6 a 2 se han migrado hacia`.agents/backup/Y2026-sessions-neg6-a-002/`:

|===
|Archivo |Antes de la rotación |Después de rotación |Ganancia |`.agents/INDEX.adoc` |19 sesiones listadas |10 sesiones (3-12) |-9 entradas |`.agents/SESSIONS_HISTORY.adoc` |18 sesiones |10 sesiones |-8 entradas |`COMPLETED_TASKS_ARCHIVE` |161 líneas (sesiones 1-12) |135 líneas (sesiones 3-12) |-26 líneas |`sessions/` |20 archivos |10 archivos |-10 archivos |**copia de seguridad/** |inexistente |1 ola fría (10 sesiones archivadas) |+1 paquete frío
|===

La ganancia en líneas era modesta — el proyecto es joven, 12 sesiones — pero lo importante es que el**el mecanismo está en su lugar**. La próxima rotación automática se desencadenará en la sesión 20, o antes si se alcanzan las 500 líneas EAGER.

== La Lección Humano-Agente

Esta sesión 048 me ha enseñado algo fundamental sobre la colaboración con un agente IA.

El agente tiene un sesgo natural: tiende a**optimizar**, à **simplificar**, à **eliminar las redundancias**. Es el sesgo de un sistema entrenado para producir respuestas limpias y concisas. Ante un conjunto de datos rico y multidimensional, su primer reflejo es reducirlo a su expresión más simple.

El ser humano, por su parte, tiene una intuición diferente: intuye que la redundancia estructurada es un**ventaja**, no es un defecto. Que la diversidad de los ángulos sobre una misma realidad es precisamente lo que permitirá, más tarde, una destilación de calidad.

No es que el agente esté equivocado. Es que su 'optimum' no es el mío. El agente optimiza para el**presente**— el contexto inmediato, la respuesta rápida a la pregunta planteada. El ser humano optimiza para el**futuro**— la capacidad de encontrar, cruzar, destilar en tres meses o tres años.

____ Lo que quiero es el material bruto. Tus reflexiones, tus dudas, tus respuestas a mis preguntas. No tu síntesis. La síntesis, sé cómo hacerla mejor que tú. Quiero la materia prima. ____

Esta frase que le dije al final de la sesión lo resume todo. El agente es una herramienta de producción. El ser humano es la herramienta de destilación. La gobernanza no está hecha para que el agente comprenda todo solo — está hecha para que el ser humano pueda, más tarde, trabajar el material producido.

La ola fría idéntica es la traducción arquitectónica de esta filosofía: no se tira nada, no se fusiona nada, no se reindiza nada. Se desplaza el paquete intacto. La destilación vendrá más tarde, a mano, por el humano.

== La continuación lógica del artículo anterior

Si has leídolink:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[el artículo sobre la estrategia Eager/Lazy], reconocerás la progresión natural :

1. **Artículo 0108**— La gobernanza Eager/Lazy : *comment* estructurar el contexto del agente en dos niveles de disponibilidad
2. **Este artículo 0110**— El mecanismo de backup: *cómo* hacer que este contexto envejezca sin perderlo cuando se vuelve demasiado voluminoso

El primer artículo respondía a la pregunta: « El agente no recuerda nada entre dos sesiones, ¿cómo darle una memoria?

Éste responde a la pregunta que se deriva inevitablemente de la primera: « La memoria crece en cada sesión, ¿cómo impedir que ahogue al agente sin borrarla?

La respuesta se reduce a un patrón :**Caliente/Tibio/Frío**, aplicado a los archivos de gobernanza. Y en un principio:**nunca perder nada, siempre relocalizar todo**.

== Enlaces

* Artículo anterior :link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Gobernar un agente de IA con AsciiDoc]
* Mi sitio : https://cheroliv.com
* El proyecto`magic-stick`: https://github.com/cheroliv/magic-stick

---

*Un buen sistema de gobernanza nunca elimina datos. Los organiza.*
----

La clave del mecanismo:**el backup no es un índice central, es una copia fiel de la ola pasada**. Cuando se supera el horizonte de las 10 sesiones activas, no se elimina nada. No se reindexa nada. No se fusiona nada. Se toma el paquete de archivos de agentes tal como estaba en la sesión N-10 y se desplaza a`backup/`Please provide the text you would like me to translate.

Los archivos activos, por su parte, se truncan:

* ÍNDICE : únicamente las 10 últimas líneas (ventana deslizante)
* SESSIONS_HISTORY : idem
* COMPLETED_TASKS_ARCHIVE : nuevo archivo para el periodo actual
* sessions/ : únicamente las 2 últimas sesiones

[plantuml, format=svg, id=diag-hot-warm-cold, alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Arquitectura Hot / Warm / Cold del Contexto del Agente
package "HOT (EAGER)\nCargado automáticamente\n~300 líneas" as HOT #FFCDD2 {
  file "INDEX.adoc\n(10 sesiones)" as IDX_HOT
  file "PROMPT_REPRISE\n(sesión N+1)" as PRO_HOT
  file "AGENT.adoc\n(reglas absolutas)" as AG_HOT
}

package "WARM (LAZY)\nCargado bajo demanda\n~500 líneas" as WARM #FFF9C4 {
  file "SESSIONS_HISTORY\n(10 últimas)" as HIS_WARM
  file "SCRIPT_VERIFICATION\n(última)" as VER_WARM
  file "PROCEDURES.adoc\n(plantillas)" as PRO_WARM
  file "*_REFERENCE.adoc\n(doc técnica)" as REF_WARM
}

package "COLD (backup/)\nNunca cargado\nLectura humana únicamente" as COLD #BBDEFB {
  folder "Y2026-001-039/" as WAVE {
    file "INDEX (completo)" as IDX_COLD
    file "SESSIONS_HISTORY\n(completo)" as HIS_COLD
    file "COMPLETED_TASKS\n(completo)" as ARCH_COLD
    folder "sessions/ (001-039)" as SESS_COLD
  }
  folder "Y2026-040-???\n(futuro)" as FUTURE
}

HOT --> WARM : "El agente recurre\nsi es necesario"
WARM --> COLD : "Nunca automático\nEl humano accede solo"

note bottom of COLD
Regla: COPIA ÍNTEGRA
Sin transformación
Sin reindexación
Solo lectura después del archivado
end note

@enduml
----

La ganancia inmediata es masiva: el contexto EAGER pasa de**~5200 líneas a ~300 líneas**. Una división por 17. Sin haber perdido una sola línea de datos históricos.

== Por qué no es un cajón de sastre

El agente, en su primera iteración, temía que`backup/`se convierta en una caja negra — una carpeta donde se arrojan archivos que nunca se volverán a leer. Es un miedo legítimo. Pero se basa en una confusión.

Un "cajón de sastre" es cuando se tiran archivos**sin estructura, sin convención, sin lógica de agrupación**. Aquí, el backup está estructurado por periodo (`Y2026-001-039`), y cada carpeta de backup contiene**la misma estructura**que el expediente`.agents/`activo: INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/.

No es un cajón de sastre. Es un**instantánea con marca de tiempo**. Incluso se podría decir que es un mecanismo de versionado simplificado — con la salvedad de que no versiona los archivos individualmente, sino el paquete completo de la gobernanza en un momento T.

Cuando quiera recuperar una información antigua, no necesita un índice central. Tiene dos opciones:

1. **grep` focalizado**Please provide the text you would like me to translate.`grep -r "zsh" backup/Y2026-001-039/`— y encuentra todo lo que mencione zsh en el periodo, independientemente del ángulo (INDEX, SESSIONS_HISTORY, archivo de sesión).
2. **Reintegración manual**: copias temporalmente la carpeta de backup en el contexto activo y le pides al agente que analice este periodo específico.

El índice es implícito. Está en la estructura misma de los archivos; cada uno es ya un índice desde su propio ángulo.

== La Metáfora de los Estantes

Para hacer que el mecanismo sea intuitivo, lo he conceptualizado en tres estantes:

* **Estante 1 (EAGER)**— el plan de trabajo. Lo que necesito *ahora*. INDEX reciente, PROMPT_REPRISE, reglas absolutas. Ligero, inmediato, crítico.
* **Estante 2 (LAZY)**— la biblioteca de consulta. Lo que puedo ir a buscar bajo demanda. Referencias técnicas, historial reciente, procedimientos. Más voluminoso, pero no cargado en memoria.
* **Cueva (backup/)**— los archivos fríos. Todo lo que ha pasado pero que no quiero tirar. El agente nunca entra allí. El humano baja cuando quiere destilar.

El agente propuso inicialmente un cuarto estante — un`index-backup.adoc`que sería LAZY y contendría una tabla de contenidos de todo el backup. Me negué. Sería una redundancia más en un sistema que ya sufre de crecimiento lineal. La estructura de los archivos archivados ya es un índice.

== El Sensor de Dos Disparadores

La conceptualización era sólida, pero quedaba un punto ciego:**¿cuándo exactamente activar la rotación?**El artículo inicial lo identificaba como una cuestión abierta. Dos días más tarde, la respuesta está codificada en los archivos de gobernanza de seis proyectos: un sensor de dos disparadores.

=== El Disparador Automático — `N % 10 == 0

El primer desencadenante es matemático. Cuando el número de sesión es un múltiplo de 10 — sesión 10, 20, 30, 40 — la rotación backup se ejecuta automáticamente dentro del procedimiento de fin de sesión, justo después del paso 6.

¿Por qué 10? Es el compromiso entre dos fuerzas contrarias: una ventana demasiado corta (5 sesiones) pierde el contexto necesario para la continuidad; una ventana demasiado larga (20 sesiones) no resuelve el problema de sobrepeso del contexto. Diez sesiones, a un ritmo de una a dos sesiones por día, cubren aproximadamente una semana de trabajo: lo suficiente para que el agente recuerde las decisiones recientes, pero no tanto como para que el contexto explote.

=== El Disparador por Umbral — 500 Líneas EAGER

El segundo disparador es dinámico. Independientemente del número de sesión, si los archivos EAGER acumulados superan**500 líneas**, la rotación se activa.

Este umbral protege contra el escenario en el que las sesiones son excepcionalmente productivas: mucho contenido escrito en pocas sesiones. Una sesión que produce 120 líneas de contenido editorial hace crecer `COMPLETED_TASKS_ARCHIVE` mucho más rápido que una sesión de depuración que corrige dos líneas. El umbral de 500 líneas, medido a través de`wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc`, capta esta asimetría.

=== El Activador Manual — "rotation backup

Finalmente, el humano mantiene el control. Las palabras clave`rotation backup`, `backup rotation` ou `lance la rotation backup`desencadenan el procedimiento bajo demanda, independientemente del final de la sesión. Útil cuando se siente que el contexto se vuelve pesado pero aún no se ha llegado a un múltiplo de 10, o cuando se quiere archivar una fase de trabajo antes de comenzar una nueva.

[plantuml, format=svg, id=diag-capteur-trigger, alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Sensor de Rotación de Respaldo — Los Tres Disparadores
start

:Procédure de fin de session;
note right: Mots-clés "fin de sesión"\nou "lo dejamos aquí"

:Étapes 1 à 6\n(archivage standard);
note right
1. Archivar sesiones/N.adoc
2. ACT PROMPT_REPRISE
3. ACT SESSIONS_HISTORY
4. ACT INDEX.adoc
5. ACT TEST_COVERAGE
6. ACT COMPLETED_TASKS
end note

if (N % 10 == 0\nOU\nEAGER cumulé > 500 lignes ?) then (oui)
  :⚙️ Rotation Backup\n(étape 7);
  note right
1. Crear backup/Y20XX-sessions-X-Y/
2. Copiar íntegramente INDEX + HISTORY
+ COMPLETED_TASKS + sessions/
3. Truncar activos a 10 sesiones
4. Añadir _Localisation active_
  end note
else (non)
  :Pas de rotation;
endif

:Checklist [✅] x 7\n(si applicable);

stop

@enduml
----

Este diagrama muestra la inserción exacta del sensor en el procedimiento de fin de sesión. El paso 7 es opcional —solo se ejecuta si una de las dos condiciones es verdadera— pero se *verifica* sistemáticamente. La lista de comprobación final incluye`[✅] 7. Backup roté (si applicable)`Please provide the text you would like me to translate.

=== El Bucle Cerrado

Este sensor cierra el bucle abierto por el artículo anterior. La gobernanza Eager/Lazy había resuelto el problema de la memoria del agente entre dos sesiones. El mecanismo Hot/Warm/Cold resolvió el problema de la memoria que crece. El sensor de dos disparadores resuelve el problema del *cuándo*, eliminando la carga mental del humano de supervisar el tamaño del contexto.

[plantuml, format=svg, id=diag-boucle-fermee, alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Las Tres Capas de la Gobernanza del Agente
left to right direction

package "Capa 1 — Memoria\n(Artículo 0108)" as C1 #E8F5E9 {
  rectangle "**EAGER**\nTablero de control\nCarga automática" as EAG
  rectangle "**LAZY**\nManual del propietario\nCarga bajo demanda" as LAZ
  EAG -[hidden]right-> LAZ
}

package "Capa 2 — Envejecimiento\n(Artículo 0110)" as C2 #FFF9C4 {
  rectangle "**HOT**\n10 sesiones activas\n~300 líneas" as HOT
  rectangle "**WARM**\nReferencias\nProcedimientos" as WRM
  rectangle "**COLD**\nbackup/\nOla fría" as CLD
  HOT -[hidden]right-> WRM
  WRM -[hidden]right-> CLD
}

package "Capa 3 — Desencadenante\n(Hoy)" as C3 #BBDEFB {
  rectangle "**Auto**\nN % 10 == 0" as AUTO
  rectangle "**Umbral**\n> 500 líneas" as SEUIL
  rectangle "**Manual**\nrotación de backup" as MAN
  AUTO -[hidden]right-> SEUIL
  SEUIL -[hidden]right-> MAN
}

C1 --> C2 : "La memoria crece\n→ se necesita un mecanismo\nde envejecimiento"
C2 --> C3 : "El envejecimiento\n→ se necesita un desencadenante\npara ejecutarlo"

note bottom of C3
✅ Desplegado en 6 proyectos
`magic-stick` · `bakery-gradle`
`plantuml-gradle` · `cheroliv.com`
`jhipster-gradle-plugins`
`quizz-benchmark-gradle
end note

@enduml
----

Las tres capas se apilan lógicamente. La primera le otorga memoria al agente. La segunda evita que esta memoria abrume al agente. La tercera automatiza el mantenimiento de esta memoria para que el humano no tenga que pensar en ello.

=== La Migración Efectiva en cheroliv.com

El mecanismo no se quedó en lo teórico. Sobre`cheroliv.com`, la primera rotación de backup se ejecutó el 29 de abril de 2026 — las sesiones -6 a 2 migraron hacia`.agents/backup/Y2026-sessions-neg6-a-002/`Please provide the text you would like me to translate.

|===
|Archivo |Antes de la rotación |Después de la rotación |Ganancia |`.agents/INDEX.adoc` |19 sesiones listadas |10 sesiones (3-12) |-9 entradas |`.agents/SESSIONS_HISTORY.adoc` |18 sesiones |10 sesiones |-8 entradas |`COMPLETED_TASKS_ARCHIVE` |161 líneas (sesiones 1-12) |135 líneas (sesiones 3-12) |-26 líneas |`sessions/` |20 archivos |10 archivos |-10 archivos |**backup/** |Inexistente |1 ola fría (10 sesiones archivadas) |+1 paquete frío
|===

La ganancia en líneas fue modesta — el proyecto es joven, 12 sesiones — pero lo importante es que el**el mecanismo está implementado**. La próxima rotación automática se activará en la sesión 20, o antes si se alcanzan las 500 líneas EAGER.

== La Lección Humano-Agente

Esta sesión 048 me ha enseñado algo fundamental sobre la colaboración con un agente de IA.

El agente tiene un sesgo natural: busca**optimizar**, à **simplificar**, à **eliminar las redundancias**. Es el sesgo de un sistema entrenado para producir respuestas limpias y concisas. Ante un dataset rico y multidimensional, su primer reflejo es reducirlo a su expresión más simple.

El ser humano, por su parte, tiene una intuición diferente: presiente que la redundancia estructurada es un**ventaja**, no un defecto. Que la diversidad de ángulos sobre una misma realidad es precisamente lo que permitirá, más tarde, una destilación de calidad.

No es que el agente esté equivocado. Es que su "optimum" no es el mío. El agente optimiza para el**presente**— el contexto inmediato, la respuesta rápida a la pregunta planteada. El humano optimiza para el**futuro**— la capacidad de recuperar, cruzar, destilar en tres meses o tres años.

Please provide the text you would like me to translate. Lo que quiero es el material bruto. Tus reflexiones, tus vacilaciones, tus respuestas a mis preguntas. No tu síntesis. La síntesis, sé hacerla mejor que tú. Quiero la materia prima. Please provide the text you would like me to translate.

Esta frase que le dije al final de la sesión lo resume todo. El agente es una herramienta de producción. El humano es la herramienta de destilación. La gobernanza no está hecha para que el agente lo comprenda todo por sí solo — está hecha para que el humano pueda, más tarde, trabajar el material producido.

La misma ola fría es la traducción arquitectónica de esta filosofía: no se tira nada, no se fusiona nada, no se reindexa nada. Se desplaza el paquete intacto. La destilación vendrá más tarde, a mano, por el humano.

== La continuación lógica del artículo anterior

Si ha leídolink:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[el artículo sobre la estrategia Eager/Lazy], reconocerá la progresión natural:

1. **Artículo 0108**— La gobernanza Eager/Lazy: *cómo* estructurar el contexto del agente en dos niveles de disponibilidad
2. **Este artículo 0110**— El mecanismo de backup: *cómo* hacer que este contexto envejezca sin perderlo cuando se vuelve demasiado voluminoso

El primer artículo respondía a la pregunta: «El agente no recuerda nada entre dos sesiones, ¿cómo darle una memoria?

Este responde a la pregunta que surge inevitablemente de la primera: «La memoria crece en cada sesión, ¿cómo evitar que asfixie al agente sin borrarla?

La respuesta se resume en un patrón:**Caliente/Tibio/Frío**, aplicado a los archivos de gobernanza. Y en un principio:**no perder nunca nada, relocalizar siempre todo**Please provide the text you would like me to translate.

== Enlaces

* Artículo anterior:link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Gobernar un Agente de IA con AsciiDoc]
* Mi sitio: https://cheroliv.com
* El proyecto`magic-stick`: https://github.com/cheroliv/magic-stick

---

Un buen sistema de gobernanza nunca elimina datos. Los archiva.
----

La llave del mecanismo:**La copia de seguridad no es un índice central, es una copia exacta de la ola pasada.**. Cuando se supera el horizonte de las 10 sesiones activas, no eliminamos nada. No reindexamos nada. No fusionamos nada. Tomamos el paquete de archivos de agentes tal como estaba en la sesión N‑10 y lo movemos dentro`backup/`.

Los archivos activos, ellos, están truncados:

* ÍNDICE: solo las últimas 10 líneas (ventana deslizante)
* SESSIONS_HISTORY : idem
* COMPLETED_TASKS_ARCHIVE : nuevo archivo para el período en curso
* sessions/ : solo las dos últimas sesiones

[plantuml, format=svg, id=diag-hot-warm-cold, alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Architecture Hot / Warm / Cold de la Contexto Agent
package "HOT (EAGER)\nChargé automáticamente\n~300 líneas" as HOT #FFCDD2 {
  file "INDEX.adoc\n(10 sessions)" as IDX_HOT
  file "PROMPT_REPRISE\n(session N+1)" as PRO_HOT
  file "AGENT.adoc\n(règles absolues)" as AG_HOT
}

package "WARM (LAZY)\nChargé a petición\n~500 líneas" as WARM #FFF9C4 {
  file "SESSIONS_HISTORY\n(10 dernières)" as HIS_WARM
  file "SCRIPT_VERIFICATION\n(dernière)" as VER_WARM
  file "PROCEDURES.adoc\n(templates)" as PRO_WARM
  file "*_REFERENCE.adoc\n(doc technique)" as REF_WARM
}

package "COLD (backup/)\nJamais cargado\nLecture humana únicamente" as COLD #BBDEFB {
  folder "Y2026-001-039/" as WAVE {
    file "INDEX (completo)" as IDX_COLD
    file "SESSIONS_HISTORY\n(complet)" as HIS_COLD
    file "COMPLETED_TASKS\n(complet)" as ARCH_COLD
    folder "sessions/ (001-039)" as SESS_COLD
  }
  folder "Y2026-040-???\n(future)" as FUTURE
}

HOT --> WARM : "Agent sube\nsi necesario"
WARM --> COLD : "Nunca automático\nL'humano va solo"

note bottom of COLD
Regla : COPIE INTÉGRALE
Sin transformación
Sin reindexación
Read-only después de archivado
end note

@enduml
----

La ganancia inmediata es masiva : el contexto EAGER pasa de**~5200 líneas a ~300 líneas**. Una división por 17. Sin haber perdido ni una sola línea de datos históricos.

== Por Qué No Es Un Cajón De Sastre

El agente, en su primera iteración, temía que`backup/`Se convierta en una caja negra — una carpeta donde depositamos archivos que nunca volveremos a leer. Es un temor legítimo. Pero se basa en una confusión.

Un cajón de sastre, es cuando se arrojan archivos.**sin estructura, sin convención, sin lógica de agrupamiento**. Aquí, el respaldo está estructurado por período (Y2026-001-039) y cada carpeta de respaldo contiene**la misma estructura**Que el expediente`.agents/`activo : INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/

No es un cajón de sastre. Es un**instantánea con marca de tiempo**. Podríamos incluso decir que es un mecanismo de versionado simplificado — con la salvedad de que no versiona los archivos individualmente, sino el conjunto completo de gobernanza en un instante T.

Cuando quieras recuperar una información antigua, no necesitas un índice central. Tienes dos opciones:

1. **grep` dirigido**:`grep -r "zsh" backup/Y2026-001-039/`— y encuentras todo lo que mencione zsh en el período, cualquiera que sea el ángulo (INDICE, SESSIONS_HISTORY, archivo de sesión)
2. **Reintegración manual**: Copias temporalmente la carpeta de respaldo en el contexto activo y solicitas al agente que analice este período específico.

El índice está implícito. Está en la propia estructura de los archivos — cada uno ya es un índice desde su propio ángulo.

== La metáfora de las estanterías

Para hacer el mecanismo intuitivo, lo he conceptualizado en tres niveles:

* **Estante 1 (EAGER)**— el plan de trabajo. Lo que necesito *ahora*. ÍNDICE reciente, PROMPT_REPRISE, reglas absolutas. Ligero, inmediato, crítico.
* **Estantería 2 (LAZY)**— biblioteca de consulta. Lo que puedo ir a buscar bajo petición. Referencias técnicas, historial reciente, procedimientos. Más voluminoso, pero no cargado en memoria.
* **Cueva (backup/)**— los archivos fríos. Todo lo que ha pasado pero que no quiero tirar. El agente nunca entra allí. El ser humano desciende allí cuando quiere destilar.

El agente propuso inicialmente una cuarta estantería — un`index-backup.adoc`que sería LAZY y contendría una tabla de contenido de todo el respaldo. Lo he rechazado. Sería una redundancia más en un sistema que ya sufre crecimiento lineal. La estructura de los archivos archivados ya es un índice.

== El sensor de dos disparadores

La conceptualización era sólida, pero quedaba un punto ciego:**¿Cuándo exactamente desencadenar la rotación?**El artículo inicial lo identificaba como una pregunta abierta. Dos días después, la respuesta está codificada en los archivos de gobernanza de seis proyectos: un sensor con dos disparadores.

=== El Disparador Automático — `N % 10 == 0

El primer desencadenante es matemático. Cuando el número de sesión es múltiplo de 10 — sesión 10, 20, 30, 40 — la rotación de copia de seguridad se ejecuta automáticamente dentro del procedimiento de finalización de sesión, justo después del paso 6.

¿Por qué 10? Es el compromiso entre dos fuerzas opuestas: una ventana demasiado corta (5 sesiones) pierde el contexto necesario para la continuidad; una ventana demasiado larga (20 sesiones) no resuelve el problema del exceso de contexto. Diez sesiones, a ritmo de una o dos sesiones por día, cubren aproximadamente una semana de trabajo—suficiente para que el agente recuerde las decisiones recientes, pero no tanto como para que el contexto se dispare.

=== El disparador por umbral — 500 líneas EAGER

El segundo desencadenante es dinámico. Independientemente del número de sesión, si los archivos EAGER acumulados superan**500 líneas**,
 se activa la rotación.

Este umbral protege contra el escenario donde las sesiones son excepcionalmente productivas — mucho contenido escrito en pocas sesiones. Una sesión que produce 120 líneas de contenido editorial hace crecer COMPLETED_TASKS_ARCHIVE mucho más rápido que una sesión de depuración que corrige dos líneas. El umbral de 500 líneas, medido vía`wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc`, captura esta asimetría.

=== El Desencadenador Manuel — "copia de seguridad por rotación

Finalmente, los seres humanos siguen al mando. Las palabras clave`rotation backup`, `backup rotation` ou `lance la rotation backup`Desencadenan el procedimiento bajo demanda, independientemente del final de la sesión. Resulta útil cuando se siente que el contexto está volviéndose pesado pero aún no se ha alcanzado un múltiplo de 10, o cuando se desea archivar una fase de trabajo antes de iniciar una nueva.

[plantuml, format=svg, id=diag-capteur-trigger, alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Sensor de Rotación Backup — Los Tres Desencadenantes
start

:Procedimiento de fin de sesión;
note right: Mots-clés "fin de sesión"\nou "paramos aquí"

:Pasos 1 a 6\n(archivage standard);
note right
Sesiones archivadas/N.adoc
MAJ PROMPT_REPRISE
MAJ SESSIONS_HISTORY
MAJ INDEX.adoc
MAJ TEST_COVERAGE
MAJ COMPLETED_TASKS
end note

if (N % 10 == 0\nOU\nEAGER cumulé > 500 lignes ?) then (oui)
  :Rotación de Copia de Seguridad\n(étape 7);
  note right
    1. Créer backup/Y20XX-sessions-X-Y/
    2. Copier intégrale INDEX + HISTORY
       + COMPLETED_TASKS + sessions/
    3. Tronquer actifs à 10 sessions
    4. Ajouter _Localisation active_
  end note
else (non)
  :Sin rotación;
endif

:Checklist [✅] x 7\n(si applicable);

stop

@enduml
----

Este diagrama muestra la inserción exacta del sensor en el procedimiento de finalización de la sesión. El paso 7 es opcional — solo se ejecuta si una de las dos condiciones es verdadera — pero se verifica sistemáticamente *verificada*. La lista de verificación final incluye`[✅] 7. Backup roté (si applicable)`.

=== Bucle cerrado

Este sensor cierra el bucle abierto por el artículo anterior. La gobernanza Eager/Lazy había resuelto el problema de la memoria agente entre dos sesiones. El mecanismo Hot/Warm/Cold ha resuelto el problema de la memoria que crece. El sensor con dos disparadores resuelve el problema del *cuándo* — quitándole al humano la carga mental de vigilar el tamaño del contexto.

[plantuml, format=svg, id=diag-boucle-fermee, alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Las Tres Capas de la Gobernanza del Agente
left to right direction

package "Capa 1 — Memoria\n(Article 0108)" as C1 #E8F5E9 {
  rectangle "**EAGER**\nTableau del borde\nChargé auto" as EAG
  rectangle "**LAZY**\nManuel propietario\nChargé sur demande" as LAZ
  EAG -[hidden]right-> LAZ
}

package "Capa 2 — Envejecimiento\n(Article 0110)" as C2 #FFF9C4 {
  rectangle "**HOT**\n10 sesiones activas\n~300 líneas" as HOT
  rectangle "**WARM**\nRreferencias\nProcprocedimientos" as WRM
  rectangle "**COLD**\nbackup/\nVague fría" as CLD
  HOT -[hidden]right-> WRM
  WRM -[hidden]right-> CLD
}

package "Capa 3 — Desencadenador\n(Aujourd'hui)" as C3 #BBDEFB {
  rectangle "**Auto**\nN % 10 == 0" as AUTO
  rectangle "**Umbral**\n> 500 líneas" as SEUIL
  rectangle "**Manual**\nrotation backup" as MAN
  AUTO -[hidden]right-> SEUIL
  SEUIL -[hidden]right-> MAN
}

C1 --> C2 : "La memoria crece\n→ se necesita un mecanismo\nde envejecimiento"
C2 --> C3 : "El envejecimiento\n→ se necesita un desencadenador\npara ejecutarlo"

note bottom of C3
✅ Desplegado en 6 proyectos
magic-stick · bakery-gradle
plantuml-gradle · cheroliv.com
jhipster-gradle-plugins
quizz-benchmark-gradle
end note

@enduml
----

Las tres capas se apilan lógicamente. La primera le da una memoria al agente. La segunda impide que esa memoria ahogue al agente. La tercera automatiza el mantenimiento de esa memoria para que el humano no tenga que pensar en ello.

=== La Migración Efectiva en cheroliv.com

El mecanismo no se quedó teórico. Sobre`cheroliv.com`, la primera rotación backup fue ejecutada el 29 de abril de 2026 — las sesiones -6 a 2 han migrado hacia`.agents/backup/Y2026-sessions-neg6-a-002/`:

|===
|Archivo |Antes de la rotación |Tras la rotación |Ganancia |`.agents/INDEX.adoc` |19 sesiones listadas |10 sesiones (3-12) |-9 entradas |`.agents/SESSIONS_HISTORY.adoc` |18 sesiones |10 sesiones |-8 entradas |`COMPLETED_TASKS_ARCHIVE` |161 líneas (sesiones 1-12) |135 líneas (sesiones 3-12) |-26 líneas |`sessions/` |20 archivos |10 archivos |-10 archivos |**backup/** |inexistente |1 ola fría (10 sesiones archivadas) |+1 paquete frío
|===

El aumento de líneas era modesto — el proyecto es joven, 12 sesiones — pero lo importante es que el**El mecanismo está colocado**. La próxima rotación automática se activará en la sesión 20, o antes si se alcanzan las 500 líneas EAGER.

== La Lección Humano-Agente

Esta sesión 048 me enseñó algo fundamental sobre la colaboración con un agente IA.

El agente tiene un sesgo natural: él trata de**optimizar**, à **simplificar**, à **eliminar las redundancias**. El sesgo de un sistema entrenado para producir respuestas limpias y concisas. Ante un conjunto de datos rico y multidimensional, su primer reflejo es reducirlo a su forma más simple.

El humano, él, tiene una intuición diferente: presiente que la redundancia estructurada es un**ventaja**, no es un defecto. Que la diversidad de los ángulos sobre una misma realidad es precisamente lo que permitirá, más tarde, una destilación de calidad.

No es que el agente esté equivocado. Es que su "optimum" no es el mío. El agente optimiza para el**presente**— el contexto inmediato, la respuesta rápida a la pregunta planteada. El humano optimiza para el**futuro**— la capacidad de encontrar, cruzar, destilar en tres meses o tres años.

____ Lo que quiero es el material bruto. Tus reflexiones, tus vacilaciones, tus respuestas a mis preguntas. No tu síntesis. La síntesis, sé hacerla mejor que tú. Quiero la materia prima. (empty)

Esta frase que yo le dije al final de la sesión resume todo. El agente es una herramienta de producción. El ser humano es la herramienta de destilación. La gobernanza no está hecha para que el agente entienda todo por sí mismo — está hecha para que el ser humano pueda, más tarde, trabajar el material producido.

La ola fría idéntica es la traducción arquitectónica de esta filosofía: no se desecha nada, no se fusiona nada, no se volverá a indexar nada. Se mueve el paquete intacto. La destilación vendrá más tarde, a mano, por el humano.

== La continuación lógica del artículo anterior

Si has leídolink:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[el artículo sobre la estrategia Eager/Lazy.], reconocerás la progresión natural :

1. **Artículo 0108**— Gobernanza Eager/Lazy : *cómo* estructurar el contexto del agente en dos niveles de disponibilidad
2. **Este artículo 0110**— El mecanismo de respaldo: *cómo* envejecer este contexto sin perderlo cuando se vuelve demasiado voluminoso

El primer artículo responded a la pregunta: « El agente no se recuerda de nada entre dos sesiones, ¿cómo darle una memoria?

Éste responde a la pregunta que inevitablemente deriva de la primera: «La memoria crece en cada sesión, ¿cómo evitar que ahogue al agente sin borrarla?

La respuesta consiste en un patrón:**Caliente/Tibio/Frío**, aplicado a los archivos de gobernanza. Y en un principio :**nunca perder nada, siempre reubicar todo**.

== Enlaces

* Artículo anterior:link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Gobernar un Agente IA con AsciiDoc]
* Mi sitio : https://cheroliv.com
* El proyecto`magic-stick` : https://github.com/cheroliv/magic-stick

---

*Un buen sistema de gobierno nunca elimina datos. Los archiva.*
----

Artículos relacionados

HyperFrames-Gradle: Convertir AsciiDoc a video MP4
31 May 2026
Auditoría de mi consumo LLM: SQLite, OpenCode, Ollama Cloud, y por qué mi suscripción Pro está revolucionando el mercado mundial
18 May 2026
La arquitectura “Plugin independiente + raíz consumidora”: ¿por qué mis builds de Gradle se duplican?
14 May 2026
El Knowledge Graph como motor de recomendación: cómo maté los « artículos conexos » cronológicos
12 May 2026