Tomaste una decisión el martes. El agente y tú hablasteis por qué la capa de auth tenía que seguir siendo stateless, pesasteis dos enfoques, elegisteis uno y seguisteis. El jueves abres una sesión nueva, pides un cambio cerca, y el agente te propone tan contento el enfoque que ya habías descartado. Se lo vuelves a explicar. Acabas de pagar esa decisión dos veces, y la segunda no te compró nada.
Eso es la pérdida de contexto, y si operas agentes para trabajo real es probablemente el mayor impuesto sobre tu día. No la calidad del modelo. No el coste de tokens. El goteo constante de reestablecer cosas que el sistema ya había resuelto, porque el sitio donde las resolvió fue una conversación, y las conversaciones terminan.
No parece un coste grande porque nunca llega como una sola factura. Llega como mil re-explicaciones pequeñas, cada una lo bastante barata para absorberla, sumando una fracción grande de tu atención gastada en contarle a los agentes lo que, en cierto sentido, ya sabían.
Dos pérdidas distintas que llamamos igual
«Perder contexto» cubre dos fallos que se comportan distinto y necesitan arreglos distintos.
El primero es la pérdida dentro de una sesión, cuando la ventana de contexto se llena y se compacta. Un run largo se resume para caber, y resumir es lossy a propósito. Manejar esa frontera a propósito es su propia disciplina, gestionar la ventana de contexto en trabajo largo. El modelo se queda un resumen comprimido y suelta los detalles. Los detalles que suelta suelen ser los que menos importaban al resumen y más te importaban a ti: la razón exacta por la que descartaste un enfoque, el invariante que acordaste proteger hace tres horas, el caso límite que le dijiste explícitamente que cubriera. El transcript sigue leyéndose bien. El agente simplemente deja de honrar en silencio una restricción que ya no puede ver. Es primo cercano de por qué los agentes derivan: la especificación contra la que trabaja cambió sin ruido, y nada avisó del cambio.
El segundo es la pérdida entre sesiones. Una sesión nueva arranca en frío. Lo que no quedó escrito en algún sitio duradero simplemente no está. El código sobrevivió, porque el código es un archivo. El razonamiento detrás del código no, porque el razonamiento vivía en el chat. Reabres el proyecto y el agente sabe qué dice el código y nada de por qué lo dice.
Los dos son el mismo error de fondo: tratar la conversación como si fuera memoria. No lo es. Es una superficie de trabajo que se borra.
dentro de una sesión
- la ventana se compacta
- el resumen suelta detalles
- el invariante se va
entre sesiones
- la sesión arranca en frío
- nada duradero persiste
- el porqué se pierde
Qué desaparece de verdad
Ayuda ser concreto sobre qué pierdes, porque «contexto» es demasiado vago para defenderse de ello. Cuando una sesión se compacta o termina, lo que se evapora de forma fiable es:
- Las decisiones y sus razones. No solo qué elegiste, sino qué descartaste y por qué. La opción descartada es el conocimiento caro, y es lo primero que un resumen tira.
- Los invariantes. Lo que tiene que seguir siendo cierto. «Nunca bloquees el hilo principal aquí.» «Esta tabla es solo-append.» Un agente que no ve el invariante lo rompe y pasa su propia revisión, porque desde dentro de la ventana no había regla que violar.
- El espacio negativo. Casos límite que acordaste cubrir, alcance que acordaste dejar fuera. La ausencia es imposible de reconstruir desde un diff. Nadie puede mirar el código y ver el caso al que le dijeron que no se preocupara.
- El hilo de la intención. Por qué existe esta tarea, qué comportamiento busca instalar, cómo conecta con la cosa tres tareas más allá. Es la primera baja de un arranque en frío y la más difícil de reconstruir.
Fíjate en que nada de esto es el código. El código es lo único que sobrevive por defecto. Todo lo que le da sentido al código es justo lo que se pierde.
Por qué una ventana más grande no te salva
La respuesta obvia es una ventana de contexto más grande, y ayuda en el margen, pero no resuelve el problema, por dos razones.
Primera, más ventana es más sitio que llenar, no una garantía de conservar lo correcto. Un run lo bastante largo se compacta igual, dé igual el tamaño de la ventana, y cuando lo hace, el mismo resumen lossy decide qué guardar. Una ventana más grande pospone la pérdida. No cambia su naturaleza.
Segunda, y más de fondo: la ventana es por sesión. No puede cargar nada a través de la frontera donde una sesión acaba y otra empieza. La pérdida entre sesiones no es un problema de capacidad. Ninguna ventana, por grande que sea, persiste después de cerrarla. Es el argumento que desarrollé en context engineering para agentes de código: el movimiento útil no es meter más en la ventana, es ser deliberado con qué entra en ella y qué sobrevive fuera.
El arreglo es dejar de usar el chat como almacén
Las cosas duraderas, decisiones, invariantes, intención, tienen que vivir en algún sitio que no sea la conversación. Ese es el movimiento entero. Todo lo demás es detalle.
En concreto, eso significa que una decisión se escribe cuando se toma, en una forma que un agente futuro en frío pueda cargar, no queda implícita en un transcript que nadie va a reabrir. Significa que los invariantes viven en un fichero de reglas que el agente lee al empezar cada sesión, no en tu recuerdo de haberlos dicho una vez. Significa que la intención detrás de una tarea viaja con la tarea como artefacto, no como tu memoria de un chat.
Esto es justo de lo que va la memoria para agentes de código: decidir qué debe persistir fuera del chat, y en qué forma. La pérdida de contexto es la enfermedad. La memoria externa y deliberada es el tratamiento. Los dos artículos son el mismo problema visto desde la herida y desde la cura.
Hay una versión de esto del lado de producto, y vale la pena ver el paralelo. Los equipos pierden entre personas lo mismo que los agentes pierden entre sesiones: la razón de una decisión, la restricción que alguien conocía y nunca escribió. Eso es memoria de producto, lo que un equipo olvida y el sistema no debería. La respuesta es la misma en ambos casos, un sistema que recuerda en nombre del equipo, que es la idea detrás de el cerebro de producto que se mantiene solo. El olvido humano y la pérdida de contexto del agente son el mismo fallo a dos escalas.
Cómo se ve lo bueno
Sabrás que lo has arreglado cuando una sesión en frío no sea un arranque en frío. Cuando abras un agente nuevo en un proyecto y cargue las decisiones, los invariantes y la intención actual antes de escribir una línea, porque esas cosas viven en el repo y el modelo las lee, no en un chat que cerraste el martes.
Eso no pasa por accidente, y no pasa prompteando más fuerte cada mañana. Pasa negándote a que el conocimiento duradero viva en un sitio efímero. El chat es donde ocurre el trabajo. No es donde vive la memoria. Ten esas dos cosas claras y el impuesto de productividad desaparece sin ruido, porque dejas de pagar las mismas decisiones dos veces.
Esa negativa, hecha sistemática, es buena parte de lo que significa dejar de ser el runtime a mano. Y es por lo que correr varias sesiones en paralelo solo escala si cada una puede cargar el contexto compartido por su cuenta, en vez de enrutar cada dato recordado por el único humano que estaba cuando se decidió.
¿Cuánto de tu primera hora con un agente se va en re-explicarle lo que ya debería saber? Cuéntame en el foro.
Preguntas frecuentes
¿Por qué mi agente de código pierde el contexto entre sesiones?
Porque el razonamiento vivía en el chat, y el chat es una superficie de trabajo que se borra. El código sobrevive porque es un archivo; las decisiones, los invariantes y la intención detrás de él no, salvo que quedaran escritos en algún sitio duradero. Una sesión nueva arranca en frío y sabe qué dice el código y nada de por qué lo dice.
¿Es lo mismo perder contexto dentro de una sesión que entre sesiones?
No, y necesitan arreglos distintos. Dentro de una sesión, la ventana se llena y la compactación resume de forma lossy, soltando justo los detalles que más te importaban. Entre sesiones no se traslada nada, porque la ventana es por sesión. Uno es un problema de compresión, el otro de persistencia.
¿Una ventana de contexto más grande arregla la pérdida de contexto?
Solo en el margen. Más ventana es más sitio que llenar, no una garantía de conservar lo correcto, y un run largo se compacta igual. Y más de fondo: la ventana es por sesión. Ninguna ventana, por grande que sea, persiste después de cerrarla. La pérdida entre sesiones no es un problema de capacidad.
¿Cómo dejo de re-explicarle las mismas decisiones a un agente?
Deja de usar el chat como almacén. Escribe las decisiones cuando se toman, guarda los invariantes en un fichero de reglas que el agente lee al empezar cada sesión, y deja que la intención de una tarea viaje con ella como artefacto. Cuando eso vive en el repo y no en un transcript cerrado, una sesión en frío deja de ser un arranque en frío.